Appendices

These are the parts of the handbook meant to be copied. Each one links back to the chapter it came from. The onboarding, one-to-one and handover templates are adaptations I would start with; the filled-in examples describe possible work, not a particular employee's history.

Appendix A: A template for shaping a goal

From Delivery. I fill this in with the person doing the work, and add detail only where a real question needs it.

• Outcome: Who should be able to do what?
• Why now: Why does this deserve attention ahead of the other goals?
• Evidence: What would show us that it works, and which assumptions need checking?
• Owner and Sponsor: Who owns delivery, and who supplies the context and agrees scope?
• Boundaries: What is included, excluded or dependent on other work?
• Work linked to the goal: Every implementation issue in the milestone must link to a goal, directly or through a subgoal. Move work that does not contribute to a goal out of the milestone.
• Next check: When will we look at the result and decide what happens next?

Appendix B: The roles on a goal

From Decisions and Delivery.

Appendix C: Product responsibilities without a product manager

From Collaboration. This is the division I drafted for the team to discuss.

Leadership owes the team:

• Who each goal is for, what problem it addresses and what finished work looks like.
• One shared order of priorities. When it changes, agreement on what moves out, changes or waits.
• Shared customer notes, and engineers in those conversations.
• Decisions recorded where the work is happening.
• An answer within one working day to a scope question, concern or draft.

Engineers owe the team:

• Questions about the scope before building.
• The code connected to the work it belongs to.
• Enough understanding of the main customer journeys to use and explain them.
• The change taken through to pre-production and the affected journey used end to end, including its failure cases.
• For a blocked item: what is missing, who could help, and the next action.

Appendix D: Questions about a release path

From Delivery. A team should be able to answer these about its own service.

• After a version is released, does it reach each environment automatically, or does a person promote it?
• Who decides that a release goes out: the service owner alone, or with a review?
• How do you roll back in practice: revert the commit, redeploy the previous version, or fix forward?
• When did you last roll something back, and how long did it take?

The exercise I would start with: take one customer journey all the way through, including a failure and recovery, and have another engineer repeat it.

Appendix E: The technical founder

The Becoming a CTO series describes the first-year experiences behind this handbook.

1. Nobody Handed Me a Manual
2. Imposter Syndrome Is Real
3. Trust Is a System You Design
4. Ten Engineers, No Product Manager
5. We Kept Trying to Plan Everything
6. AI Is a Multiplier, Not a Signature
7. Compliance at AI Speed
8. My First Year as CTO

Appendix F: Reading

Grouped by the chapter each one informed.

The role

• Matt Mochary, with Alex MacCaw and Misha Talavera, The Great CEO Within. A useful reference for management practices alongside the experience behind these chapters.
• Camille Fournier, The Manager's Path. The later chapters describe holding direction and the whole picture while the team moves without you.
• Charity Majors, The Engineer/Manager Pendulum. On the change in work underneath a change in title.
• Will Larson, Work on what matters. For deciding where technical involvement helps most.
• Lara Hogan, When to delegate, when to say no. The exercise I used to sort my commitments.

Trust, ownership and decisions

• Netflix, Culture. “Context, not control” is the shortest statement of why ownership has to run both ways.
• Henrik Kniberg, Spotify engineering culture, part 1. High alignment is what makes high autonomy safe.
• Rouan Wilsenach, Ship / Show / Ask. Our vocabulary for when a change needs someone else before it lands.
• Sarah Milstein, How team agreements promote high performance. A practical companion to writing a working agreement.

Planning and product

• Ryan Singer, Shape Up. The chapters on appetite and boundaries are the ones I reread.
• Martin Fowler, The New Methodology. Adaptive against predictive planning.
• Henrik Kniberg, Making sense of MVP. The skateboard-to-car picture, with the reasoning underneath it.
• Marty Cagan, Product is Hard. Keeps the PM conversation connected to product value.

Building with AI

• Simon Willison, Not all AI-assisted programming is vibe coding (but vibe coding rocks). On taking responsibility for code you understand.
• Birgitta Böckeler, The role of developer skills in agentic coding. The framing, steering and correction involved in working with an agent.
• Addy Osmani, The 70% problem. Where AI-assisted building saves time and where it does not.
• DORA, Balancing AI tensions: moving from adoption to effective use. On the verification work that comes with faster generation.

Review, release and compliance

• Google Engineering Practices, The Standard of Code Review. What a reviewer is actually deciding.
• Martin Fowler, Patterns for Managing Source Code Branches. Separates branching choices from review and release choices.
• Steven Shorrock, The Varieties of Human Work. Language for the difference between what a procedure says and what happens.
• Phil Venables, Control Reliability Engineering. Checking whether a control keeps working after its first successful test.
• GitLab, The importance of a handbook-first approach. Whether documentation is part of how people work or maintained separately for a review.

