The Hidden Cost of Complexity

Complexity Rarely Starts as Complexity

Most organizations don’t decide to become complicated. Nobody walks into a planning meeting and says, “Let’s make this harder to understand.” Complexity usually arrives with perfectly reasonable intentions: a new form is created because something was missed, a new approval is added because someone made a mistake, a spreadsheet is built because the existing system doesn’t provide the information someone needs, a new policy addresses an exception, a new meeting keeps another group informed, a new report gives leadership more visibility.

Individually, every decision may make sense. The problem is that organizations are very good at adding things and remarkably bad at removing them. Over time, yesterday’s solutions become today’s complexity, and eventually nobody remembers why half of it exists.

Every Problem Leaves Something Behind

One of the easiest ways to create complexity is how we respond when something goes wrong. An employee makes a mistake, and a manager says, “We need a policy for that.” Or: “We need an SOP.” “We need another approval.” “We need a form.” “We need someone to sign off on this.”

It feels responsible. Something went wrong, so we’re doing something to prevent it from happening again. But before adding anything, we should diagnose what actually happened. When an employee makes an error while performing a business process, I believe there are only three possibilities. First, there is no applicable SOP or standard, so the employee had to figure out what to do on their own. Second, there is an SOP, but it is wrong. The employee followed it exactly and the mistake happened anyway. Third, there is an SOP, it is correct, and the employee did not follow it.

There is no number four.

That means the first question after a process error shouldn’t be “What new policy do we need?” It should be “Which of the three happened?”

Only One of the Three May Require Something New

If there was no SOP, then yes, perhaps one needs to be created. But even then, the question should be whether the work actually requires a formal procedure, not whether every unusual situation deserves its own policy.

If the SOP exists but is wrong, don’t create another policy. Fix the SOP.

If the SOP is correct but wasn’t followed, another policy doesn’t solve anything either. Now you need to understand why the correct process wasn’t followed. Was the employee trained? Was the procedure accessible? Was the expectation clear? Was there a practical reason the employee couldn’t follow it? Or was it simply ignored?

Those are root-cause questions. Writing another policy before answering them doesn’t fix the cause. It just gives the organization another policy.

That’s How Complexity Is Born

Imagine an organization where every mistake results in another control. One employee makes an error, so a supervisor adds an approval. Someone misses a field, so another checkbox is added. A report contains the wrong number, so someone creates a second spreadsheet to verify the first. Someone forgets to notify another department, so a mandatory email is added to the process. Someone fails to follow an existing procedure, so management writes another procedure reminding employees to follow the first procedure.

Each response can be defended. That’s what makes this dangerous. The organization isn’t intentionally creating bureaucracy. It’s trying to solve problems. But every problem leaves something behind: a rule, a form, an approval, a report, a meeting, a field, a checklist, a workaround.

One at a time, they don’t look like much. Ten years later, nobody understands why it takes twelve steps to do something that should take four.

Complexity Has a Carrying Cost

We usually think about the cost of something when we create it: What will this software cost? How long will it take to build this process? How much time will this new report require? But almost everything we add to an organization creates an ongoing carrying cost. A policy has to be understood. An SOP has to be maintained. A process has to be followed. A system has to be supported. A report has to be produced. A meeting has to be attended. A field in a database has to be entered correctly. An approval has to be obtained. An exception has to be remembered.

And the cost doesn’t occur once. It occurs every time someone interacts with that part of the organization.

Suppose one mistake causes us to add a two-minute verification step. That doesn’t sound expensive. But if 20 employees perform that process five times a day, we’ve added 200 minutes of work every day. More than three hours, every day, to prevent one mistake.

Maybe that’s justified. Maybe it isn’t. The point is that we rarely calculate the ongoing cost of the solution. We see the mistake. We see the corrective action. We don’t see the capacity we’re committing forever.

The Organization Becomes Harder to Understand

One of the first signs of complexity is that people stop understanding how the whole system works. They understand their piece. Finance knows its process. Operations knows its process. Development knows its process. Programs know their process. Leadership knows what reports arrive. But fewer people understand what happens from beginning to end.

That’s when simple questions start producing complicated answers:

“How does this get approved?” “It depends.”

“Where does that information come from?” “Usually from this system, unless it’s this type of request.”

“Who owns this?” “Technically one department, but another person usually handles it.”

“Why do we do this?” “I’m not sure. We’ve always done it.”

Those aren’t necessarily signs of bad employees. They’re often signs of an organization that has accumulated more complexity than anyone is actively managing.

Complexity Creates Dependency on People

When systems become complicated, experienced employees become translators. They know which rules actually matter, which steps can be skipped, who really makes the decision, which spreadsheet contains the real number, and that the written procedure says one thing while the organization actually does another.

That knowledge is valuable. It is also dangerous, because now the process doesn’t live in the organization. It lives in people.

When one of those people leaves, takes vacation, changes roles, or simply isn’t available, everyone suddenly discovers how much organizational knowledge was being carried in someone’s head. We often call that person indispensable. Sometimes what we really mean is that the system has become unnecessarily dependent on them.

Complexity Makes Change Harder

Simple systems are easier to change because you can see how the pieces connect. Complex systems create uncertainty: change one process and something else might break; remove one report and someone may depend on it; replace one piece of software and three spreadsheets may have been built around it; eliminate one approval and nobody is quite sure whether another policy requires it.

So organizations become cautious. Instead of simplifying the system, they add another layer to protect the existing layers. That creates a cycle: complexity makes change risky, the fear of risk causes organizations to add controls, those controls create more complexity, and more complexity makes future change even harder. Eventually, maintaining the system begins to take priority over improving it.

Complexity Is Especially Expensive in Small Organizations

Large organizations can sometimes absorb complexity. They have specialists: departments dedicated to compliance, technology, finance, human resources, data, and administration. Small organizations usually don’t. The same person may be managing employees, answering emails, reviewing expenses, preparing reports, solving technology problems, working with clients, and attending board meetings. Every unnecessary process competes directly with mission work.

That makes simplicity more than a convenience. It becomes a capacity strategy. If a nonprofit can eliminate a report nobody uses, simplify an approval process, remove duplicate tracking, or reduce the number of systems an employee has to touch, it has effectively returned time to the organization.

No grant required.

Ask a Different Question

When reviewing a process, leaders often ask, “Does this still work?” That’s a low standard. Plenty of complicated systems work.

A better question is: “If we were designing this today, knowing what we know now, would we build it this way?” Would we still require this approval? Would we still collect this information? Would we still hold this meeting? Would we still use both systems? Would we still produce this report? Would we still have this policy? Would we still organize the work this way?

Some answers will be yes. Good, keep those things. But every “no” identifies complexity the organization may be carrying simply because nobody has challenged it.

Subtraction Is a Leadership Skill

Leaders are usually rewarded for adding: launch the initiative, build the program, create the dashboard, write the policy, add the service, implement the system. There is much less recognition for removing something.

But subtraction can be one of the most valuable things a leader does. Eliminating a report can return hours every month. Removing an approval can shorten a process. Combining two systems can eliminate duplicate work. Clarifying ownership can remove meetings and emails. Deleting a field nobody uses can improve data quality. Retiring an obsolete policy can make the remaining policies easier to understand and follow.

None of those actions looks as impressive as launching something new. They may be far more valuable.

Before You Add Something, Diagnose the Problem

Complexity is easy to add because adding something feels like action. Something went wrong, do something. But good operations requires something harder: diagnosis.

The next time a process error occurs, resist the urge to immediately create another rule. Start with three questions: Was there an applicable SOP? If there was, was it correct? If it was correct, was it followed?