Sole understanding of a business-critical system stays with a small, loyal group, so any attempt to reassign or challenge them risks a visible failure that the executive who forced it would own.
An example
The incoming chief operating officer of a parcel delivery company inherited a route-optimization system that planned forty thousand stops a day. It ran on a niche programming language chosen twelve years earlier for speed, and only three engineers, all trained by the system's original architect and loyal to him, could change it. There was no runbook. Cross-training had been on the plan for six quarters and slipped each time, and outside engineers were kept from watching changes on grounds of stability. When she proposed moving the team into the central technology group, the architect replied that peak season was eleven weeks away and this was not the time to risk an outage. Her predecessor had tried the same move two years earlier; routes failed for a day in November and he wore it. She waited until February, when volumes were lowest, and began by hiring a contractor to map the code.
Why it works
Accommodating the group keeps the system running and spares the executive personal blame, so it is the easy option. Reassigning them looks worse, since nobody outside has the knowledge to step in and the documentation is thin, often by design. Above all, challenging them risks a visible, attributable failure, a botched close, a missed filing, a day of failed routes, owned by whoever forced the change. It works best when the system is business-critical with hard deadlines, the knowledge has built up through undocumented changes over years, the group is small but survives losing any one member, and the organization is mid-transformation. An obscure technology chosen early compounds it.
The thinking behind it
Oliver E. Williamson The Economic Institutions of Capitalism (1985) explains that specialized knowledge of one firm's systems is an asset that loses its value elsewhere and leaves the firm exposed to whoever holds it. A small group that alone can run a critical system holds such an asset, and an obscure technology deepens it. Cross-training, documentation, and mainstream technology choices keep that specificity low before it can be turned into a hold-up.
Jeffrey Pfeffer Pfeffer's The External Control of Organizations: A Resource Dependence Perspective (1978) argues that whoever controls a critical, scarce resource gains power over those who depend on it, and that people act to reduce their own dependence and create others'. The group's exclusive knowledge is that resource. Independent mapping of the code and regular checks of how many people can run each system reduce the dependence, and with it the group's power.
Warning signs
No runbook exists for a business-critical system. Cross-training slips every quarter. Nobody outside the group can deploy or change the system, and outsiders are kept from observing the work. The group's members were trained by one person and owe their careers to that person. The technology is unusual and was justified at design time on performance or licensing grounds. "Now is not the time to risk an outage" is a standing refrain.
How to defend yourself
Act before the standoff; once it exists, every option is expensive.
- Use the quietest period of the year to force documentation and observation, when an outage would hurt least.
- Sponsor an independent effort to map and document the code, by contractors or by a team outside the group.
- Make cross-training and documentation compliance requirements with dates, and tie the group's incentives to completing them.
- If key members leave on their own, use the moment to rebuild the knowledge elsewhere.
Expect resistance framed as concern for stability, and answer it with a schedule and a rollback plan.
How a leader shuts it down
Build the defenses years before they are needed: mandatory cross-training and rotations, documentation requirements, code-review access across teams, and scheduled checks of how many people can run each critical system. At procurement and design, require mainstream technology or a documented reason for anything else, along with source-code escrow and transition-assistance terms. Report key-person risk like any other operating risk.