If you're a first-time CTO, there's a good chance your team is still trying to figure you out. How do you like to communicate? What do you care about most? When is it okay to interrupt you… and when isn't it?

Most first-time CTOs haven't thought about this explicitly yet. And that's completely normal. You're busy building a product, hiring a team, and figuring out the role itself. Sitting down to document "how I work" probably isn't at the top of your list.

But here's the thing: your team is already building a model of who you are. They're just doing it through trial and error and getting some of it wrong 😅.

A CTO README is a short document that tells your team how you work, what you value, how you communicate, and what they can expect from you. Think of it as a personal operating manual. Not a contract. Not a manifesto. Just a clear, honest guide that helps the people around you collaborate with you more effectively.

By the end of this playbook, you'll understand why the practice exists, what makes a good README, what the legitimate criticisms are and you'll have everything you need to write your own.

The readme for an AI agent

AI coding agents and assistants are increasingly part of how engineering teams operate. And just like a new hire, they work better when they understand how you think. An AI agent can adapt accordingly.

This is already how tools like Claude Code work. Point an AI agent at your README and it adapts how it communicates, what it prioritises and how it frames decisions. The same document that helps a new engineer understand you in their first week helps an AI assistant understand you in its first second.

Community Action: Share Your README 🚀

Once you've read this article, write yours, even a rough first draft, and share it in the community. Get feedback from people who actually understand the role. See how others have tackled the same sections you're struggling with.

What Is a CTO README?

The concept started in engineering leadership circles around 2016, the director at Netflix began sharing a personal document with every new team he joined. The idea was simple: instead of waiting months for people to figure out his quirks, preferences, and values through trial and error, he'd give them a head start.

The name borrows from software, where a README file explains how a project works. Here, the "project" is you.

A CTO README typically covers:

- How you prefer to communicate (and how not to reach you)

- What you value most in your team

- How you handle conflict, failure and decision-making

- What your quirks and blind spots are

- What people can expect from you… and what you expect from them

It's not long. A good README takes 5-10 minutes to read. But the clarity it creates can save months of miscommunication.

Why this matters for you

Let's start with what you're probably experiencing right now.

You're in a new role maybe your first leadership position. You've got a team that's trying to figure out how to work with you. You're trying to figure out how to lead them. Meanwhile, there's a product to build, a CEO to align with, and a maybe a board that expects results.

Some of the issues you might have:

"I keep giving feedback that surprises people: they didn't know I cared about that."

"My team doesn't bring me problems early enough, and I don't know if it's because they're afraid to or because they don't know I want them to."

"I realised my direct reports have completely different assumptions about how I make decisions."

A CTO README short-circuits the guessing. It gives your team a starting point so they can spend less time figuring you out and more time building.

But there's a second reason that's just as important, and it's not about your team at all:

Writing a README forces you to articulate what you actually believe.

The playbook for writing a good README

Let’s build a README together. We'll walk through the essential sections, what to put in each, and the mistakes that turn a useful document into corporate wallpaper. You won't get this perfect on the first try, but that’s expected. The goal is a solid first draft, not a masterpiece.

Section 1: About Me

Start with who you are, not your resume, but your story. How did you get here? What are you passionate about? What should people know about you as a human being?

This section humanises the document. It's short, three to five sentences, and it sets the tone for everything that follows.

🔥 Example: "I started as a Java developer, then moved into Solution Architecture at a large retailer. Eventually I took the leap and started my own startup in e-learning, it didn't work out, but it taught me that sales is the most important thing a company can have. Along the way, I learned you don't need to code to enjoy your job. Outside of work, I'm a family man who stays fit to stay sharp."

Prompt to get you started: If someone who doesn't work with you asked "what are you like?", what would you tell them?

Section 2: My Role as I See It

Define what you think your job is. Not the job description: your actual understanding of where you add value and what you're accountable for.

This is important because your team's assumptions about your role might not match your own. Stating it explicitly avoids a lot of confusion.

🔥 Example: "I believe in getting the right people on the bus. Once they're on, my job is to make sure the team can take responsibility for itself. I'm here to unblock things by making decisions, even the difficult ones, so we keep moving in the right direction for what the company needs. And I love to nurture talent and watch it grow."

Prompt: Complete the sentence: "The most important thing I do every day is..."

Section 3: What I Value

This is the emotional core of the document. What behaviours matter most to you? What do you reward or even informally? What does a great team look like to you?

Be specific. "I value transparency" is too vague. "I'd rather hear bad news on Monday than discover it on Friday" is useful.

🔥 Example: "I value openness: hard on problems, soft on people. If something isn't working, I want us to talk about it directly rather than tiptoeing around it. I like ambition and setting the bar high, which means a commitment to self-improvement from everyone, including me. And I value people who bring something extra: not just doing their job, but doing the thing they're uniquely good at. Everyone has that thing, and it's different for each person."

Prompts:

- What's the one team behaviour that, if missing, breaks everything for you?

- Think of the best team you've been on. What made it work?

- What do you informally reward… even when it's not in anyone's job description?

Section 4: Communication

This is the most practically useful section. Be concrete. Don't say "my door is always open" unless your door is actually, literally, always open.

Cover these areas:

Preferred channels: When should someone Slack you versus email you versus book a meeting? What's your response time for each?

Availability: When do you work? What happens if someone messages you at 9pm… do you expect a response from them at 9pm?

Bad news: How do you want to hear about problems? Early and rough, or fully formed with proposed solutions?

1:1s: What are they for? Who owns the agenda? How often?

