Organizations can become harder to change even when people support a new direction. An old approval may now underpin a report, a handoff and a system rule. Changing it requires agreement across all those dependencies, not merely permission to remove the original step.
Consider a hypothetical customer-order approval introduced for a major account. Finance, operations and technology each build an arrangement around it. Two years later, a faster ordering process requires all four groups to reconsider the work. Each addition may have been sensible; together, they leave obligations whose continuing value needs examination.
At OutcomesLab, we call this gradual loss of strategic clarity and alignment Strategic Entropy. It is a management metaphor, not a physical law or a claim that every addition causes harm. The question it raises is practical: after an initiative delivers its immediate result, what work will the organization still have to carry?
How a decision acquires a longer life
An initiative begins with a purpose and usually an advocate. Making it operational may require owners, measures, reviews, and connections to other teams. Those arrangements can be necessary at launch. The harder question arrives later, when the original problem has changed but other people have come to rely on the solution. Who can stop a report if another team uses it? Who can retire an exception if nobody has checked whether the risk it addressed remains?
In the hypothetical ordering process, the approval initially answers a question about one account. Once other teams build around it, changing the approval also means revising a report, a handoff, and a system record. Before deciding what to remove, a leader needs to understand both the protection the approval provides and the relationships that now sustain it.
Fritjof Capra and Pier Luigi Luisi, authors of The Systems View of Life: A Unifying Vision, emphasize relationships and context rather than isolated parts. Their systems perspective offers a useful lens here: a process chart for the customer team may understate the reach of its approval. That perspective does not establish that rules inevitably produce rigidity. It encourages leaders to trace who depends on a rule before treating its removal as a minor edit.
Michael T. Hannan, László Pólos, and Glenn R. Carroll give the dependency problem a more specific form. They model how a change to one part of an organization can trigger changes elsewhere, particularly when the starting point is central to an intricate design. Their account does not tell us how quickly an organization accumulates rules. It does explain why changing a connected arrangement can take more time than changing its initiating component suggests.
This differs from Dilution Drag, the OutcomesLab principle concerning finite resources spread across too many current priorities. A crowded portfolio can weaken execution now. Strategic Entropy also concerns the residue of past priorities. A project can finish while its measures, approvals, and system connections continue to shape what the organization can do next.
The benefits of adding an arrangement are usually clearest to its sponsor. Its continuing costs may be spread among people who prepare a report, interpret a rule, maintain an interface, or resolve an exception. Removal reverses the immediate burden: someone must change arrangements others use, while the benefit may emerge gradually as less coordination work. That asymmetry helps explain how an outdated commitment can persist without anyone explicitly deciding to keep it.
When a new fix preserves the old problem
When inherited obligations slow a new priority, leaders may add coordination. A delayed decision gets an escalation meeting; conflicting measures get a reconciliation report. Either response might help. If the same conflict returns each month, however, the meeting may help people navigate it without changing the conditions that reproduce it.
Peter M. Senge, author of The Fifth Discipline: The Art and Practice of the Learning Organization, distinguishes a large number of details from the harder problem of dynamic complexity: interacting decisions whose effects can be delayed or difficult to see. In his account of manufacturing, tightening controls around an apparent inventory problem differs from reducing delays across procurement and production. The first response may manage a symptom; the second examines a process that keeps producing it.
The distinction matters when teams repeatedly ask executives to reconcile competing measures. Faster escalation might shorten each delay. Examining what the measures reward could reveal why the dispute keeps returning. They may express a necessary tension between service and control, in which case leaders need a deliberate way to manage it. Or one measure may belong to an earlier strategy. Either finding is more useful than assuming employees have failed to understand the new priority.
A team may understand it perfectly and still face conflicting instructions. Its customer commitment may depend on the old process while its new target rewards speed. Communication can clarify what leaders want, but it cannot by itself revise an approval right or change a system on which another team relies. The operating arrangements have to be part of the change.
That does not make subtraction the answer to every delay. An approval might prevent a material customer error, meet a regulatory obligation, or provide a safeguard when another control fails. Different customers may genuinely need different processes. Removing complexity from one team’s view can transfer risk or work to someone else. In a qualitative study of two professional-service firms, Ioana Lupu and Joonas Rokka found that controls workers experienced as balanced could help them focus, while overused controls were associated with excessive busyness. A leader needs to judge what a control does, not merely that it exists.
Return to the customer approval. If it still prevents a material error, deleting it to speed up ordering would be a poor choice. If its protection can be incorporated into standard ordering, the separate handoff may no longer be necessary. If the customer arrangement has ended, the approval may have lost its purpose. Retaining, redesigning, and retiring it are different decisions; each requires knowing who relies on the current arrangement and why.
Greg McKeown argues in Essentialism: The Disciplined Pursuit of Less that trade-offs require choosing what matters, eliminating nonessentials, and removing obstacles to execution. Applying that discipline to organizational commitments is an OutcomesLab interpretation, not a retirement method tested in his book. It also requires a cross-functional check: what looks expendable to one owner may sustain another team’s control or customer promise.
Use the balance sheet to redesign the work
Start with one bounded area, such as the ordering journey, and create an Entropy Balance Sheet. This is a proposed decision aid, not a numerical score of adaptability. For each significant initiative, rule, exception, or interface, record the problem it currently addresses, its owner, the teams and systems that depend on it, and the recurring work it requires. Note what it replaced, if anything, and when its continued value should be reviewed. Keep track of what has been retired or redesigned alongside what has been added.
The balance sheet should lead to a decision rather than become another standing report. For the customer approval, the people who use and maintain it might establish that its protection remains necessary, that it can be provided with fewer handoffs, or that the original need has gone. None of those answers follows from simply counting approvals. Each calls for a different design of the work.
The balance sheet also informs agentic workflow redesign. Automating an obsolete approval makes inherited work faster without removing it. Automating an essential one requires preserving its protection and specifying who decides exceptions. Establish the purpose before assigning the step to software.
The opportunity is to reconsider the work, not just assign its existing steps to an agent. Does a reporting field support a distinct finance decision or merely confirm an approval recorded elsewhere? That answer changes the design. The affected owners must decide which customer promises and controls remain necessary; an agent cannot settle that question for them.
The same discipline applies before adding a conventional initiative. A sponsor proposing a new exception should identify its protection, who will maintain it, which teams and systems it will touch, and whether it replaces existing work. Some additions will be worth carrying even when nothing can be removed. Others may work better as temporary exceptions with a review date. Comparing additions with obligations actually reconsidered is a prompt for inquiry, not a removal quota: a required safeguard and a redundant report are not equivalent.
When a supported change stalls, trace the approvals, measures, handoffs, and interfaces it must pass through before asking people to move faster—or assigning those steps to an agent. Some protect something worth keeping. Others may survive because no one has been given the authority and information to change them. That distinction tells leaders what to preserve, what to redesign, and what work no longer needs to happen at all.