Nobody Handed Me a Manual

A little over a year ago my title changed. For most of a decade I had built data and AI teams inside a company that already existed: research, pipelines, models, and the occasional long argument about what “done” means. Then a few of us started something new, and I became the CTO.

On the first day the word meant one thing to me: when it breaks, I'm the person responsible. I didn't yet know how many different things “it” would turn out to be.

Doing it again, with people I already trusted

I wrote in the prologue about why I wanted to build again after ten years in one startup. The short version is that I still liked the work, and this opportunity had the things I had learned to look for: funding for the plan, a founding team I trusted, and a market where the people who feel the problem also hold the budget.

It also had something unusual for a company that had not shipped yet. Design partners were waiting for us. Sales channels existed before the product did. Our problem in the first year was not finding someone to sell to. It was building the thing they were waiting for, quickly enough and well enough that the wait was worth it.

That shaped the first decision I made as CTO, which was who to build it with. Most of the engineers I brought in had been on my team before. I knew how they worked, what they were good at, and what they would say when they disagreed with me. I could give one of them a problem and turn my attention elsewhere, trusting that the work would move and that they would come back when it needed a decision.

Trust was the whole point of that choice. With a product waiting to be built and a long list of other things on my desk, I could not be on top of every piece of work, and I did not want a team that needed me to be. I wanted people who would run with something, and who knew me well enough to push back when I was wrong.

Knowing them did not mean the job was the same. We had worked together inside a company with hundreds of people, a product that already existed, and teams around us for everything we did not do. Now there was nothing around us. The kind of engineer a company needs changes with its stage, and I had to be honest with myself about whether the people I trusted were also the people this stage needed. Some of what had made them valuable before mattered less now. Some of what mattered now, they had never had to do.

What carried over was not the role. It was the culture we had built together and the reason we worked. We had never been people who did the job because it was the job. We liked the problem, we liked the people we were solving it with, and we wanted to see where it went. That is what I was really bringing with me: a group who would choose the hard version of this because they found it interesting, and who had already shown me they would.

It was also a responsibility. These people came because I asked them to. If the company does not work, part of that is mine, and I think about it more than I expected to.

Trusting the people turned out to be the easy part. Making the company's rules, tools and habits reflect that trust is harder, and most of this series is about the places where they did not yet.

A fortnight in the job

Here is a sample of what crossed my desk in a recent fortnight, in no particular order:

• A TLS certificate that existed, but in the wrong cloud account, so it could not be used for the thing we needed it for.
• An auditor asking who approved a particular pull request, and why the answer was “nobody”.
• An intercompany invoice between two of our own entities.
• A payroll run, and a VAT return due the same week.
• A forecast of how long our cloud credits would last if we kept spending the way we were.
• A vendor's data-processing terms, read twice.
• A dashboard I built that nobody but me had opened.
• Another conversation about whether we needed a product manager, and what we would be asking that person to fix.

Some of that list has a simpler explanation than a missing job description. The other founders are based in Germany, and I am the one in the UK. Setting up the UK entity was mine. So was finding an office, choosing a pension provider, arranging health insurance, running payroll and submitting VAT returns. I had spent a decade building AI teams and had never registered a company. For the first few months, a surprising share of being the CTO was being the company's only person in the country where it was incorporated.

The rest of the list had no such explanation. None of it was in the job description, because there was no job description. There is a founding team, a product to ship, and a growing list of things that need someone to pick them up. I picked up a lot of them. Sometimes that was necessary. Sometimes it was easier than working out who should own the problem after that afternoon.

I could close a ticket and know I had done something. It was harder to tell whether I had given someone enough context, made a good hiring decision, or helped the team depend on me a little less. The work with an obvious finish line kept winning. I'm still learning how much that preference shaped the job I ended up doing.

I came into this role from the research and machine-learning side. I had never run production infrastructure. I had never been the name on a security policy. I had never submitted a VAT return. I've now done all three, and I would like to write about it before I forget what it felt like.

Why now

I've written before about learning in public, and this series is that idea applied to a role rather than a technology. I want to write these things down while I can still remember why a decision seemed reasonable at the time. Knowing what I know now makes it very easy to pretend I should have known it then.

Some of the changes I describe are still in progress. Some have not been running long enough for me to know whether they work. I will say which is which. I would rather share the question I'm actually dealing with than wait until I can turn it into a tidy lesson.

There is a cost to this. Writing about leading while you are leading is uncomfortable, and some of the people you lead will read it. I'm going to keep names out and keep the lessons in. Where a story involves a teammate, the point of the story is what I did, not what they did.

What the series covers

Each post is built around one thing I got wrong, or half right, and the lesson I took from it. In order:

• A team moving without me is not evidence that I don't belong. I brought people who could run without me, then felt replaced when they picked up work I had left undone. The gap was real. The conclusion was wrong. Imposter Syndrome Is Real.
• Trust is a system, not a feeling. I trusted the team completely, and our repository rules still said that founders pressed the button. What the tooling permits is what people hear. Trust Is a System You Design, coming soon.
• Visibility is not direction. Ten engineers asked for clearer priorities and I answered with a dashboard. The responsibilities a product manager would own do not disappear because you cannot hire one. Building a Team When There Isn't One Yet, coming soon.
• AI multiplies the work. It cannot own the decision. Where an assistant has made a team our size able to do the work of a larger one, and the line between a useful output and a judgement someone has to sign. AI Is a Multiplier, Not a Signature, coming soon.
• A policy is a promise, and someone will check it. Working through SOC 2 and ISO 27001 put sentences I had written next to things we had actually built. A shorter document does not remove the obligation. Compliance Is a Mirror, coming soon.
• Finishing things myself was a comfort, not leadership. The work I kept reaching for, what it crowded out, and what I'm handing over so the team can act without waiting for me. The CTO Who Does Too Much, coming soon.

My first year as CTO has changed how I ask questions, share responsibility and decide where my time belongs. These are the experiences behind those changes, written while the details are still fresh.