🔥 Example: "Slack for everything, never Teams. If a conversation takes longer than five minutes, book a meeting so we can record it. For questions and status updates, prepare before reaching out: my time is limited, so make it count. I value your time too 😀. I might send messages outside business hours, but I don't expect a reply until you're back on the clock. When I message you during work hours on Slack, I expect a reply within two hours. For urgent things, just call. After hours, send me a text."

Prompt: Think about the last miscommunication you had with someone on your team. Would this section have prevented it?

Section 5: How I Make Decisions

Your team needs to understand your decision-making style. Are you consensus-driven or do you make the final call? When do you want input? What happens after a decision is made… especially if someone disagreed?

🔥 Example: "I follow Jeff Bezos's revolving door principle. Decisions that can be reversed should be taken swiftly, don't overthink them. Decisions that can't be reversed, or take a long time to undo, need more information and careful thought. But even then, I expect decisions to be made with a limited set of information… that's the startup way. Moving forward is always more important than not moving at all. Once we commit, we move forward. It may take time to decide, but looking back doesn't help anyone."

Prompt: Think of a recent decision that went well. What made the process work? Now think of one that went poorly, what would you do differently?

Section 6: Feedback

How do you give feedback? How do you prefer to receive it? Be honest about this on: it's where the gap between aspiration and reality is often widest.

🔥 Example: "I give feedback openly and directly, hard on problems, soft on people. If I don't like something or it wasn't built correctly, I'll say so. I expect the same in return: push back on me when you think I'm wrong."

Prompt: When was the last time someone gave you honest feedback? How did you react… and how do you wish you'd reacted?

Section 7: My Quirks and Blind Spots

This is the section that separates a useful README from corporate fluff and it's the one most first-time CTOs find hardest to write. That's normal. Being honest about your patterns and rough edges requires vulnerability, and vulnerability feels risky when you're still establishing yourself as a leader.

But here's what we've seen: this is often the section that builds the most trust. Your team already knows your quirks. Naming them shows self-awareness.

Be honest, but critically, don't use this as a permission slip. If you list a flaw, also mention what you're doing about it.

🔥 Example: "I think out loud. When I'm brainstorming, I'll say things that sound like decisions but are actually me processing. If you're unsure whether something I said is a direction or a thought experiment, ask me: 'Is that a decision or are you thinking out loud?' I'm working on being clearer about this, and I appreciate the nudge."

Prompt: Ask two people you trust: "What's the thing about working with me that took the longest to figure out?" Their answers belong in this section.

Section 8: What Frustrates Me

Be direct about the things that erode your trust or patience. This isn't about being demanding, it's about giving people actionable information.

🔥 Example: "Excuses over solutions frustrate me. When something doesn't work, I don't need an explanation of why it's broken: I need a proposal for how to fix it. I also get frustrated when people stay too rigidly within their domain and don't help a teammate out. In a startup, you need to be more of a generalist than a specialist. Step outside your comfort zone and pitch in where you're needed."

The Mistakes That Kill a README

Writing aspirational fiction. If your README describes the leader you want to be rather than the one you are, your team will notice the gap immediately. That gap doesn't build trust, it destroys it.

Making it too long. If it takes more than 10 minutes to read, nobody will read it. Be concise. Edit ruthlessly.

Using it as a monologue. A README you hand over and never discuss is a memo, not a conversation starter. Share it in your first 1:1 with new team members. Ask: "Does this match your experience of working with me?" Be prepared for honest answers.

Setting it and forgetting it. Revisit it every quarter. You'll evolve, your README should too.

Making it one-directional. The most effective version of this practice is bidirectional. Ask your team members to write their own. When everyone has a README, it stops being "the boss's rules" and becomes a team practice.

Making It Bidirectional: The Team README Practice

This is how you address the power dynamic criticism head-on. Instead of only publishing your own README, invite your team to create theirs too. When a senior engineer shares that they need 20 minutes of quiet focus after standup, or that they prefer written feedback over verbal, the entire team benefits.

How to introduce it:

1. Write yours first. Lead by example.

2. Share it with the team and discuss it together, not in a presentation, but in a conversation. Maybe a 1:1?

3. Invite (don't require) others to write their own. Make it optional. Some people will love it, others won't and both are fine.

4. Use READMEs as 1:1 conversation starters with new team members.

How to talk about it:

- To your team: "I've written a short document about how I work, my values, communication style, and quirks. I'd love your feedback on whether it matches reality. And if you'd like to write your own, I'll read it."

- To your CEO: "I've introduced personal operating manuals across the engineering team. It's reduced onboarding friction and improved how we communicate across the team."

Where to Find Inspiration

If you'd like to see how other leaders have approached their READMEs before writing your own, here are solid starting points:

- Molly White's Manager README on GitHub: clean, concise and authentic

- Liran Tal's Manager README on GitHub: well-structured with clear sections

- The collection at svnk.github.io/manager-READMEs: dozens of examples from leaders across the tech industry

- managerreadme.com: a dedicated tool for creating and sharing your README

Read two or three for inspiration, then close the browser and write your own. The goal isn't to copy someone else's leadership style, it's to articulate yours.

The Skill You're Building

Writing a CTO README is not really about the document. It's about developing a skill that will serve you throughout your leadership career: the ability to be clear, honest and intentional about how you lead.

First-time CTOs often feel like they need to have everything figured out before they can lead with confidence. A README flips that assumption. It says: "I don't have all the answers, but I'm willing to be transparent about who I am and how I work." That honesty is more powerful than any amount of manufactured certainty.

The best READMEs are not polished, corporate-sounding documents. They're honest, slightly imperfect reflections of a real person who's trying to lead well. Yours will be too and that's exactly what your team needs.

If you've made it this far, you now understand the why, the how and the pitfalls. That's real progress. The next step is yours: block 90 minutes, open a blank document and start writing. Good luck 🚀!