Appendix G: A ninety-day plan for an engineer

This template accompanies the first ninety days section in People. Prepare the draft at least seven days before the person starts, then review it together in their first week. Choose work that fits the role and the product's current stage.

Record the person's role, manager, start date and review dates. For each goal, write the outcome, what would demonstrate progress and the support the manager will provide. Link the people and resources they will need.

These are suggested goals to discuss, not a timetable every engineer must meet. Hold weekly one-to-ones and keep the monthly check-in notes in the shared plan. If a goal changes, record why and agree what replaces it.

Appendix H: A one-to-one that is not another stand-up

From People. Keep one shared note over time. The report brings the topics they need help with; both people can add to it. Link to a delivery update when it supplies context, so the meeting can spend its time on the question behind it.

Date:What would make this conversation useful today?Something I am pleased with, and why:A decision, concern or obstacle I want to discuss:Feedback I would like, or feedback I want to give:A capability I want to develop:
Agreed next step:What I will do:What my manager will do:Support or context needed:When we will return to this:

At the next meeting, start with anything still owed from the previous one. At least once a month, make room for the person's longer-term direction. They may want to deepen their current work rather than move into a larger role.

When a development topic needs more than a conversation, I would add a small experiment: the current difficulty, what the person will try, what they expect to learn and when we will look at the result together. That is the approach I describe in Rethinking Performance Management.

Appendix I: A feedback and development note

From Giving feedback. Write this as a working note for a conversation. Complete the other person's account with them; do not fill it with guesses about their motives.

The expectation we had agreed:The situation and date:What I observed:The effect on the work or other people:Their account and any context I was missing:What should continue or change:Support, authority or information I need to provide:The next experiment or action:How and when we will review it:

For a later performance review, gather examples across the period rather than copying only the latest note. Include work the manager did not directly see, with the contributor's account and specific feedback from people involved. Keep a development conversation's purpose clear, and state explicitly when a conversation concerns a formal performance decision.

Appendix J: A handover that can be checked

From Habits and Operations. This is the record I would use to understand why an item keeps returning.

• What is the responsibility, and why did it become mine?
• Who will own it, and what decisions can they make?
• What context, access and working instructions do they need?
• Which decisions still need someone else, and who is that person?
• What will we do together once before they take it on?
• What would show that they can carry it without me?
• When will we review the arrangement, and where will we record anything that comes back?

The check should show whether the next person can actually do the work, including knowing when to ask for help.

Appendix K: Meeting agendas

These condense the cadence in Collaboration. Every meeting needs a named owner, preparation and somewhere to record decisions. If an item needs a separate discussion, record who will arrange it and when.

Stand-up

Monday, Wednesday and Friday, 25 minutes. Before the meeting, Owners update expected dates and everyone prepares a one-minute update tied to the goals they own or support.

1. What moved since the last stand-up?
2. What should move before the next one?
3. What help or decision is needed, and from whom?

Use about fifteen minutes for updates and the remaining ten for questions. Move detailed problem-solving to a follow-up with the people involved. Leave the source issue or goal updated, so somebody who missed the call can follow the decision.

All hands

Thursday, 60 minutes. Allow ten minutes for company news, fifteen for demos of shipped goals and fifteen for milestone updates. Leave room for questions, then use the final five minutes of the working agenda to give unresolved items an owner and a date. Our meeting also includes a round of GeoGuessr.

The preparation differs by role: founders bring customer and company changes; Owners bring outcomes to demonstrate and people to recognise; Milestone Leads bring progress, expected dates, risks and decisions needed.

Monthly Planning

First Monday of the month, 90 minutes. I would prepare the current priorities, capacity, customer context and decisions needed, then use this sequence:

1. Review what changed in the product or company that affects priorities.
2. Agree which goals need attention next and what will wait.
3. Name the Sponsor and Owner who will shape each selected goal.
4. Record dependencies and unresolved decisions with a responsible person.

The output is a selection of goals to shape. Detailed planning follows between the Sponsor and Owner, and work starts when the Owner has capacity.

As the company grows

At a startup, I would keep only the fields needed to agree the work and follow it through. As several teams start using a template, I would make cross-team dependencies and decision owners easier to find, and keep a shared definition for fields such as Owner and Sponsor. The useful test is whether someone outside the original team can understand the record and know whom to ask.

Still to write

• A sample list of areas and who has the final say in each.