Writing a Manager README: an honest example and useful questions

“I value ownership, open communication, and people who solve problems themselves.”

If that is at the top of your manager README, your team still knows almost nothing. When should someone involve you? What does ownership mean when two priorities clash? How do you react to bad news? And what happens when your own behaviour is the problem?

A good manager README does not only make visible what you expect from employees. It also describes what they can expect from you, where your blind spots are, and how someone can disagree with you safely. Otherwise it is not a guide, but a list of rules from the person with the most power.

What is a manager README?

A manager README is a short, personal guide for working with a leader. The name comes from software development, where a README explains what something does, how to use it, and what to watch out for.

For a manager, it can cover availability, decisions, delegation, one-to-ones, feedback, mistakes and behaviour under pressure. The document can speed up onboarding and make implicit expectations discussable.

A manager README is not:

• a personal manifesto that the team is only allowed to accept;
• a replacement for clear roles, goals or HR policy;
• a diagnosis or complete description of your character;
• a contract you later use to say: “You could have known this.”

See the text as a first hypothesis. In practice, the team discovers what is true, what is missing, and which phrasing mainly describes your own good intention.

The power imbalance changes the assignment

An employee cannot respond as freely to a manager README as to a colleague’s guide. The manager allocates work, evaluates performance and influences opportunities. “Feedback is welcome” therefore does not automatically feel like real permission.

Research on psychological safety makes clear why behaviour carries more weight than an invitation. In a study of 51 work teams, shared safety to take interpersonal risk was linked to learning-oriented behaviour in teams. Leadership coaching and context also played a role in the model (Edmondson, 1999).

Your README therefore must not only say that people may challenge you. It must make the route and your response predictable. When do you ask for objections? Can someone respond in writing? What do you do when the feedback is uncomfortable? And how do you later show that the signal was not used against the sender?

Make it visibleExplain your patterns

Name not only your intention, but also the behaviour others actually see and could misread.

Make it reciprocalWrite what you provide

For every expectation, set out a concrete responsibility or promise from yourself.

Make it safeDesign disagreement

Provide multiple routes to raise objections and show in your behaviour that a critical signal remains welcome.

Seven parts of a usable manager README

Keep the document short enough to actually read. One to two pages is usually enough. These seven parts cover the moments when unspoken expectations create the most work.

1. Availability

Describe when you are reachable and through which channel, what urgent means, and how focus blocks are made visible.

Avoid: “My door is always open.”

Instead write: “For something that needs a decision today, send me a message with the deadline in the first sentence. For thinking work, I would rather schedule twenty minutes than exchange five separate messages.”

2. Decisions

Explain which decisions the team makes independently, when you decide, and how a decision is documented. Also state how long objections are still welcome.

A useful structure is: advise, consent, decide or execute. For recurring topics, specify who has which role. That way “ownership” does not mean someone gets responsibility without decision latitude.

3. Delegation

Describe what outcome and boundaries you provide and where the new owner is free. Say how often you want to align and when a risk is reported early enough.

The most important self-test: if you still prescribe the route step by step, have you delegated work, or only divided up execution?

4. One-to-ones

Make it clear whose meeting it is. Who sets the agenda? Which topics do and do not belong here? How are agreements stored? Make space for development, collaboration and workload, not only status updates.

A workable agreement: “You add topics to the shared document. I add context and questions. The first half is yours, urgent operational decisions we schedule separately.”

5. Feedback

Describe how you give feedback and how you want to receive it. Add an alternative for people who do not like responding live. Above all, capture what you do after critical feedback.

“We do not have to agree” is too thin. Better: “I first summarise what I heard and say when you will get a response or decision. If I change nothing, I explain which trade-off carried more weight.”

6. Mistakes

Say when a mistake must be reported immediately and how you distinguish between an incident, a risky choice and a problem in the system. Also write what the team sees from you when you make a mistake yourself.

A manager who only says “making mistakes is allowed” but looks for blame at the first mistake mainly teaches the team to share information later.

7. Behaviour under pressure

Describe which pattern gets stronger in you when time, reputation or results are under pressure. Do you become shorter, quieter, more controlling, or more optimistic? Name the visible signal and give a concrete intervention.

Example: “Under time pressure, I start formulating solutions myself more quickly. Then explicitly ask: do you want to think along now or are you deciding? That question helps me make my role clear.”

