The Lever Most CTOs Reach for First Isn't the One Attached to Delivery

Board pressure to show a return on AI spend tends to produce the same first move: push the AI lever harder. Broader adoption mandates, closer usage tracking, another round of token capacity bought to keep the accelerated pace going — all of it gets folded into whatever the board already reads as progress. It’s a reasonable instinct: that lever sits within the CTO’s direct authority, it’s visible enough to explain in a single slide, and it produces a number that looks like movement. I notice, though, that continued investment in that direction mostly adds capacity to one stage of the system — the coding itself — while, as I’ve written before, introducing a variability of its own that most planning doesn’t account for. For a good number of scaling organisations, pulling the lever harder barely moves the outcome the board actually cares about.

Not every point where you can intervene in a system carries the same weight. Some levers are easy to reach and produce almost nothing when pulled. Others sit further from view and can ripple through far more of the system when they shift. Ease of reach doesn’t reliably predict which is which. I find the real skill lies in tracing a lever’s first- and second-order effects before pulling it, rather than assuming the one within easy reach is either sufficient or beside the point.

However, I find the AI-adoption lever is almost always the easy one. The lever that actually governs delivery at scale is closer to decision rights — who is formally authorised to resolve a conflict between two squads’ priorities, who owns an architectural boundary that both teams have quietly assumed belongs to the other. That structure existed before AI. It just wasn’t under much strain, because the volume of decisions arriving into it was manageable.

AI changes the arrival rate, not the structure. Two teams can now each produce a working implementation against an API contract that neither has formally confirmed, in a fraction of the time it once took — and the mismatch surfaces sooner, more often, and with more code already built on top of it. Every one of those mismatches needs someone with the authority to resolve it. If that authority was never made explicit, each one becomes an escalation, a stalled PR, a conversation that has to happen before either team can safely proceed.

Here is where the instinctive fix goes astray. Facing that friction, the response is usually to go for more of the visible lever — tighter AI usage mandates, more granular velocity tracking, pressure to “align better” without specifying how. None of that touches decision rights, because decision rights are harder to redesign than a dashboard is to build. It requires deciding, explicitly, who owns what — which is precisely the kind of organisational work that easy levers let you avoid.

Finally, I feel I have to stress this again: None of this argues against AI adoption. It argues for checking, before applying more pressure to the lever you can already reach, whether that lever was ever connected to the constraint. I’ve written before about where the bottleneck actually tends to sit at scale — this is the governance layer underneath that same observation: knowing the constraint isn’t coding is only useful once you’ve found the lever that’s actually attached to it.

If you’re ready to go further, let’s explore how clarifying decision rights across your scaling teams can work for your organisation. Reach out today, and let’s find the lever that’s actually connected to the constraint.