Governance
The CTO's dilemma: speed today or speed tomorrow
Every technology leader is asked to move faster. The hard part is knowing which kind of fast you're being asked for.
Ask any board what they want from engineering and the answer is some version of faster. It sounds like a single request. It is actually two, pulling in opposite directions, and conflating them is how good technology organisations quietly grind to a halt.
Two kinds of fast
The first is speed today: ship the feature this sprint, hit the date, unblock the deal. The second is speed tomorrow: keep the system in a state where the next feature is also cheap. Almost every meaningful engineering decision is a trade between the two.
You can borrow speed from the future, but the interest rate is brutal and it compounds.
The dilemma is that speed today is visible and speed tomorrow is not. A skipped test, a copy-pasted module, a schema bent to fit a deadline — each one looks free in the demo and shows up six months later as a system nobody wants to touch.
Leading through it
- Name the trade openly. Make the cost of "just this once" explicit, in the room, when the decision is made.
- Budget for tomorrow. Treat the health of the system as a line item, not a thing you'll get to later.
- Measure the right speed. Lead time on the tenth feature tells you more than velocity on the first.
The best technology leaders I know aren't the ones who always choose tomorrow. They're the ones who know which kind of fast the moment actually calls for — and can say so, clearly, to the people who only asked for one word.