An honest example

Use this example as a structure, not as text to copy blindly.

What you can reach me for

For a blocker that needs a decision today, message me right away with consequence and deadline. We collect other topics in our shared document or schedule them.

How I make decisions

I first want to see the goal, options and the strongest objection. I say upfront whether I am asking for advice or delegating the decision. After a decision, I record the owner and the reason.

How I delegate

I provide the outcome, quality bar, deadline and required dependencies. The route is yours. If I still steer on method, you may ask me which boundary is actually at risk.

Our one-to-ones

The agenda is yours. Status updates belong in the team overview. We use the time for priorities, collaboration, development and things you do not want to discuss in the group.

Feedback

I give feedback as close as possible to the behaviour and not via hints. You do not have to respond immediately. Feedback to me can be live, in writing or via our people partner. I will come back within two working days on what I do with it.

Mistakes

Report early what happened, what the impact could be and what you need now. We first limit the damage and then investigate cause and process. With my own mistake, I name the same three points.

Under pressure

I become faster and more directive. That can sound as if discussion is closed. Ask me: “Is this a decision or are you thinking out loud?” Then I make that explicit.

This example is useful because almost every paragraph contains observable behaviour, a boundary and reciprocity. The manager does not promise to be perfect. They make correction possible.

From a demand to a mutual agreement

One-sided

Do not come only with problems, come with solutions. I expect you to take ownership and inform me on time.

Mutual

When you bring a problem, bring the impact, deadline and the options you already see. If there is not yet a solution, still report the blocker early. I then make clear who decides and what help you get from me.

Red flags in a manager README

“That is just how I am”

A preference explains behaviour, but does not make the effect any less real. “I am direct” should be followed by how you check whether the message landed respectfully and clearly.

Rules without something in return

“Keep me proactively informed” is incomplete. About what, when, and what does the manager do with that information? Every expectation should give something back in the form of clarity, decision latitude, protection or help.

The ideal version of yourself

If you write that you listen calmly while the team mostly sees you interrupt under pressure, experience wins. Ask two colleagues which sentence does not match your behaviour.

Mandatory vulnerability from employees

The manager can voluntarily share something personal. That does not give a right to the same from the team. Keep the README focused on work behaviour and let employees decide what they keep private.

A document without a correction mechanism

A version from your first week of management quickly becomes folklore. Add a date, owner and next evaluation moment at the bottom.

Discuss the README, do not only send it around

1. 1
   PrepareWrite with evidence

   Link every statement to a recent example and ask two people which missing blind spot should be included.

2. 2
   DiscussLet the team correct it

   Ask which sentence is unclear, one-sided or not recognisable. Respond first by summarising, not by defending.

3. 3
   UpdateTest and revise

   Choose one working agreement, evaluate after a month and revise the entire document every quarter.

Send the text in advance and give people time to formulate comments. Then discuss three questions:

1. Which passage helps you make a decision or report something earlier?
2. Which passage places responsibility mainly on the team?
3. Where does my visible behaviour deviate from the text?

Also allow feedback in writing after the conversation. The employee who finds it easiest to challenge the manager live is not automatically the one with the best objection.

End with one experiment. For example: from now on, for every delegated project you record the outcome, decision latitude, boundary and next check-in moment. A month later, you do not discuss whether everyone liked the README, but what difference the agreement made.

Use personality as a mirror, not as an excuse

A personality profile can help you write your patterns more sharply. A focused manager may discover that their early planning is experienced as control. An exuberant manager may see that thinking out loud sounds like a decision. A sensitive manager can note that they spot risks early and seek extra context under pressure.

Always translate a label into behaviour and reciprocity:

• What does the team see me do?
• How could that be misread?
• What effect does my position as manager have?
• What may others say or do in such a moment?
• What do I then promise myself?

Also read how to create a broader Personal User Guide. With Personal User Guide for work you can translate your Big Five preferences into concrete patterns, misinterpretations and agreements.

The best README makes itself less necessary

A strong manager README gives a new team faster access to information that would otherwise remain implicit for months. After that, daily behaviour should take over from the document. People know how a decision will be made, can report a risk early, and see that disagreement does not become a career risk.

So do not write a definitive guide about who you are. Write a testable agreement about how you work together, and visibly give the team the right to improve that agreement.