Skip to main content
How to Write a Manager README
TMThomas McClean· Engineering Manager· 6 min read
  • Leadership
  • Trust
  • New managers
  • Team management
  • 1-1s

How to Write a Manager README

A manager README explains how you work, what you value, and what your team can expect from you. Here is how to write one that builds trust from day one.

Most teams spend the first few months quietly working out how their manager operates. What makes them tick. When to push back and when to let something go. How to deliver bad news without it landing badly. That process takes time, costs trust, and occasionally goes wrong. A manager README is a short document that puts those things on paper so your team does not have to figure them out through trial and error.

A manager README is not a list of accomplishments. It is a practical guide to working with you - written by you, for your team, before they have to ask.

What a manager README actually covers

A good README answers the questions your team will have in their first few months but might not feel comfortable asking out loud. Not because you are hiding anything, but because people are often reluctant to ask their manager basic questions about how they work. Putting the answers on paper removes the friction.

Typical sections

How I work

Core hours 9-5, prefer Slack over email, available on Fridays for longer conversations.

What I care about

Honesty over polish. Progress over perfection. Keeping commitments.

How I make decisions

I involve the team on decisions that affect how we work. I decide faster on operational things.

Giving me feedback

Say it directly. I will not take it personally. I would rather hear it early.

What you can expect from me

Regular 1-1s, honest feedback, and I will always tell you what I know.

The most useful sections are the ones that would have saved someone time or discomfort if they had known earlier. If you have heard the same question more than twice from different people on your team, it belongs in your README.

Keep each section short. Three sentences is usually enough. The goal is clarity, not comprehensiveness. A README with five honest sections beats a twelve-section template that reads like a job application.

Why transparency builds trust faster

The case for a manager README is really a case for transparency. When your team understands how you work, they spend less energy trying to decode your behaviour and more energy on the actual work. They are less likely to misinterpret your directness as anger, or your silence as disapproval. They know what normal looks like.

Without a README

Is she annoyed with me?
Should I email or Slack?
How much detail does he want?
Can I push back on this decision?
Will she want to know about this problem?

Weeks of guesswork.

With a README

Slack for quick things, email for decisions
Direct feedback is welcome here
Friday updates, not daily pings
Push back with data - it is expected
Tell me early about problems

Clear from day one.

This matters most for new joiners, who are already processing a lot. But it also benefits your existing team. If your working style has changed or you have taken on a new team, a README gives you a structured way to communicate that without waiting for the right moment in a 1-1 to come up naturally.

It also signals something about how you lead. Sharing a document that says “here is how I work and where I fall short” is an act of openness. That is exactly the kind of behaviour that helps teams feel safe to be honest in return. It is one of the most practical things you can do to build psychological safety in your team.

How to write yours

Start with the sections that are most relevant to where you are right now. If you are new to a team, lead with how you communicate and what people can expect from you in the first few months. If you are onboarding someone new, focus on what they need to know immediately.

A minimal starting point

## How I communicate

Slack for day-to-day. Email for anything that needs a record. I respond within a few hours during core hours. If something is urgent, call me.

## What I value most

Honesty, follow-through, and raising problems early. I would rather hear about something going wrong at the start than find out at the end.

## How to give me feedback

Say it directly. I prefer it in our 1-1 unless it is time-sensitive. I will not be defensive - criticism helps me improve.

## What you can expect from me

Regular 1-1s, honest feedback, and I will always share what I am able to. I will advocate for you.

Write it as if you are talking to someone on their first day. Plain language. Short sentences. Specific rather than vague. “I prefer direct feedback” is fine, but “I prefer direct feedback because I find vague hints stressful” is better. The more concrete you are, the more useful the document becomes.

Once you have a draft, share it before a 1-1 and invite feedback. Ask: does this reflect how I actually behave? Is there anything missing? That conversation is often as valuable as the document itself. It opens a dialogue about how you work and signals that you are open to adjustment.

The act of writing also makes you examine your own habits. If you write “I trust my team to manage their own time” but you are checking in daily on progress, that is worth noticing. A README is a small form of accountability to yourself. Use it as part of your effort to build trust with the people you manage.

Keeping it honest and current

The most common mistake with manager READMEs is writing them once and leaving them. Your priorities shift. Your working style evolves. A README that describes how you led two years ago can actually create problems, because it sets expectations you no longer meet.

  • Review every six monthsSet a recurring reminder to reread it and check whether it still reflects how you actually work. Even small updates keep it useful and signal to your team that you are still paying attention to it.
  • Update when context changesNew team, new role, new priorities - a transition is the best time to refresh your README. It also gives your team useful context about what is changing and why.
  • Ask your team to challenge itEvery few months, share the current version in a 1-1 and ask: is this still accurate? The gaps between what it says and what your team experiences are where the most useful updates come from.
  • Be honest about weaknessesA README that says “I can be slow to respond when I am in deep focus” is far more useful than one that presents an idealised version of yourself. Honesty breeds trust. Spin does the opposite.

Pair your README with regular catchups and you have a strong combination. The document tells your team how you work; your 1-1 catchups give them a regular space to check in on whether it is working in practice. One without the other is useful. Together, they make the relationship between you and each team member much easier to maintain.

Frequently asked questions

Run better 1-1s

Keep notes, track actions, and show up prepared every time. Free to start.