The Systems You Built to Help Are the Systems Getting in the Way

Christopher Uryga
9–13 minutes

A woman seated alone in a dark control room, surrounded by a curved wall of glowing monitors displaying data and maps.

Every system in your organization was added for a reason. An approval layer after a compliance incident. A cross-functional committee because two departments couldn’t align. A reporting cadence that doubled because leadership lost visibility during a quarter that went sideways. Each decision made sense when it was made. None of them got revisited. And now the people closest to the work spend more time managing the machinery than doing the work itself.

McKinsey’s 2026 State of Organizations report surveyed 10,000 leaders across 15 countries. Two-thirds of them admitted their organizations are too complex and inefficient to execute effectively. Not on some future initiative. On anything. These are the people who designed the structures, approved the processes, and signed off on the governance layers. The majority now concede the machine they built is working against them.

This is not an efficiency problem. It is a structural one.

What You’ll Learn

  • Why organizational complexity compounds like debt, and what “decision debt” means for daily operations
  • How tool and process accumulation consume productive capacity before anyone notices
  • Why humans default to adding systems instead of removing them, and what the research says about this bias
  • What happens when you automate a system that was already broken
  • How to recognize when your systems have crossed from helpful to self-preserving
  • What simplification requires beyond good intentions

What Is Decision Debt, and How Does It Compound?

Decision debt is the accumulated weight of structural decisions that were never revisited. Every approval layer, reporting cadence, committee, and workflow that was added in response to a specific problem but never removed when the problem passed. The debt compounds because each new layer makes the next one harder to identify and remove.

Ralph Jocham, writing for Scrum.org in March 2026, framed it precisely. Organizations don’t become complex because leaders want complexity. They become complex because every local decision to add structure made sense at the time. Nobody schedules a meeting to make things worse. But the cumulative effect of thousands of reasonable decisions is an unreasonable system.

The financial weight is measurable. McKinsey estimates that 20 to 30 percent of operating expenses are lost to structural inefficiency. Senior executives now spend 23 hours per week in meetings, up from fewer than 10 hours in the 1960s, according to research published in Harvard Business Review. That’s not a scheduling problem. It’s the organizational equivalent of compound interest running in the wrong direction.

Here’s the mechanism that makes it self-reinforcing. Clayton Christensen’s RPV framework explains why complexity protects itself once it’s embedded. Complexity doesn’t just live in org charts. It embeds in processes and values. Proposing simplification threatens the roles, committees, and approval chains that complexity created. The antibodies are already in place before anyone suggests the surgery.

As a general rule, if simplifying a process would eliminate someone’s primary role, that process will resist simplification regardless of whether the role serves the organization’s mission.

How Does Tool and Process Accumulation Reduce Productivity?

The average organization now uses 112 SaaS applications. Seventy percent of workers report that switching between those tools reduces their efficiency, according to IDC research. Nearly 70 percent of employees spend up to 20 hours a week chasing information across fragmented systems. More than half of workers spend less than half their week on tasks that generate revenue, according to a 2025 analysis from Research.com.

These numbers describe a specific failure mode. The systems aren’t broken. They’re working exactly as designed. Each one solves the problem it was built to solve. The problem is that nobody designed the interactions between them. The cognitive cost of navigating 112 tools, reconciling their outputs, and maintaining context across their interfaces falls entirely on the people doing the work.

Dr. Laura Weis, an organizational psychologist, presented findings at the 2024 Enterprise Technology Leadership Summit that put a dollar figure on this burden. Cognitive overload costs organizations $322 billion annually in lost productivity. Teams experiencing high cognitive load showed a 76 percent correlation with burnout rates and a 68 percent correlation with turnover intention.

John Sweller’s cognitive load theory offers a useful framework here. He identified three types of cognitive load: intrinsic (the task’s inherent complexity), germane (the effort to learn and integrate), and extraneous (unnecessary burden created by poor design). Bureaucratic processes, redundant tools, unclear decision chains, and conflicting information architectures are all extraneous load. They don’t make the work harder because the work is hard. They make the work harder because the system around the work is poorly designed.

