Writes a Manager README covering how I work, what I expect, how to disagree with me, how to reach me and what I am still learning, shared as a draft the team can correct. Use for "run mgr-manager-readme", "manager readme", "how I work document", "user manual for my team", "introduce myself to my new team", "I inherited a team", "reset with my former peers", "how to work with me doc", part of the AI for Managers Pack by Polar Bear.
Installs into .claude/skills of the current project.
Are you the author of Mgr Manager Readme?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/polar-bear-org-mgr-manager-readme)
---
name: mgr-manager-readme
description: Writes a Manager README covering how I work, what I expect, how to disagree with me, how to reach me and what I am still learning, shared as a draft the team can correct. Use for "run mgr-manager-readme", "manager readme", "how I work document", "user manual for my team", "introduce myself to my new team", "I inherited a team", "reset with my former peers", "how to work with me doc", part of the AI for Managers Pack by Polar Bear.
---
# Manager README
## When To Use
The team does not yet know how you will manage, you inherited a team, or you need to reset how you work with people who were your peers last month. This answers: what does my team need to know about how I work, written so they can hold me to it?
## When Not To Use
If the question is how the whole team works together (channels, hours, meeting norms), that is a team decision; run Working Agreements. If you have not yet listened to the team, run New Manager 30-60-90 Day Plan first and write this after.
## Inputs
- How you actually spend your week, and how and when you reply to messages
- What you expect from the team, in your own words
- One or two things you know you are still learning as a manager
If you have none of this, I start from your answers to the three questions below, and mark the output as a first draft.
## Approach
The manager "how I work" document is common practice with no single public originator. Its value is not the writing; it is that the team can check it against what you do. The failure it prevents: a README promising "my door is always open" from a manager whose calendar has no free hour, which teaches the team that the manager's words are decoration.
## Workflow
1. Ask three questions: how do you really reply to messages and by when, what is one thing that frustrates you in how work reaches you, and what are you still learning?
2. Write five sections in the first person, each specific enough to test: how I work, what I expect, how to disagree with me, how to reach me, what I am still learning. Replace every adjective with a behaviour ("I reply to messages within [time the user sets]", not "I am responsive").
3. "How to disagree with me": give a real channel (in the 1:1, in writing, in the meeting) and a promise about what happens after, such as a reply by a date and a reason if you do not change course.
4. "What I am still learning": name one or two honest gaps. One real gap earns more trust than five strengths.
5. Check every line against what the manager actually does this month; cut or rewrite any line that promises what the calendar or inbox contradicts. Flag lines you cannot verify.
6. Share it as a draft the team can correct, with a review date. Their corrections go in, not to a footnote.
## Output Format
```markdown
# Manager README
Draft shared on [date]. Correct me: [where to comment]. Review date: [date].
## How I work
- [behaviour, e.g. "I block [time] for focus work and move it for urgent team issues"]
## What I expect
- [expectation as an action]
## How to disagree with me
- Channel: [1:1 / in writing / in the meeting]
- What happens after: [reply by when, and what I do if I keep my view]
## How to reach me
| For | Use | I reply within |
|---|---|---|
| [urgent / routine / sensitive] | [channel] | [time set by user] |
## What I am still learning
- [honest gap], and what I am doing about it: [action]
## Changes from team corrections
- [date]: [what changed and who asked]
## Decision
[name, the manager] reviews the team's corrections and publishes the revised version by [date].
```
## Done When
- All five sections are in the first person with testable behaviours
- "How to disagree with me" names a channel and what happens after
- Every line matches what the manager does today, or is cut
- A review date and a correction route are on the page
## Quality Bar
- No adjective without a behaviour behind it
- No promise the calendar contradicts
- One or two real gaps, not a disguised strength
- Says nothing about any individual team member
## Next
Run mgr-delegation-levels (Levels of Delegation) to make decision rights explicit.
## About the makers
This pack is made by Polar Bear, a consultancy built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. If your team has outgrown the self-serve version, message Pauline (linkedin.com/in/paulinebertry).