A manager README is a short written user guide for working with you as a leader: how you communicate, what you expect from your team, how decisions are made and how feedback reaches you best. The name comes from software development. Every good repository has a README file that tells newcomers how to work with it. So why not one for people, too?
The topic has been on my mind since I casually recommended writing such a document in my guide to the first one-on-one with new employees. That was too short-sighted. There is a fairly heated debate around manager READMEs, and the critics are right on several points. In this article you get both: a template to copy and an honest guide on how to write it so that it builds trust instead of costing it.
In short
A manager README helps your team understand your expectations and habits early, and it forces you to get clear about them yourself. However, it only works as an invitation to talk, not as a substitute for talking. The biggest pitfall is a flattering self-image that does not match how you actually behave.
What you will learn in this article
- What a manager README is and how it differs from working agreements
- Which criticism is justified and what that means for your document
- A template with nine sections to copy
- How to write and review the document in six steps
- How to introduce it to your team without it sounding like orders
What is a manager README?
It is a document of one or two pages in which a leader describes how they work and what others can expect from them. You will find many names for it: leadership README, personal user manual, “manual of me” or simply “how I work”. They all mean almost the same thing. The difference is mostly who writes it. A manager README comes from the leader, while anyone on the team can write a personal user manual.
The idea is not new. It became popular mainly in Silicon Valley tech companies, where some leaders share their READMEs publicly on GitHub or in blog posts. You will find sentences like “I don’t answer chats in the evening, and I don’t expect you to either”. Trivial? Maybe. For a new colleague who wonders in her first week whether she still has to respond at 9 pm, exactly this sentence is worth a lot.
How it differs from working agreements and a team charter
Manager READMEs are often confused with other collaboration tools. The most important line runs between “one person describes themselves” and “everyone agrees on something”. I described how teams negotiate their shared rules in my article on team working agreements.
| Manager README | Personal user manual | Working agreement | |
|---|---|---|---|
| Who writes it? | The leader | Each person for themselves | The whole team together |
| For whom? | Direct reports | Colleagues | Everyone on the team |
| Content | Expectations, way of working, decisions, feedback | Own way of working and needs | Shared ground rules |
| Commitment | Self-commitment of the leader | Voluntary information | Joint promise by everyone |
Why a manager README helps
Every leader has expectations they have never spoken out loud. For example, that bad news should come right away and not only once there is a finished solution. Or that a pull request without a description sits longer with you. New team members usually learn such things by trial and error. That takes weeks and sometimes an awkward conversation nobody needed.
A manager README shortens this phase. It also helps you: once you have to write down when you want to be involved, you quickly notice that you never knew exactly. In distributed teams the benefit is even bigger, because many signals from office life are missing. On a video call, nobody sees that you are focused and therefore seem curt.
Taking the criticism of the manager README seriously
The best-known critic is Camille Fournier, a former CTO and author of “The Manager’s Path”. In her 2018 blog post “I hate manager READMEs” she raises several objections that I find strong. Her core point: trust comes from behaviour over time. Or in her words: “You don’t get it from writing a doc about how you deserve their trust.”
Her arguments can be summarised like this. First, the document often mainly serves the manager, because it explains away misunderstandings in advance. Second, we know ourselves less well than we think, especially under stress. Third, the power balance is uneven: if your actions do not match your text, hardly anyone on your team will tell you openly. Fourth, listing your own quirks does not make those quirks acceptable. And fifth, such texts go stale, because people change.
My take
I largely agree with the criticism and still think the tool is useful. The difference lies in the attitude. A manager README that reads like instructions for “handling me correctly” does harm. One that makes expectations visible, invites disagreement and has an expiry date helps. That is why I would take three things from the criticism straight into the document: have it reviewed by someone who does not depend on you. Drop the “my quirks” section and write what you are working on instead. And set a date for the next review.
On one point I disagree with Fournier. She advises limiting the document to expectations of your reports. In my view, a README only becomes fair when it also says what the team can expect from you. Otherwise it remains a list of demands.
A template for your manager README
The following template has nine sections. You do not have to fill all of them. Better to drop a section than to fill it with platitudes. “I value open communication” appears in almost every README and tells nobody anything.
- What this document is for: one sentence on its purpose, a date and an invitation to disagree.
- My role: what you are responsible for, what you do for the team and what you explicitly do not do.
- What I expect from you: a few observable expectations, for example about bad news or commitments.
- Communication and availability: which channel for which level of urgency, typical response times, core hours.
- Decisions: what someone decides alone, where you want to be informed and what you decide together. The levels of delegation help with sorting this out.
- 1:1 meetings: cadence, length and who owns the agenda.
- Feedback: how you give feedback and how criticism reaches you best.
- What I am working on: one real area for improvement, named openly, instead of a list of charming quirks.
- What this document is not: not a basis for performance reviews and no excuse for bad behaviour.
As a Markdown file it looks like this. Copy it into your wiki or as a README into a team repository and replace the placeholders:
<!-- manager-readme.md --> # How I work – manager README of <name> Last updated: <date> · Next review: <date + 3 months> ## What this document is for A starting point for working together. It does not replace conversations, it should make them easier. If something does not match your impression, tell me – then the document is wrong. ## My role - What I am responsible for: ... - What I do for you: ... - What I deliberately do not do: ... ## What I expect from you - ... (concrete and observable) ## Communication and availability - Urgent (production, customers): call me or ... - Normal: chat, I usually reply within ... - Not urgent: ticket or a note for our 1:1 - My core hours: ... I do not expect replies outside your working hours. ## Decisions - You decide on your own: ... - I want to be informed beforehand: ... - We decide together: ... ## Our 1:1 meetings - Cadence and length: ... - The agenda is yours. I only bring topics if you have none. ## Feedback - How I give feedback: ... - The best way for your feedback to reach me: ... - If I get something wrong, I want to know, even by message. ## What I am working on - ... (a real area to improve, not an excuse) ## What this document is not Not a basis for performance reviews, not a contract and not a licence for bad behaviour. It is my current attempt to explain myself. Writing a manager README in six steps
Plan about two hours for the first draft, spread over a week. A README you dash off in one afternoon usually describes who you would like to be.
- Observe instead of inventing: For one week, note situations that pleased or annoyed you. A status update came too late, a decision was made without you, a review was especially helpful. These reveal your real expectations.
- Draft on one page: Fill in the template. Stick to one page, two at most. Nobody reads anything longer a second time.
- Make it concrete: Replace every vague statement with an observable one. The table below shows what that looks like.
- Get it reviewed: Give the draft to someone who has seen you at work but does not report to you. Good candidates are a peer, a former team member or a coach. Ask explicitly: “Where do I describe myself as better than I am?”
- Introduce it in a conversation: Do not just send it by email. Discuss it in a 1:1, as described in the next section.
- Revisit it: Put a date in your calendar three months out and then roughly every six months. Ask the team what no longer holds true.
The process at a glance: drafting and making it concrete are merged into one step here, and feedback keeps flowing back into the text.
Vague or concrete? Examples to rewrite
The most common mistake is sentences that sound good and say nothing. One test helps: could an outsider observe whether you stick to it? If not, rewrite the sentence.
| Vague | Concrete |
|---|---|
| My door is always open. | Send me “Got 10 minutes?” in chat. I get back to you the same day, usually within an hour. |
| I value ownership. | You make technical decisions within your service on your own. For changes to public interfaces, I want to be informed beforehand. |
| I am a direct person. | In our 1:1 I say openly when something bothers me, and I explain why. If that comes across as too harsh, please tell me right afterwards. |
| Bad news is welcome. | If a deadline is at risk, I want to know as soon as you do. A proposed solution is nice but not a requirement. |
How to introduce your manager README to the team
The moment of handover decides whether the document lands as an offer or as house rules. It fits best into the first 1:1 with a new person or into a regular 1:1 with existing team members. Tell the most important points in your own words instead of reading them out, and share the document afterwards. How to structure that first conversation overall is covered in my guide to the first one-on-one.
Then comes the most important part, the questions back. These four questions work well as a conversation guide:
- Which parts match your impression of me so far, and which do not?
- What is missing from the document for you?
- Is there anything you would like from me that is not in here?
- What should I know about how you work?
The first question is uncomfortable, and that is exactly why it matters. However, do not expect anyone to disagree in the first conversation. The power gap remains, no matter how friendly you ask. So repeat the question at the three-month review and offer a written channel as well.
Personal user manuals for the whole team?
If this works well, the obvious next idea is for everyone on the team to write their own personal user manual. That can help, especially in new or distributed teams. Tom Geraghty of Psych Safety recommends combining such documents with a shared team charter so they do not become an excuse for unhelpful behaviour. I would add two rules: it is voluntary, and personality tests or type labels stay out. Write yours first and then invite others, instead of handing it out as a task.
Common mistakes with a manager README
- Wishful thinking instead of reality: You describe who you would like to be. A review by someone outside your team helps.
- Quirks as a free pass: “I am sometimes impatient” sounds honest but works like a warning. Write instead what you are working on and how people can point it out to you.
- Only demands: A README that only describes what others should do is a set of instructions. Also say what the team can expect from you.
- Sent by email: Without a conversation, context is missing and the text quickly seems self-important.
- Never updated: After a year without a review, at least one section is usually wrong. A date makes that visible.
- Used as a yardstick: If you point to your README in a performance review (“But it says right there that ...”), an invitation turns into a rule.
FAQ
What is a manager README?
A manager README is a short description of how a leader works: expectations, communication, decisions and feedback. It is meant to make it easier for new and existing team members to start working together.
How long should a manager README be?
One page is ideal, two pages are the upper limit. Longer documents are rarely read a second time and usually contain platitudes.
What is the difference between a manager README and a personal user manual?
The content is similar. The leader writes a manager README for their team, while anyone can write a personal user manual about themselves.
When should I not write a manager README?
If trust in the team is currently damaged, a document about you looks like a distraction. Conversations and reliable behaviour help more. Also skip it if you do not intend to review it regularly.
Where should I keep my manager README?
Where your team already works: in the team wiki, as a README in a team repository or linked in the team channel. A date matters, so everyone can see how current it is.
Your next step
You do not need to write a finished document today. Start with the first step: for one week, note situations in which one of your unspoken expectations became visible. By Friday you will have the raw material for the sections “What I expect from you” and “Communication”, based on real behaviour instead of your self-image.
Now over to you: have you worked with a manager README, as a leader or as a team member? Did it help or rather confuse things? Let me know in the comments.
Sources
- Camille Fournier: I hate manager READMEs (Elided Branches, 2018)
- Tom Geraghty: Personal User Manuals (Psych Safety, 2022)
- Spinach AI: The pros and cons of manager READMEs
This post was created with AI assistance.
👉 Next step: Preparing a first one-on-one? My question cheat sheet puts the best questions on one printable page.
📬 Stay updated: New articles on serverless, AI and leading tech teams via RSS, browser push or the weekly newsletter (in German).
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
