The job is velocity in a direction.

Most writing about the CTO job is a list. A list of responsibilities, a list of skills, a list of things that went wrong at someone else’s company. Lists are comforting because they suggest that if you tick every box, you’ll be safe.

You won’t. The job isn’t ticking boxes. And it isn’t being the fastest person in the room, either — the speed comes from the team, not the leader. The job is building the balance and the structure that let the organisation move the right way, faster than the problems can pile up. Velocity in a direction is the outcome. Balance and structure are the work.

That job description hides three claims, and the rest of this page is an argument for them. They are the three parts of the operating model — Balance, Guardrails, Measurement — the same three-part shape as the kinds of work (Build, Run, Plan) and the levers (Team, Tools, Techniques):

1. Balance — spreading your effort beats focusing it. The thing slowing you down is rarely the thing you’re staring at.
2. Guardrails — build safety in; don’t slow things down. Speed comes from deciding ahead of time which decisions don’t need you at all.
3. Measurement — measuring is the actual work. You can’t steer what you can’t see — and seeing is exactly what AI now makes almost free.

Each is a little against-the-grain on its own. Together they form a loop, and the loop is the point.

1. Balance — spreading your effort beats focusing it

Every team is doing three kinds of work at once. Build — making new things. Run — keeping what already exists working, safe, and affordable. Plan — connecting the technology to the business that pays for it.

The instinct, especially under pressure, is to pick one and pour everything into it. The board wants features, so Build gets the people and Run gets the scraps. Or an outage scares everyone, so Run gets all the attention and the roadmap quietly stalls. This feels like being decisive. It’s actually the most common way technical teams slow themselves down.

Here’s why: the three kinds of work are connected, and the connections are where speed leaks away. A team that starves Run doesn’t move faster on Build — it moves slower, because every outage interrupts the new work and every shaky system makes every change harder. A team that starves Plan ships plenty, in the wrong direction, and finds out six months later.

So the discipline isn’t focus. It’s noticing which of the three is currently holding you back, fixing that, and moving on before it becomes a crisis. A team moves at the speed of its slowest necessary part — and the slowest part keeps changing.

A useful way to make this concrete is to cross the three kinds of work with the three things you actually control — Team, Tools, Techniques — which gives you a grid of nine boxes where effort can go. The grid matters less than the habit it builds: before you spend, work out honestly where the problem really is. Most expensive mistakes in this job come from fixing the wrong kind of problem — buying a tool to fix what’s really a people problem, reshuffling the team to fix what’s really a process problem.

And every box has two ways to be wrong, not one. A box can be starved — and a box can be overfed: meetings multiplying because planning feels like progress, an architecture built for a scale that never came, a process so heavy nothing ships. Overfeeding is harder to spot because it looks like diligence. The honest question isn’t “where do we need more?” It’s “which box is at the wrong level — and in which direction?”

2. Guardrails — build safety in; don’t slow things down

Here’s the trap every capable leader walks into: you’re good at decisions, so decisions come to you, so you become the place decisions go to wait. Your judgement — the thing that made you valuable — becomes the bottleneck. Adding more of your attention doesn’t fix it; it makes everyone depend on you more.

The way out is to stop asking who decides and start asking what kind of decision is this. Most decisions can be undone. If you’re wrong, you walk it back, and the cost is small and quick. For those, the only sensible rule is: decide fast, let whoever is closest decide, and don’t send it up to you at all. A few decisions genuinely can’t be undone — they’re expensive to get wrong and there’s no walking them back. Those deserve to slow down. Those deserve a real stop sign.

And that doesn’t mean the CTO draws every line personally — that just recreates the bottleneck one level up. It works in layers: from the CTO down, each layer sets the guardrails for the layer below it, inside the limits set above. You draw the outermost lines and hold them; your leads draw the next set within yours; a team that knows its limits writes its own working rules inside those.

Generic advice tells you to “empower your team” and “delegate.” That’s a nice feeling, not a method. The method is sorting: be clear about the big pile of decisions that can be undone, defend the small pile that can’t, and write the lines down at every layer so people can act without asking. Speed isn’t the enemy of safety. Being fuzzy about which decisions need safety is the enemy of both.

3. Measurement — measuring is the actual work

You can’t steer what you can’t see, and most technical teams are flying blind in ways they’ve stopped noticing. They know their revenue to the dollar and how often they ship not at all. They can tell you last quarter’s headcount but not whether outages are getting more or less frequent. They decide where to invest based on whoever argued most recently and most loudly.

The fix is to treat measuring not as paperwork but as a main part of the job. Measuring is what turns opinion into something you can actually see. And which way you’re heading — not where you happen to be right now — is what should drive your decisions. A capability that’s mediocre but improving is a completely different problem from one that’s strong but slipping, and you can’t tell them apart from a single snapshot.

This is also, concretely, where AI earns its keep in a technical team right now. Not by replacing the judgement — the judgement is yours — but by making it cheap to see. The expensive, neglected work of measuring — pulling the signals together, noticing what moved, spotting what’s slipping before it becomes an outage — is exactly the work AI now makes almost free.

And here’s the part that takes the pressure off: the team doesn’t have to be perfect. It has to be heading the right way. Perfection is a snapshot, and snapshots go stale. A direction you can hold is worth more than a peak you can’t.

Why the three are really one argument

Read on their own, these look like three separate tips. They’re not. They’re one machine with three moving parts — Balance, Guardrails, Measurement.

You measure so you know which of Build, Run, and Plan is actually holding you back — otherwise “spread your effort” is just guessing. You build guardrails so the team can act on what the measuring reveals without waiting in line at your door — otherwise speed dies in the gap between knowing and doing. And you keep the three kinds of work in balance so the speed you’ve unlocked doesn’t quietly burn down the system that produces it.

One caution about the word direction: it isn’t a fourth thing to work on. You can’t buy it, staff it, or put it on the roadmap. Direction is what the whole grid looks like when the boxes are at the right levels and pointed at the same goal — the property that emerges when the system is aligned.

The job, stripped of its lists, is this: build the balance and the structure that keep the team pointed somewhere worth going and moving faster than the problems can pile up. The team supplies the speed; you supply the system that makes the speed safe and aims it. Velocity in a direction — heading the right way, and moving fast — is what it looks like when that system is working. Everything else is just a way to build it.