Manager READMEs
A Manager README is a 1-2 page document a leader writes about themselves: what they value, how they communicate, when they're available, what they care about, what bugs them, how they make decisions, and how their reports should work with them. GitLab popularized the format in their public handbook; companies from Stripe to Shopify have adopted variants. The principle is simple: every new report spends 3-6 months reverse-engineering their manager's preferences from observation. A README compresses that learning curve to one afternoon. KnowMBA POV: manager READMEs reduce friction more than 1:1 frequency increases — but most managers refuse to write one because it requires self-awareness about behaviors they'd rather not name explicitly.
The Trap
Two failure modes. (1) Aspirational READMEs: managers write what they wish they were like, not how they actually behave. ('I welcome all feedback' from a manager who visibly bristles at criticism.) Within 90 days, the README destroys trust because it sets expectations that contradict daily reality. (2) Unwritten READMEs: managers who refuse to write one because 'people should just get to know me.' The cost is hidden but enormous — every new report wastes 3-6 months of cognitive bandwidth learning preferences that could have been documented in 2 hours. The unwritten README also disadvantages introverts and remote workers who can't pick up cues as easily.
What to Do
Write a 1-2 page README in five sections: (1) What I value (top 3-5 principles, with examples). (2) How I communicate (preferred channels, response times, when to interrupt, when to wait). (3) How I make decisions (Type 1 vs Type 2, what I want input on, what I'll decide alone). (4) What bugs me (specific behaviors that consume my energy — be honest). (5) How to work with me effectively (1:1 expectations, pre-reads, escalation path). Critical step: have your three most senior reports review it for honesty BEFORE publishing. Their job is to flag aspirational claims. Update annually.
In Practice
GitLab's CEO Sid Sijbrandij maintains a public README in the GitLab handbook that includes specific items like 'I prefer async written communication,' 'I read everything in the handbook before meetings,' and 'I get frustrated when meetings recap content that was already in the pre-read.' The README is referenced in 1:1s and is part of the onboarding for any new direct report. GitLab attributes part of its remote-first effectiveness (12,000+ employees across 67 countries at peak) to the discipline of every manager publishing a README. Source: GitLab Handbook (handbook.gitlab.com).
Pro Tips
- 01
The most useful section of any README is 'what bugs me' — written specifically. 'I get frustrated when people send me long Slack messages I have to decode' is useful. 'I value clear communication' is useless. Specificity is the entire point.
- 02
Publish your README in a place reports can re-read it (Notion, internal wiki, handbook). A Google doc shared once and forgotten doesn't reduce friction — it just feels productive. The README is a reference document, not a one-time read.
- 03
Pair the README with a 'Working With You' doc that EACH report writes about themselves. The asymmetry is wrong — you're learning their preferences too. The mutual README practice cuts onboarding friction more than any other single intervention.
Myth vs Reality
Myth
“READMEs are corporate self-help theater”
Reality
READMEs are operational documents that compress a 3-6 month learning curve into 2 hours. The signal is in usage: companies whose managers actually reference READMEs in 1:1s see measurable reductions in 'manager friction' on engagement surveys. The ones that don't reference them after writing are doing theater.
Myth
“Increasing 1:1 frequency solves manager-report friction better than READMEs”
Reality
More 1:1s without a README just produce more occasions for the report to guess at preferences. The README sets the baseline; 1:1s discuss the work. KnowMBA's view: weekly 1:1s with no README leave reports inferring preferences from tone — exhausting and error-prone.
Try it
Run the numbers.
Pressure-test the concept against your own knowledge — answer the challenge or try the live scenario.
Knowledge Check
Which of these is the BEST entry for the 'What bugs me' section of a manager README?
Industry benchmarks
Is your number good?
Calibrate against real-world tiers. Use these ranges as targets — not absolutes.
% of Managers With Published Manager README
Companies > 50 employees with formal management practicesElite (GitLab/Stripe)
> 90%
Healthy
60-90%
Inconsistent
20-60%
Absent Practice
< 20%
Source: GitLab Handbook + remote-first company benchmarks
Real-world cases
Companies that lived this.
Verified narratives with the numbers that prove (or break) the concept.
GitLab
2014-Present
GitLab institutionalized Manager READMEs as part of its public handbook (one of the most comprehensive remote-work documents in the world, 2,000+ pages). Every manager — including CEO Sid Sijbrandij — maintains a public README accessible to anyone in the company. The READMEs are referenced in onboarding, in 1:1s, and updated annually. GitLab attributes its ability to scale to 12,000+ remote employees across 67 countries (peak) to the discipline of documenting how each manager actually works.
Manager READMEs Published
100% of managers
Handbook Total Length
2,000+ pages
Peak Headcount
~12,000
Countries Operating In
67
GitLab's example shows the practice scales. The discipline isn't 'each manager writes a README once' — it's 'the company expects READMEs as part of being a manager and references them daily.' That's the difference between theater and infrastructure.
Stripe
2018-Present
Stripe internalizes Manager READMEs (or 'Working With Me' docs) as part of its onboarding process for any new manager. Each new manager publishes one in their first 30 days, reviewed by their manager and shared with their reports. The format varies but the core is consistent: how I communicate, how I make decisions, what bugs me. Internal surveys at Stripe show that teams whose managers maintain current READMEs report 18% higher 'clarity on expectations' scores.
READMEs as Onboarding Requirement
Yes (within 30 days)
Update Cadence
Annual
Clarity Score Lift With Current README
+18%
Headcount
8,000+
Stripe's data is the empirical case for READMEs: teams whose managers maintain them report measurable clarity gains. The investment is 2 hours per year per manager. The return shows up in every 1:1 the report has for the next 12 months.
Decision scenario
The Hidden README Problem
You're a CTO. Engagement scores show your direct reports give you a 6/10 on 'I know what's expected of me' (vs company average of 8/10). You have weekly 1:1s with all five reports. You're confused.
1:1 Frequency
Weekly
Clarity Score
6/10 (vs 8/10 avg)
Direct Reports
5
Manager README
None
Decision 1
Your VP of People diagnoses it as a 'manager skill gap.' She suggests management coaching ($15K, 6 months). Alternatively, you could write a Manager README (2 hours).
Take the coaching — clearly there's a deeper management skill issue if reports give you a 6/10Reveal
Write a Manager README first (2 hours): communication preferences, decision-making style, what bugs me, how to escalate. Then assess if coaching is still needed.✓ OptimalReveal
Related concepts
Keep connecting.
The concepts that orbit this one — each one sharpens the others.
Beyond the concept
Turn Manager READMEs into a live operating decision.
Use this concept as the framing layer, then move into a diagnostic if it maps directly to a current bottleneck.
Typical response time: 24h · No retainer required
Turn Manager READMEs into a live operating decision.
Use Manager READMEs as the framing layer, then move into diagnostics or advisory if this maps directly to a current business bottleneck.