When you need a CTO, and when you just need a developer

Somewhere in your company there is a list of technical decisions waiting to be made. The question that matters is not “do we need someone technical?” — you probably do — but which kind of decision is at the top of that list. Get that wrong and you either pay leadership rates for feature work, or, more expensively, let feature-rate thinking make leadership-grade decisions.

I’ve sat on both sides of this. I’ve been the developer shipping the feature, and I’ve led a team of six engineers at a UK-regulated gambling company, where the cost of a casual decision arrives later with a compliance bill attached. The difference between the two jobs is not intelligence or seniority. It is the kind of decision each one exists to make.

Two kinds of decision

A useful test, borrowed from Amazon’s vocabulary: is the decision a door you can walk back through?

Two-way doors are reversible. The button colour, the copy, this sprint’s feature, most bug fixes, most refactors. If it’s wrong, you change it next week and the cost is next week. This is developer work, and good developers make hundreds of these calls without ceremony. You want throughput here, not deliberation.

One-way doors are the decisions you will still be living with in three years. The core stack. The data model. Build versus buy for the system your business runs on. Whether the first engineering hire is a senior generalist or two juniors. What you promise customers about their data. Whether the AI feature is a real capability or a demo wearing a product’s clothes. These decisions are cheap to make and brutal to unmake — and they are usually made early, quickly, and by whoever happens to be in the room.

A CTO — full-time, fractional, or a co-founder who grew into it — is the person whose actual job is the one-way doors. Not because developers can’t think at that level, but because someone has to be accountable for it, and accountable means: they asked what the business needs, they wrote the reasoning down, and they are still there when the consequences arrive.

The signs you need the one-way-door person

You can observe these without being technical. That’s rather the point.

You’re comparing agency quotes you can’t evaluate. Three proposals, one says four weeks, one says four months, one is triple the price of the others, and every conversation ends with you nodding at words you’d struggle to define. The quotes aren’t really the problem. The problem is that nobody on your side of the table can tell which one is lying, including by accident.

Your roadmap is whatever was last suggested. If the technical plan changes depending on which developer you spoke to most recently, you don’t have a technical plan. You have a sequence of enthusiasms.

Investors ask questions you relay rather than answer. “What’s your moat on the data side?” “Why this stack?” “What does the next hire unlock?” If your answer is “I’ll ask the dev team”, a fund hears the true answer, which is that nobody owns it.

You’re about to make your first engineering hire. This is the one-way door founders most reliably walk through backwards. The first hire sets the culture, the review bar, and — because they’ll choose the tools — half the architecture. Hiring them without technical leadership in the loop means the most junior technical judgement in the company is making its most durable technical decision.

“We should do something with AI” has appeared in a board minute. And it has no owner, no budget, no kill criterion — just a sense that everyone else is doing it. That sentence, left unowned, becomes either an expensive pilot that dies quietly or a vendor contract that outlives its usefulness.

The signs you don’t

Honesty cuts the other way too. Plenty of companies are told they need CTO-level help when what they need is hands.

• The big decisions are made and holding. Stack chosen, architecture stable, data model boring in the good way. What’s left is a backlog. Hire builders.
• The work is well-specified. If you can write down what done looks like and be right, a good developer or a small agency will get you there without a technical executive watching.
• You already have the judgement in-house. A strong senior engineer who reads the business well is, functionally, most of a CTO. Give them the mandate before you give an outsider a title.

The failure mode in this direction is real but cheaper: you pay someone to think when you needed someone to type. The failure mode in the other direction compounds for years.

Why the title got confusing

“CTO” now covers a person managing four hundred engineers at a bank and a freelancer who built your app and put the title in their email signature. Agencies sell “CTO-level oversight” as a line item. None of this is necessarily dishonest, but it does mean the title tells you almost nothing.

So ignore the title and ask the person — whoever they are — one question about a decision you’re facing: “What would make this the wrong call?” Someone doing the one-way-door job answers with trade-offs, costs, and the conditions under which they’d reverse. Someone doing the feature job answers with how they’d build it. Both answers are useful. They are answers to different questions, and only one of them is the question a company bets itself on.

What getting it wrong actually costs

The reason to care about the distinction is that its two failure modes are priced differently.

Buying judgement when you needed throughput costs you a salary-shaped number and some frustration. It is visible, it shows up within months, and you can correct it.

Buying throughput when you needed judgement is the expensive one, because the bill arrives late and compounds. The classic shapes: the rebuild tax — a first version built fast on unexamined foundations, which the second team (there is always a second team) recommends rewriting, so you pay for the product twice and lose a year; the stuck codebase — velocity that halves every quarter because nobody was accountable for keeping change cheap, until features that took days take months and nobody can say why; and the inherited decision — a vendor contract, a data model, a platform choice made casually in month two that quietly dictates what the company can build in year three. None of these announce themselves as technical-leadership failures. They present as “development is slow”, long after the decision that caused them stopped being visible.

That asymmetry is the practical rule: when in doubt about which kind of help you need, price the mistake in each direction first.

Five questions for whoever you’re about to trust

Whether it’s a prospective CTO, a fractional advisor, a senior first hire, or the agency’s “technical lead”, the same short interview works — and none of it requires you to judge code:

1. “What would make this the wrong call?” — the one-way-door test from above. You’re listening for trade-offs and reversal conditions, not a build plan.
2. “What have you shipped that I can touch?” — not led, not overseen: shipped. Judgement without shipping drifts into slideware.
3. “What would you refuse to build for us?” — anyone worth trusting has a no. If everything you suggest is a great idea, you are talking to a salesperson.
4. “Walk me through a decision you got wrong.” — you learn more from the post-mortem than the highlight reel, and whether they blame circumstances or reasoning.
5. “If we stopped working together in six months, what would I be left holding?” — the handover answer. Vague here means dependent later.

Good answers to these correlate with good one-way-door decisions far better than titles do.

What to do about it

If the signs point at the one-way doors, the options in rough order of commitment: give the mandate to a senior engineer you already trust; bring in part-time or fractional leadership for the days-per-week the decisions actually need; or hire a full-time CTO — which is the right call precisely when the decisions have become a full-time stream, and an expensive vanity before then. A genuine technical leader will happily tell you which of those you are, including when the answer earns them nothing.

The pattern behind all of it: pay for judgement where decisions are irreversible, and pay for throughput where they aren’t. Most technical budgets go wrong by buying one and hoping it comes with the other for free.

Drizzlelabs is an independent software studio in Bristol — the tools in the footer are the working proof, and the about page has the longer story.