Priorities Are Expensive: What Subsystem Dominance Does to a System
Priorities Are Expensive: What Subsystem Dominance Does to a System
Prioritisation is treated as a management virtue. If everything is important, nothing is important; rank, stack, execute. The discipline is real, and the advice is not wrong. But there is a cost to prioritisation that almost never appears in the conversation, and it isn’t paid where anyone is looking for it.
When you prioritise, you are not only choosing what to do. You are elevating one part of a system above the others, and a system is not a collection of parts that happen to sit near one another.
Subsystem dominance destabilises the whole
An organisation is held together by the relations between its parts, and those relations are calibrated. Sales sells at a rate product can build for. Product ships at a rate support can absorb. Support surfaces defects at a rate engineering can act on. Engineering’s throughput is what makes the next sales promise credible. None of those rates was designed in a document. They settled into balance because each part constrains and feeds the others.
Give one subsystem dominance, and you don’t simply take resources from the rest. You break the coupling. Push sales hard and product builds against promises it can’t keep; support absorbs the shortfall and degrades; degraded support stops surfacing accurate defect signals; engineering, working from a corrupted signal, fixes the wrong things; and the product that reaches the next customer is worse than the one that closed the last deal. The priority didn’t only cost the deprioritised functions. It disabled the feedback that the whole system was running on, including the feedback that the prioritised subsystem depends on to keep selling.
Which is the part that catches people out. Subsystem dominance eventually starves the dominant subsystem. Sales wins the quarter and inherits a product it can no longer credibly sell. Speed wins the release and inherits a codebase in which nothing can be shipped quickly. The winning part destroys the conditions of its own performance, because those conditions were never located inside it. They were in the relations it broke.
The tensions are the control system
This is why managing the tension rather than winning it is not temperamental advice about balance. It’s a structural claim. Innovation pulling against reliability, speed against stability, growth against sustainability, those oppositions are not problems awaiting resolution. They are the mechanism by which each side is regulated. Reliability is what makes innovation survivable. Innovation is what stops reliability calcifying into stagnation. Each holds the other to account, continuously, without anyone having to adjudicate.
Declare a priority, and you don’t settle the tension.
You disable the regulator.
The suppressed side stops constraining the dominant one, and the dominant one – now unopposed – runs to an extreme it was never meant to reach on its own. What looks like decisiveness at the moment of the decision looks, eighteen months later, like a system that has lost the ability to correct itself. The organisation didn’t lose a subsystem. It lost the equilibrium that made all of them work.
Why leaders prioritise anyway, and why that isn’t laziness
It would be easy to call this a failure of nerve or an unwillingness to think, leaders, retreating from complexity into simplicity. It isn’t, and the diagnosis matters because it determines the remedy.
Leaders prioritise ruthlessly because the architecture rewards it.
They are accountable for a subsystem’s number, on a cycle short enough that the destabilisation lands after the assessment.
Nobody is measured on the equilibrium of the whole.
Everybody is measured on their part of it.
In that structure, optimising your subsystem at the expense of the system is not laziness. It is the only rational strategy available, and the leader who nobly refuses it will miss their target and be replaced by someone who doesn’t.
Which means “embrace complexity” is advice that cannot be taken. A leader can understand perfectly well that pushing sales will break support next quarter and still push sales, because their reward is tied to the first fact and nothing at all to the second. The cognitive work was never the constraint.
The consequence structure was.
What actually changes it
If prioritisation destabilises the system because the destabilisation is invisible and unattributed, then the remedy is not to think harder about the trade-off. It’s to build a structure in which the trade-off is visible, owned, and paid for by whoever makes it.
That begins with making the cost explicit at the moment of decision, and attaching a name to it. Not “this quarter is about sales,” but “this quarter is about sales, which means we are accepting a longer support backlog and a higher risk of burnout in engineering, and I am accountable for both.” A priority whose cost is stated and owned is a decision. A priority whose cost is silent is a transfer, and the person receiving it never agreed to it.
It also means holding someone accountable for the equilibrium rather than only for the parts. Where the architecture tracks subsystem output alone, subsystem output is what will be optimised, and that isn’t a moral failing, it’s arithmetic. Somebody has to carry the consequence of the couplings breaking, and if that consequence lands nowhere, the couplings will keep breaking. Until it does, the person setting the priority is playing a game where one column has numbers, and the other is empty.
And it means treating the tensions between competing needs as conditions to be held rather than contests to be won. Healthy systems live in that tension permanently. The moment one side is declared the priority, the architecture stops noticing the other, and the regulator that kept both honest is switched off.
The point
Prioritisation isn’t the enemy, and the people who do it aren’t avoiding the hard work of thought.
Often priorities are what get anything done, and sometimes a subsystem genuinely must be given dominance for a period.
The error is believing the cost is confined to what you deprioritised.
It isn’t.
Elevate one part of a system and you disturb every relation that part sits inside, including the ones the elevated part depends on, and the bill arrives later, in a currency nobody was tracking, usually diagnosed as a different problem entirely.
So the question isn’t whether to prioritise. It’s whether your structure makes the price of a priority visible to the person setting it, holds someone accountable for the equilibrium and not merely for their subsystem’s number, and treats the tensions between the parts as the thing keeping the system honest rather than an untidiness to be resolved.