From CTO to transformation partner

Here is a question worth asking before you hire your next CTO, or accept your next CTO job.

What does that person do in year three?

The traditional answer has a shape everybody recognizes. Year one is learning the system and earning the right to touch it. Year two is the big rebuild, the replatform, the reorg, the thing they were hired for. Year three is delivery and scale. Year four is running what they built, and somewhere in there they either get a bigger remit or start looking.

That shape was not a law of nature. It was a consequence of how long it took to build software. That clock has just been broken, and almost nobody has updated the job description.

The four-year shape was priced on build time

I run an engineering organization, and I also take a small number of transformation engagements. I have stopped thinking of those as two different jobs, and this is why.

We recently built an order management system in two months with two developers. Not a prototype, the real one, with reviews going from 3.6 to 4.2 stars afterward. The last time I scoped a piece of work like that with a traditional team, it was most of a year and most of a squad.

We took search in-house. It had been 2.45 seconds, and it now runs under 300 ms, which took roughly $200,000 a year off a vendor bill. That project would not have been approved two years ago, because the estimate would have killed it in the meeting.

Look at what that does to the four-year plan. The rebuild you were hired for is not a three-year program anymore. It is a nine-month one. The reorg lands faster. The migration lands faster. The thing that was supposed to define your tenure is finished before your second annual review.

That is a good problem, but it is a problem. Because the job as traditionally defined is now mostly done, and there are two and a half years left on the plan.

The caretaker trap

What usually fills that gap is maintenance. Keep the lights on, keep the roadmap moving, keep the team stable, do a smaller version of the same thing again next year.

That was a respectable job for 20 years. It is a dangerous one now, for a specific reason: a technology function whose main output is continuity is a cost center, and cost centers get squeezed, absorbed or outsourced. If the interesting work is done and the remaining work is running it, the organization eventually notices that running it is not what it needed a senior technologist for.

I have never actually done that job, and I did not plan it that way. Every role I have held was a transformation. Taking the first online children's clothing store in the Netherlands live in 2001 and growing it past a million in revenue on organic search alone. Fifty-plus commerce builds and a procurement system used by Philip Morris, Nestle, and Bayern Munich. Getting review stickers to more than 280,000 hotels in six weeks for Booking.com. A rebrand and a full platform migration in two months with three people, which I do not recommend but would do again. Five years at a luxury retailer in the Gulf where the team went from 18 to 53 across three countries, the app went from converting at 0.9% to over 4%, and revenue grew roughly 10x.

The pattern is not that I like change. It is that every time the change finished, the job changed with it, or I would have been doing something else.

What did not get faster?

Now the useful part, because this is where the new job description comes from.

Agents collapsed the cost of building. They did not touch four other things, and all four got harder as a result.

Deciding what to build. When shipping was slow, the roadmap was self-limiting, and a bad idea cost you a quarter before it hurt. Now you can build the wrong thing three times in the time it used to take to build it once. The scarce skill is knowing which work is worth doing, and that skill has no automated version.

Keeping quality up while volume goes up. More output means more surface, more review load, more places for something to rot quietly. Left alone, this is where the whole gain leaks back out.

Changing what people do for a living. An engineer who spent fifteen years being the person who could write the tricky part now gets judged on how well they specify and review. That is a genuine loss for some of them, and handling it as a training issue is how you lose the best ones.

Proving you run it responsibly. Under the AI Act, and increasingly in every enterprise procurement questionnaire, someone will ask what AI you use, who reviews it, and what you decided. That answer has to exist as a record, not as a memory.

Read those four back. None of them is a building problem. All of them are transformation problems. Which means the part of the CTO job that automation removed was the part that used to justify the org chart, and the part that is left is the part that changes how the company works.

That is not a smaller job. It is a harder one, and it does not finish.

The job that is left

Concretely, here is what that looks like in practice, from the work I am doing now.

We stopped giving engineers individual AI licenses and built one shared harness everybody works through, versioned in the repo like code. Development speed went up 4x, and bugs went down 28%.

The first phase of that harness is product work, done with the product manager rather than for them, and its output is a state file committed alongside the code. The specification stops being a memory or a meeting and becomes a versioned artifact.

Review is split. The engine does the mechanical first pass, a human always approves, and because the boring part is finished before anyone opens the pull request, review went from a queue to minutes.

Quality is measured with a fixed set of real cases scored the same way every time, so we can tell whether something works rather than whether it demos well.

And the compliance record falls out of that. What we run, who reviews it, what we decided. Not a binder somebody maintains, a by-product of working properly.

None of that is a project with an end date. It is a function. Somebody has to own it permanently, keep it current as the tools change every few months, and keep dragging the organization through the next version of itself. That is transformation partner work, and the person best placed to do it is usually the one already in the chair.

What the four-year tenure was right about

I am not arguing for churn. Replacing your CTO every 18 months is a terrible idea, and most of the damage I have been hired to repair was caused by exactly that.

Continuity of person is valuable and hard to replace. Trust with the board takes years. Knowing why the weird thing in the billing system is weird takes years. Being present for the consequences of your own decisions is the only thing that makes a technologist honest, which is also why I would be skeptical of anyone selling AI advice who has not run anything since 2019.

So keep the person. What you cannot keep is the mode. The failure is not a long tenure; it is a long tenure spent doing the same job the whole way through. Continuity of person, discontinuity of work.

If you are hiring one

Change the spec.

Most CTO briefs still describe a caretaker in disguise: has run a team of this size, in this sector, on this stack, for this many years. That describes someone who successfully maintained a situation.

Ask instead how many times they have changed the way a team works, and what it cost them. Ask what they killed. Someone who has never canceled their own project has either been lucky or has not been paying attention. I spent 2025 validating three ideas at Antler and killed two of them for commercial reasons, and that is a more useful thing to know about me than any stack on my CV.

Ask what they handed over, and whether it survived without them. Building something nobody else can run is not a strength.

And ask when they last shipped. Not managed a shipment, shipped.

If you are one

The uncomfortable version of this post is that the caretaker job is quietly disappearing, and the people holding it will feel it as budget pressure rather than as a role change, which makes it hard to see in time.

The good news is that the escape is not a career change. It is the same chair with a different job in it. Stop measuring yourself by what your team built this year and start measuring by what your team can now do that it could not do last year. Those are very different numbers, and only one of them keeps mattering.

Where to start

Take one workflow. Time it end to end and mark every hour as working or waiting. Then ask what your team would attempt if that workflow were four times faster, and notice how many of the answers are things you have already written off as too expensive.

That list is your actual roadmap now. It is also the fastest way to find out whether your technology function is in transformation mode or maintenance mode.

If you want a hand making that shift stick, that is the work I do.