A Year In, the Job Looks Different

During my first year as CTO, I hired engineers, set the initial architecture and built the front end. I also set up a UK company, ran payroll and found myself responsible for security policies. There was a product to build and a company around it that needed to work.

Those were real parts of the job. We had no front-end engineer at the start. The UK entity needed someone to get it running. A small founding team cannot wait until every responsibility has a specialist before doing the work.

Looking back, the harder part was recognising when the arrangement needed to change. Something I took on because nobody else could do it could remain mine long after that reason had gone. A decision I could explain in a conversation became harder to carry as more people built against it. The way we started was useful. It needed to evolve with the team and the product.

Some work was mine until we could hand it over

The front end is the clearest example. Building it myself helped us get started. When we could hire for it, I handed it over. The company still needed that work, and now someone else could own it. That gave me room to spend more time on decisions affecting the rest of the product.

Other responsibilities have been harder to place. We still don't have a product manager, so the product work remains with the founders. We have to stay close to customers, choose priorities and explain what we want a piece of work to achieve. I started writing those obligations down because leaving the role unfilled could not mean leaving the work unowned.

Those two situations need different responses. For the front end, we could hire and transfer ownership. For product work, we needed to make the responsibilities within the existing team clearer. “Delegate more” would not have answered both.

I still expect to build things. Sometimes that is the most useful contribution I can make. I also keep a list of work I should hand over, and a log of work that came back to me. That helps me notice when a temporary arrangement has quietly become permanent. Then I can look at what is missing: a person, access, context, authority or time to make the handover properly.

The team needed a different kind of involvement

I had brought in people I trusted and set a technical direction. As they built, their understanding of individual parts became deeper than mine. Meanwhile, I held context from customer and founder conversations they hadn't been in. Both kinds of knowledge were necessary, and neither was reaching the other reliably.

Asking the engineers to explain how their parts of the system worked helped me regain the wider picture. It also helped with the feeling that I should already know everything. I could ask about a gap and do something with the answer. Their expertise made that possible.

I needed to make my side of that exchange more dependable too. The team needed to know which customer problem mattered, why a priority had changed and which decisions they could make themselves. Hiring capable people didn't make those answers obvious.

We put Owner and Sponsor roles into our working agreement. The Owner takes responsibility for delivery. The Sponsor supplies the product context and approves scope changes. When I am the Sponsor, that gives me a useful way to stay involved: help shape the goal, answer when the scope no longer fits and leave the implementation decisions with its Owner.

Writing that context down matters. I had seen at Beamery how much shared documentation helps a team grow. Here, it gives someone working at a different time or in a different place access to a decision without needing me on a call. It also gives them something specific to question when the decision stops making sense.

That is a more useful relationship than either trying to follow every detail or assuming everyone has enough context because I trust them.

We got further when we could see what needed changing

Our planning changed when design partners brought real data into the product. The tidy assumptions in the prototype stopped being enough. Moving from monthly plans to two-week cycles gave us an earlier point to find out what worked and adjust.

We later tried to plan the whole three months before launch and made it difficult again. The newer planning rules keep the longer-term direction while bringing the Sponsor and Owner together to shape the next goals. We can agree what we are trying to achieve without pretending we know every step months ahead.

I see a similar change in how I think about tools. The dashboard I built became useful to the team when it showed goal status for stand-up. That gave it a job in a conversation we were already having. Building another view had been easy; working out how it would help someone make a decision took longer.

AI gives us much more room to build and experiment. I want to keep using that. It helped us move quickly, and it helps me with preparation and unfamiliar work around the code. As the volume of changes grew, we also had to make review and release responsibilities clearer.

With compliance, that meant separating critical repositories from experiments, changing the review model and checking whether our tools enforced the rules we had written. Some changes were straightforward, like turning on a missing repository setting. Others are still being implemented. Having an owner and a concrete change to make is much more useful than treating a finished policy as finished work.

I don't expect the latest arrangements to last forever. I do want us to be able to say what isn't working, understand why and change it without starting from scratch every time.

What I want to carry into the next year

I have a clearer idea now of where my attention is needed. I need enough technical understanding to see when choices in different parts of the product conflict. I need to help the founders turn customer needs into priorities the team can act on. Hiring, difficult tradeoffs and questions that cross responsibilities need time of their own in my week.

I also need to keep making ownership practical. For review, the board and the meetings I want to hand over, naming someone is only a start. They need the information and authority to carry the responsibility, and a way to get help when a decision exceeds it. Those handovers are still in progress; the front end showed me what completing one can free up.

We have a team, a product being shaped by real customer data, clearer decision roles and processes we have changed when they stopped helping. There are unfinished parts, but I can describe what needs to happen next much more clearly than I could at the start.

When I took the role, being responsible meant being the person who would pick something up when it needed doing. I still need to be willing to do that. Now I also need to decide how that work should be owned after the immediate problem is solved.

I came back to a startup because I wanted to build with these people and give them room to grow. The next year needs to make more of that possible: people shaping goals with the context they need, making decisions they have the authority to make and bringing me the questions we need to settle together. That is the team I want to keep building, and the job I want to make time for.

A few useful reads

• Lara Hogan, When to delegate, when to say no. The exercise I used to sort my own commitments and work out which responsibilities needed to move.
• Will Larson, Work on what matters. Useful when deciding where technical involvement will help most as the team changes.
• Charity Majors, The Engineer/Manager Pendulum. On staying close to technical work as your responsibilities change.