The most common mistake in addressing productivity is treating it as a people problem when it is a systems problem. If 58 percent of a worker’s week disappears into administrative overhead, the worker is not the bottleneck. The system is.

Why Do We Default to Adding Instead of Removing?

Leidy Klotz, along with Gabriel Adams and Andrew Converse, published research in Nature in 2021 that identified a cognitive bias with direct implications for how organizations grow. When people solve problems, additive ideas come to mind more quickly and easily than subtractive ones. Removing something requires more cognitive effort than adding something. And the effect compounds: the more often people rely on additive strategies, the more cognitively accessible those strategies become. Adding becomes the default not because it works better, but because the brain reaches for it first.

This bias explains a pattern that every organization has experienced. A process fails, so a review step gets added. A communication gap appears, so a new meeting gets scheduled. A tool underperforms, so another tool gets layered on top of it. Each addition is a reasonable response to a real problem. But the cumulative direction is always the same: more. The question “what should we remove?” rarely surfaces because the brain doesn’t naturally generate it.

Consider how this plays out in organizational design. A startup with five people and three tools makes decisions quickly. Not because the people are smarter, but because the system has almost no extraneous load. As the organization grows, the additive bias takes over. Each new hire, each new client, each new problem adds structure. Within a few years, the organization has an approval chain for decisions that used to take five minutes and a reporting cadence that consumes more time than the work it’s tracking.

The organizations that resist this trajectory aren’t the ones that avoid adding. They’re the ones that treat removal with the same rigor they bring to addition. Every new process gets an expiration date. Every committee gets a measurable justification. Every tool gets a regular audit against the question: does this earn its cognitive cost?

If your organization treats process creation as a formal act but treats process removal as an afterthought, complexity is compounding in one direction only.

What Happens When You Automate a Broken System?

Eighty-eight percent of organizations are deploying AI, according to McKinsey’s 2026 report. Eighty-six percent of leaders say their organization was not prepared to integrate it. Only 14 percent reported that leaders consistently championed adoption. These numbers describe a familiar pattern. The instinct is to add a powerful new capability to an existing structure and expect the structure to absorb it.

Bertrand Duperrin, writing in April 2026, identified the core problem. Automating an inefficient process produces accelerated inefficiency. Technology does not solve complexity. It sanctions it. When you automate a process that includes three unnecessary handoffs and two redundant approvals, you get faster unnecessary handoffs and quicker redundant approvals.

This is a version of the same additive bias operating at the organizational level. AI is treated as something to layer onto existing operations. The assumption is that processing power compensates for structural dysfunction. But AI requires clean decision chains, unambiguous data flows, and clear objectives. In a structure where opacity protects internal power dynamics and informal workarounds keep the machinery running, the technology exposes the inconsistencies instead of resolving them.

Duperrin drew a useful distinction. Restructuring rearranges complexity. Workflow redesign removes it. The organizations that will capture value from AI are not the ones with the most sophisticated tooling. They are the ones that simplified their systems before they automated them.

McKinsey’s own data supports this. For every dollar spent on technology, organizations should invest five dollars in people. Organizations that prioritize people alongside technology are four times more likely to maintain top-tier financial performance. The lever isn’t the algorithm. It’s the clarity of the system the algorithm operates inside.

How Do You Recognize When Systems Have Become Self-Preserving?

A system has crossed from helpful to self-preserving when the cost of maintaining it exceeds the value it produces, but removing it feels impossible. Three diagnostic questions can surface this condition.

First: what percentage of team time goes to internal coordination versus work that reaches the customer? If alignment consumes more than 30 percent of capacity, the structure is eating its own output. The system is generating enough procedural weight that the people inside it spend more energy navigating the system than producing results.

Second: how many approvals does a routine decision require? Map every decision that passes through more than two approval layers and ask what would break if one layer disappeared. In most cases, the answer is nothing. The approval exists because it was added during a crisis, and nobody questioned it after the crisis passed.

