Habits

My week moves between engineering, planning and running the company. These are the habits I use to keep track of that work, along with a few I want to make more dependable. Most came from a specific thing going wrong.

Notice when your job has changed

At the first startup, I had work I understood well and room to build a specialist team. I knew where people were stuck and how their work connected. Starting again changed the work around me much faster than it changed what I reached for each morning. I took on the front end because we had nobody else to build it, alongside setting up the company in the UK.

Both helped us get started. Later, those responsibilities still occupied me while the engineers waited for clearer priorities. My commit history showed plenty of technical involvement. It did not show that I was losing my understanding of how the rest of the system fitted together, or that I held customer context the team needed.

Being busy was a poor way to judge whether I was doing the work the company now needed from me. The useful clues were more specific: a responsibility I still held after we could give it to someone else, or a decision an engineer had to make because I had left it open. My first year as CTO gave me plenty of those clues.

I want to notice a change in the job before waiting for frustration to make it obvious. For someone early in a startup, that may mean learning to lead people they used to work alongside. For me, it meant making time for the context and decisions the growing team needed, while staying close enough to engineering to be useful.

Keep lists of what actually happened

A general feeling of being behind is hard to act on. A list of specific entries is not. When I write down what went wrong, most entries turn out to be small enough to do something about this week.

How I do it now

I keep three lists.

• Work I should hand over. Things I took on because nobody else could at the time. Each one needs a person who can own it, with the access, context and authority to do so.
• Work that came back to me. When something I handed over returns, I write it down and ask what was missing from the handover: a person, access, context, authority or time to do it properly.
• Things I got wrong and gaps I found. A missing decision becomes a conversation to have this week. A missing fact becomes a note.

Reading the first two together is how I notice that a temporary arrangement has become permanent. The third is shorter than the voice in my head suggests; I wrote about that voice in Imposter Syndrome Is Real. To sort my commitments in the first place I used the exercise in Lara Hogan's When to delegate, when to say no.

I handed over the front end once we hired someone to own it. That gave me room for decisions affecting the rest of the product. Product work was different: we still had no product manager, so the founders needed to make their responsibilities clearer. I would handle an entry in the first list differently depending on which situation it describes. Sometimes I need a person. Sometimes I need to give the existing owner the missing authority or context. Writing “delegate” beside both would hide the decision I still had to make.

Notice what went well

A list of mistakes leaves out the work that helped. Alongside it, I would keep a few specific notes about what went well and who contributed. That could be a colleague explaining an unfamiliar part of the system or taking responsibility for a problem that needed attention.

I have sometimes treated an engineer's initiative as evidence of something I should already have done. I can address that gap and still recognise what they contributed.

I would use those notes to thank the person directly, naming what they did and how it helped. The Recognition section in People covers how I would carry that into managing a team.

The second time, write it down

If I do a piece of work twice, the third time should start from instructions. Writing them takes longer than doing the work once more. It pays back when someone else can follow them, including an AI assistant, and when the task stops depending on my memory of how it went last time.

How I do it now

When work repeats, I write down what to look at, what to do with it, and which decisions need to come back to me. An assistant can follow that procedure and I can inspect the result. The same document makes the task easier to hand to a person.

If I keep repeating a decision, it needs to be written where people can find it.

I would write the instructions with the next person in mind. They need enough context to know when the procedure applies and when to stop and ask. A list of steps that only works because I remember the exceptions is not ready to hand over. When a task comes back, I can use the gap to improve the instructions instead of expecting the next person to infer what I left out.

Close the loop on what you promised

Writing down a decision helps people find it; a question I have promised to answer still needs me to respond. If I promise an answer, I need to come back with it, or say why I cannot yet and when I will. The same applies when I decide not to act on a concern. An unanswered question leaves someone guessing whether I heard it at all, and they are less likely to raise the next one.

What I am trying now

In a draft on product ownership I proposed a response time of one working day for a scope question, a concern or a draft. In return, the engineer brings what they understand, what is missing and a recommendation. It is a proposal the team can challenge, and I have to make the time to keep my side of it. Asking people to raise uncertainty early makes little sense if their questions then sit unanswered.

An answer does not always mean the decision is ready. I can explain what I am waiting for and when I will return to it. That gives the other person something to plan around.

Arrive prepared, then pay attention

A one-to-one is one place to check those commitments together. Keep a shared agenda, let the employee's concerns shape the conversation, and refer back to what was agreed. Arrive on time and give the person your attention. Those are small obligations, but they make the scheduled time usable.

I would start by reading the previous notes before the meeting. If I promised to find information, arrange access or make a decision, I should bring the answer or explain what happened. The other person should not need to use their time reminding me of my own commitment. Then I want enough room for what has changed since the agenda was written.

For a CTO, there is a particular temptation to take a conversation straight into solving the technical problem. I would ask what the person has tried, where they need a decision and what help they want from me. If the issue is missing authority or an unanswered product question, another implementation idea will not resolve it.

