Decisions

People need to know what they can decide, what they owe each other and when to involve someone else.

As the company grows

At my first startup, new managers shaped how their teams worked each day. I saw processes carried over from previous jobs without enough thought about whether they suited ours. People covers what changed as early colleagues left and experienced leaders joined.

For a CTO, this reaches into ordinary engineering work. A new person learns how much disagreement is welcome by watching a review. They learn what ownership means when a decision goes badly, and whether an incident leads to useful questions or a search for someone to blame. I would look at those situations when asking whether we are keeping the culture we say we want. A description of our early days gives a new manager very little help with the decision in front of them.

Giving a team room to work

Later in that first company, around Series C, I had the trust and permission to build an AI and research team with more freedom over how it worked. I thought of it as a startup inside the company. We used Notion while the wider organisation used Confluence and Jira, and I defended that choice because I wanted the team to be able to shape its own working environment.

That experience is part of why I wanted to work with many of the same people again. Autonomy made room for learning and exploration, which mattered to the kind of work we were doing. It also required me to be comfortable with choices I would not have made myself. If I reserved the right to substitute my preference whenever I was nearby, their freedom would depend on my absence.

There were still obligations on both sides. I needed to make time for questions and help with unfamiliar trade-offs. People needed to bring me the information that changed a decision or affected someone else's work. When we started again, our shared history helped us get going, but it could not define those obligations for a new company. Someone joining us needed to be able to find those answers without having that shared history.

Close to the customer

Engineers make better decisions when they know whose problem they are solving. That knowledge should not be held by one person and passed on in tickets.

What I am trying now. Much of this is still a draft I put to the team. Leadership explains who each goal is for, what problem it addresses and what finished work looks like. Customer notes are shared, and engineers join those conversations. Every engineer should be able to use and explain the application's main customer journeys, and the Owner, the person responsible for delivery, uses the affected journey end to end, including its failure cases, before calling a change done. Details in Ten Engineers, No Product Manager.

The planning change puts the person supplying customer context and the engineer delivering the goal in the same conversation. That approach is still new; Delivery covers how we are putting it into practice.

Decision-making

A decision needs to look decided

People cannot act on a decision they cannot find. If it lives in scattered conversations, capable people will check with you again, and your absence becomes ambiguous: it might mean the decision is theirs, that you have not seen it, or that you think it is already settled.

For any decision other people build against, they need to know what is settled, what is still open and what a change would mean for their work.

What I am trying now. I proposed that we record decisions where the work lives, and write up decisions made on a call that day. I proposed it before I was doing it reliably myself. An engineer told me our commitment to the new front end had never been formally communicated, when I felt I had said it in every call for a month. It was not yet clear enough to act on. The story is in Trust Is a System You Design.

Who decides what

A new engineer asked whether he could assign himself goals he was already owning in practice, or whether each one had to wait for the planning meeting. He needed to know which decisions were his to make.

A line I heard somewhere has stayed with me:

I own the context; you own the execution.

Whoever sets the direction makes the purpose and constraints available. The person doing the work decides how, and questions the context when it does not add up.

How I do it now. Each goal needs two roles, held by different people.

• The Owner works out how to deliver the goal and makes the implementation decisions inside what was agreed. They do not wait for me on a library choice or the order of their own work.
• The Sponsor explains why the goal matters, is the voice of the product and the customer, and explicitly approves any change to scope.

For that new engineer, taking ownership of an agreed goal did not need another planning meeting. A change to its scope still belonged with the Sponsor.

Beyond a single goal, we also need to name who has the final say in each area. If your goal needs a decision in someone else's area, it is on you to tell them early and get their approval before the decision is final or the affected work starts. The person to involve is whoever owns the area, which is sometimes me and often not.

At our size, the list of people with the final say in each area mostly works through shared context. It used to be something I carried in my head, and I have not yet published it as a table of areas and names. That is a gap I still need to close. An unanswered message does not supply approval.

When I see a reasonable implementation decision I would have made differently, I ask whether new information changes the scope, the risk or a commitment we have already made. If it does, I owe the Owner an explanation. Otherwise the choice stays with them. The two conversations that exposed this problem were about authority and missing context, despite starting with people I already trusted.

Reversible and irreversible decisions

Most decisions can be undone, and those should be made quickly by the person closest to the work. I wrote about this in Making Better Decisions Faster. A choice can be reversible and still need someone else's approval.

How I approached it at a startup. We removed the approval ability from our change-gate pilot after the auditor's review. Delivery covers that correction and the controls we still need to enforce.

Writing and talking

Written context reaches people who were not in the room and can be read at a different time. Our values say we prefer written notes to extended meetings, and that agendas and decisions from a meeting are stored with the minutes.

For AI-assisted writing, our test is that someone has to understand the document, be able to edit it, and leave the next person able to use it. Operations covers how I check that before sharing one.