Third: can you describe what the system produces that wouldn’t exist without it? If the answer is reports that feed other reports, meetings that generate action items for other meetings, or dashboards that nobody references, the system is serving itself. It has become its own constituency.

An attendee at the 2024 Enterprise Technology Leadership Summit made an observation that captures this cleanly. We would never run our servers at 100 percent capacity indefinitely. But that’s exactly what many organizations expect from their teams. The difference is that server load is visible. Cognitive load is not. And a system optimized for its own maintenance will consume whatever capacity is available without producing a visible warning.

The most reliable sign that a system has become self-preserving: proposing its removal generates more organizational resistance than the problem it was built to solve ever did.

What Does Effective Simplification Require?

Simplification is not the absence of sophistication. It is sophistication disciplined by restraint. The organizations that operate well are not the ones with the fewest systems. They are the ones where every system earns its place.

Three concrete moves make simplification structural rather than aspirational.

The first is auditing decision rights. Map every decision that requires more than two approvals. For each one, document when the approval layer was added, what problem it was responding to, and whether that problem still exists. Most organizations will find that a significant portion of their governance structure is protecting against problems that were solved years ago.

The second is measuring coordination cost directly. Track the percentage of time teams spend aligning internally versus producing work that reaches someone outside the organization. This metric is uncomfortable because it quantifies something most leaders would prefer to leave abstract. But the number is the number. If a team spends 40 percent of its week in alignment activities, 40 percent of that team’s capacity is going to overhead.

The third is treating process removal with the same formality as process creation. When a new committee, review board, or reporting cadence is established, it should carry an expiration date and a measurable justification for renewal. This is not bureaucracy added to bureaucracy. It is the structural equivalent of pruning. A system that only grows in one direction will eventually consume the thing it was designed to support.

Jocham’s framing is worth holding onto here. Commitment to simplification without structural change is just another decision that adds to the debt. The intention to simplify is not simplification. Only the removal of structure that no longer serves the mission qualifies.

Conclusion

The question most organizations ask is how to make their systems more powerful. That is the wrong question. Power without restraint produces the complexity that buries the work.

The right question is whether each system helps someone do meaningful work, or whether it helps the system justify its own existence. The answer requires honesty, measurement, and the willingness to remove structure that no longer serves anyone but itself.

The organizations that operate well are not the ones with the most sophisticated machinery. They are the ones that refused to let the machinery outgrow the mission.


Frequently Asked Questions

Is the goal to eliminate all organizational systems?

No. The goal is to ensure every system earns its cognitive and operational cost. Some processes are load-bearing. They protect quality, ensure compliance, or enable coordination that wouldn’t happen otherwise. The problem is not systems. The problem is systems that persist after their purpose has passed.

How do you simplify without losing institutional knowledge?

Simplification targets process, not knowledge. When a review layer is removed, the expertise that informed it doesn’t disappear. It gets redirected toward work that produces value instead of work that maintains structure. The knowledge often becomes more useful when it’s freed from the procedural container that held it.

Won’t removing processes create risk?

Some risk is real. Some risk is the system justifying its own existence. The diagnostic question is specific: what is the measurable consequence of removing this process? If the answer requires speculation rather than evidence, the process is likely protecting a perception of control rather than producing actual control.

How does this apply to small organizations?

Small organizations accumulate decision debt faster than they realize. The additive bias operates at every scale. A five-person team that adds a weekly status meeting, a project management tool, a shared inbox protocol, and a monthly retrospective within its first year has already built a system that consumes meaningful capacity. The earlier the discipline of removal is established, the less debt accumulates.

What’s the relationship between organizational complexity and brand coherence?

Direct. A brand is how an organization is understood over time. When internal systems are incoherent, the signals the organization sends outward become incoherent too. The same discipline that keeps a brand’s signals aligned keeps operational systems aligned: every element accountable to a clear purpose, nothing present that doesn’t earn its place, and the whole thing oriented around the person it’s meant to serve.


About the Author

Christopher Uryga
Subverse

Subverse

Typically replies within an hour

I will be back soon

Subverse
Thank you for reaching out! How can I help?
WhatsApp