I would finish with a short record of what each of us will do and when we will return to it. This is the practice I want to make dependable within the meeting cadence.

Ask for help with what you do not know

A CTO is responsible for decisions across subjects they are not expert in. I need enough understanding to question an approach, see where it affects someone else's work and recognise when I need help. Trying to be equally good at every specialist's job would leave less time for mine.

How I approached it at a startup

I told the team that I had been further from the implementation than I wanted to be and did not have the end-to-end understanding many of them had. Then I asked each person to write down how their part of the system worked. Those explanations were the start of the wider picture coming back, and saying it out loud helped quiet the voice that told me I should already know.

I need to keep learning separate from taking work back. I needed to understand how the parts connected so I could help with decisions affecting the whole product. The engineers still owned their parts. Asking them to explain a choice did not mean I should become its approver or reproduce their expertise before they could continue.

I value time to explore because it has been a large part of the work I enjoy. Trust made that possible in the team I built before, and it is one reason I chose to work with many of those people again. I owe them the same room now. When I need help understanding the system, I can ask for an explanation without treating every hour spent investigating something unfamiliar as a delivery problem.

Use an assistant for the reading around a decision

The job keeps pulling me into subjects I do not know well. Before a decision I need to understand what already exists, where the relevant information is and which question is still open. An assistant is good at bringing that together, provided I can check it.

How I do it now

I ask for links back to the files or records it used, so I can open the source behind a claim. I ask it to explain the part I do not understand, and sometimes to challenge an assumption while I am still working out what I think. Deciding whether the result does the job stays with me: whether the explanation holds up against its sources, or the fix addresses the problem. More in AI Is a Multiplier, Not a Signature.

The same care is needed when the assistant helps me write something for the team. I need to read the result before asking anyone else to spend time on it, check the claims and remove the explanation that does not help them act. If the draft makes an unresolved question sound decided, editing it means restoring the uncertainty. A polished answer is a poor substitute for telling the team what is still open.

I also need to be able to explain the diagrams and recommendations I share. That is a useful test of whether the assistant has helped me understand the work or merely given me something plausible to circulate. The next person should be able to find the decision and its reasoning without having to work through the whole conversation that produced it.

Protect time for the work only you can do

Technical work is easy to reach for. I can close a ticket and know I did something. It is harder to tell whether I gave someone enough context or made a good hiring decision, and that kind of work gets pushed out unless it has time of its own.

How I do it now

Hiring, difficult tradeoffs and questions that cross responsibilities need time of their own in my week. I still build things, and sometimes that is the most useful contribution I can make. I try to notice when building has become the thing I do while a harder decision waits.

On the company side, our norms help: we set a Slack status for focus time, and a rule of thumb is that if you do not expect to respond within about an hour, you say so.

Pay attention to what gives you energy

One way to examine that use of time is to look back over a recent week in the calendar and note which activities gave you energy and which drained it. I would look for a pattern across the week, then choose something to change and see whether it helps.

If an engineering session leaves me absorbed and a difficult staffing conversation leaves me tired, both may still need my attention. I would consider the importance of the work alongside how it felt, and ask whether the difficulty came from the task itself, missing context or too many interruptions. That gives me something more useful to change than simply trying to fill the week with work I enjoy.

I signed up for the company-building work too. A draining task may still be mine to do. Where it repeats, I would look at whether better preparation, a written procedure or a later handover could make it easier to carry. I would check any proposed handover against the lists above: who can take responsibility, and what do they need from me?

Make the pace sustainable

In the same account of self-doubt, I wrote that I would be glad to do the work with less exhaustion. I do not want to treat feeling out of my depth as a requirement for growing into the role.

A plan that depends on me being available every evening needs another look. I would start by agreeing how an urgent problem reaches me, what can wait and who can act when I am away. The support and escalation arrangements need to be clear enough for someone else to use them.

I would also leave room for rest and life outside work when planning the week. If routine work repeatedly takes that time, I would bring the workload and coverage back into the planning conversation. I would check those arrangements when planning time away, so we can resolve missing access or unclear decisions before someone has to cover for me.

As the company grows

At a startup, my handover list starts with work I took on because we had nobody else to do it. In a scale-up, I would use the same list to check which decisions still depend on me after someone else has taken responsibility. I would ask whether they need my judgement or whether I have left them without context or authority. The list of work that came back would help me check that distinction.

Write in public

I write to work out what I think and to give someone else the chance to correct me. Writing about a mistake makes me explain what I misread. See Why I Write and Learning in Public.

Still to write

• How I run my inbox and task list day to day. I do not have a method I would recommend yet.
• What I learn from trying a regular energy review, including which changes help and which responsibilities still need my attention.
• Health and sustainable hours in practice. Our values say we are in it for the long run; I still need a fuller account of how I make room for that.