A practical leadership tool for engineers and technical leaders
Leadership README Template for Tech Leaders
Help your team understand how you communicate, what you expect, and how decisions get made.
A Leadership README puts your working preferences and expectations in one place. Use it to clarify ownership, explain when to escalate, and start better conversations with your team and cross-functional partners.
This free template helps engineers and technical leaders turn unspoken expectations into working agreements people can discuss and use.
You already know the pattern.
You explain the priority in a meeting. Two weeks later half the team is working on something else.
You tell someone how you want to be brought problems. Next time you get a 4-paragraph Slack message at 11pm with no recommendation.
You wonder why a peer escalated something you would have happily owned, and why your direct report didn't escalate something they should have.
You assume people know how you operate. They don't. They're guessing. And under pressure, they're guessing wrong.
That's not a team problem. It's a missing artifact.
I wrote this for myself first.
I've spent 30+ years in technology. Chief Architect. VP. Currently a CTO at a growing SaaS company. I've led teams of 5 and teams of 140+.
For a long time I couldn't figure out why I kept saying the same things over and over. Same priorities. Same expectations. Same instructions on how I wanted decisions made and problems brought to me.
The answer wasn't that I needed to communicate "more." I was already communicating constantly.
The answer was that I'd never written it down.
What a Leadership README actually is.
One page. Five sections. Tells the people working with you exactly how you operate so they don't have to guess.
Versions of this document have circulated in engineering leadership for years - manager READMEs, operating guides, "how to work with me" write-ups. The name varies. The idea doesn't. Most senior technical leaders have still never written one.
Once it's written, people guess less. Communication friction drops. Decisions move to the right level. A lot of the repeated friction quietly goes away.
It's not a personality test. It's not a manifesto. It's an operating manual. Boring, by design.
What's in the template
Five sections. Roughly 45 minutes start to finish if you actually answer the questions instead of fudging them.
1. How I Communicate
Which channel for what, how to signal urgency, and what a meeting needs before it goes on the calendar. The defaults that quietly remove a lot of inbound friction.
2. What I Expect From You
Ownership. Communication norms. Quality bar. The standards you've been holding people to without ever writing them down - including expectations you agree on across engineering, product, design, and operations.
3. Decision Making
What you own. What they own. When to escalate - and how to raise a risk or a delivery change early instead of waiting for the next status meeting.
4. How To Bring Me Problems
What you need to see: the problem, the impact, and a recommendation with a specific request for a decision. What not to do.
5. What Success Looks Like
Outcomes. Behaviors. The picture of what "doing this job well" actually looks like, written down so the team can self-correct without you in the room.
How to introduce your Leadership README to your team.
The document is a starting point for a conversation, not a rulebook you hand down. A README that only communicates expectations in one direction is half the tool.
- Write down how you actually operate. Not the aspirational version - the real defaults your team already experiences.
- Share the draft and invite questions. Let people react before you treat it as finished.
- Discuss the differences. Where your preferences and theirs diverge, talk it through. Some gaps close in the conversation; some stay documented.
- Agree on the shared parts. Decisions, handoffs, and escalation only work if both sides sign up for them.
- Revise it as things change. The team evolves, and the working agreements should evolve with it.
Used this way, the README supports listening and discussion. It is not a unilateral rulebook for other teams - it's a written starting point that gets sharper every time you talk about it.
Why most leaders never write one.
Three reasons, in order:
One. They've never seen a good template. So they default to vague culture-deck language that no one can actually use.
Two. They assume their team already knows. The team doesn't. The team is guessing. Some of them have been guessing for years.
Three. Writing it down forces you to take a position. On how you communicate. On what you expect. On how decisions get made. That's uncomfortable, which is exactly why it's valuable.
The template solves the first problem. The second one solves itself the moment you ship the document. The third one is on you.
What you actually get
- The full Leadership README template, laid out section by section
- Prompts under each section so you're not staring at a blank page
- My filled-in answers as a working example
- A short note on how to roll it out to your team without making it weird
Free. No credit card. About 45 minutes from "I should write this" to "I've shared it with my team."
Who I am, briefly.
I'm Cory Berg. I started writing code at 18. I'm still doing it. I've held Chief Architect, VP, and CTO roles at companies large and small, led 140+ engineers, and I'm currently a CTO at a growing SaaS company.
I coach senior tech leaders on the side. Not as a former practitioner who switched careers. As an active executive who is still in the arena.
This template is the same one I use myself. I'm releasing it publicly for the first time. If you fill yours out, I want to hear what worked and what didn't. The next version will be better because of you.
A few common questions.
What is a Leadership README?
A short written document that explains how you communicate, what you expect, how decisions get made, and how you want problems brought to you. It turns unspoken expectations into something people can actually work from.
Who is it for?
Engineering managers, directors, and technology executives - and any technical leader whose work depends on other people understanding how they operate.
I'm a tech lead without direct reports. Should I still write one?
Yes. The exercise of articulating how you work, what you expect, and how you make decisions is valuable whether you have direct reports or not. Tech leads, staff engineers, and project leads benefit just as much.
How does it help with cross-team communication?
Most of the friction a README removes lives at the boundaries: handoffs between engineering, product, design, and operations. Writing down how you want to collaborate across those boundaries - and sharing it with your cross-functional partners - gives everyone the same expectations to work from.
How should I introduce it to my team?
Share the draft, invite questions, and discuss the differences before you treat it as final. The walkthrough above covers it step by step.
Is this really free?
Yes. No credit card. No upsell on the way in. I send occasional updates with new resources for tech leaders. Unsubscribe whenever.
My team is small. Is this overkill?
Smaller teams suffer more from missing artifacts, not less. There's nowhere for the misalignment to hide.
How long does this take to fill out?
About 45 minutes if you answer the questions honestly. Longer if you find yourself realizing you've never actually decided what you expect.
One last thing.
If you don't write your README, your team will keep guessing. That's the cost of not having the artifact. Not your team's fault.
Yours.
About 45 minutes. Free. Yours below.