Part III — The Decisions
How do I make the decisions that determine what the system becomes?
A CTO is involved in hundreds of decisions. Most of them are operational — they belong to the teams, the delivery cadence, the product process. What belongs to the CTO is a smaller, harder set: decisions that shape the system itself, that determine whether the organization becomes more or less coherent, and that no one else is positioned to make well.
These decisions recur. Not identically, but in recognizable patterns. The same underlying tension appears again and again — short-term delivery against long-term system integrity, local optimization against shared capability, speed against coherence.
A CTO who makes these decisions inconsistently — well in one quarter, badly in the next, depending on who is in the room or how much pressure is present — is not operating with a mandate. They are reacting to context, not shaping it. And reactive decisions, accumulated over time, produce exactly the kind of structural degradation that no single bad decision would cause on its own.
Not suddenly, but predictably.
This section is a decision reference library. Each entry covers a recurring decision the CTO faces, what makes it hard, how to make it well, and what happens to the system when it is made badly over time.
It is not meant to be read in sequence. It is meant to be returned to at the moment a decision is live — when the pressure is real, the stakeholders are waiting, and the path of least resistance is the easiest one to justify.