The first startup had taught me to build that writing habit while the company was small. When everyone shares the same room, it is easy to underestimate how much understanding comes from overhearing a conversation. A later hire or someone working at another time will not have that history. I want a decision record to give them enough of the reason to question it intelligently when the circumstances change. Copying the final instruction without the reason leaves them dependent on someone who remembers.

Ownership has two sides

The roles also depend on how we exchange information. Two German words helped me describe the duties on each side.

• Holschuld, the duty to fetch. What you need to do your job, you go and get: clarity, a decision, context, access, an answer. If something essential is missing, ask before building on an assumption.
• Bringschuld, the duty to deliver. What others need from you, you bring without being asked: a draft, the current state of your goal, a demo, bad news early.

I need to do both. Asking people to fetch missing context does not relieve me of making it available, and sending an update does not replace asking for a decision I need.

How I do it now. Both duties apply to me as much as anyone. The front-end commitment was a Bringschuld I had not met. Silence has a limit as well: an Owner can proceed with an implementation choice inside the agreed scope, but silence cannot supply a scope, area or release approval.

Transparency

Share context by default so people can make good decisions without waiting for permission. Keep confidentiality where it is needed, and avoid “need to know” as a reflex.

How I do it now.

• The one thing in our way of working that is not negotiable is that goals and milestones are always up to date.
• Slack channels are public unless the subject is confidential or sensitive.
• Praise publicly, criticise privately.
• The same rules apply to everyone, whatever their role or seniority. I used the merge bypass too, so that one is a note to myself.

The dashboard became useful in stand-up once it supported an existing conversation. Delivery covers the tooling; here I need a named person responsible for the source information and a clear expectation of when it is updated. Choosing priorities still belongs to us.

Disagreement

When we disagree, we make it about the work and the facts. Our values put it as dissent early and alignment after a decision, and suggest asking “what evidence would change your mind?”

The part that is mine is how I respond when someone challenges me. If I spend the conversation proving I was right, I have missed what they were telling me, and they will think twice before raising the next concern.

When a decision goes badly, I ask what the person knew at the time and whether they had the context and authority we said they had. If ownership lasts only until the first disappointing result, the safe choice next time is to bring every decision back to me.

Making room before I give my answer

There is a practical problem with telling people they can challenge me: I can still make my preferred answer obvious before they have had time to think. I would collect views in writing before a discussion and hear people out before announcing which idea I support. That matters when I want the team's judgement, especially when some people have more experience or authority than others.

For a technical discussion, I would ask people to describe their preferred approach and the uncertainty they see, then read those views before stating my own. During the meeting, I would make room for someone who has been interrupted to finish. A concern about the work needs an answer even when I decide to proceed. Thanking someone for speaking up and then never addressing the concern would leave the useful part undone.

I want to make this routine. Afterwards, I would look at whether I understood the objection and explained the decision, and whether the person still had the authority we had agreed. Silence in a meeting would not tell me how comfortable they felt raising a concern.

Agreements that hold

After a decision, we still need to make the agreed change happen. The review agreement we failed to keep showed me why agreeing to a change was only the start.

For any agreement that matters, I now want to decide how we would know it is being kept, and put that check in the tooling where we can. The review story is in Compliance at AI Speed.

Culture and values

At the first startup, we eventually tried to put the culture into words. An expensive two-day leadership offsite was part of that effort. At one point we had more than 20 values, with phrases such as “be the change you seek” and “act with kindness”. I remember them becoming posters in meeting rooms without doing enough to change how we worked.

I would keep the set small enough that we can explain how we practise each one. If a value says people can own a decision, the working agreement should tell them which decisions. If it says we communicate openly, someone should be able to find why a priority changed. A value that describes something we hope to do needs work behind it before we can treat it as a description of the company.

I find values useful when they say what each side owes the other. Ours are written with three parts each: what the employee is responsible for, what the company is responsible for, and how we do it in practice.

The values I work with now.

1. We are all team leads. The person closest to the work drives it.
2. We support growth and diversity.
3. We are mindful, which includes a sustainable pace and few, timeboxed meetings.
4. We are long-term, end-user focused thinkers committed to the truth.
5. We make an impact with curiosity and courage.
6. We value openness and transparency.
7. We communicate accurately.
8. We pursue excellence and think big.
9. We are humbly creative.

Our working agreement leans most on the first, the sixth and the seventh: ownership by the person closest to the work, shared context, and communication someone can act on without guessing.

Nine is still a substantial list. Writing it down gives us something to examine; it does not demonstrate that we live it.

Still to write

• A published list of areas and who has the final say in each.
• A fuller account of conflict between two people, as opposed to disagreement about a decision.
• Celebration and fun. Our milestones are deliberately small so there are wins to mark during a project, and I have not yet written about how well that works.