How Hidden Complexity Tax Saps Organization Resilience

The organizations we work for often pay a heavy but invisible tax: the complexity tax. It shows up in slow decision-making, unnecessary overhead, and warring metrics. In my article “Less is More: Creating Resilient Systems Through Simplicity”, we explored grassroots simplicity - what individual team members and coaches can do to help avoid unnecessary complexity. This article examines deeper examples of complexity that undermine organizational resilience.

We’ve all seen the symptoms: approval by committee, constant need for permission, information silos, etc. Complexity didn’t arrive overnight. Instead, it came one tiny decision at a time. Most of these decisions weren’t harmful. It’s the collective result that hurts. We have a cognitive bias when solving a problem, in that we tend to look for things to add rather than subtract. [1] But there is no magic solution. Instead of adding things as our workplaces become more complex, we need to ask how to simplify so that our organizations can withstand change and be more agile and resilient.

By recognizing and reversing this dangerous “complicating instead of simplifying” pattern at the organizational level, leaders can build truly resilient enterprises capable of adapting to an unpredictable future.

Organizational Structure

In software development, Conway’s Law states “organizations build products that resemble their organizational structure”. So when an organization has more departments and committees, it inevitably creates more complex products. Worse, the more groups that touch a product, the longer it takes to get from idea to value delivered. (See Cycle Time and Lead Time).

This isn’t unusual. As organizations grow in size, they often add more hierarchy and structure. The classic mistake is that a small, successful organization attempts to grow rapidly and they start hiring middle managers. Decisions go through an additional layer of people, and communication is reduced. In some cases, the additional complexity contributes to the system’s demise. This isn’t just theory. In the early 2000s, as Nokia did very well with mobile phones, it hired more people to help coordinate the work. On the surface, this helped. Then, as Ran Nyman and Ari Tikka document, the coordination chaos that resulted was a significant factor in the demise of Nokia mobile. [2]

Adding additional managers and departments isn’t always bad because the problem isn’t the person or even the role. Instead, the problem is when the decision is made to add a new manager (an increase in complexity) without seeking simplicity first. Once the manager or department is added, people will be invested in this complexity forever.

Decision Making

I’ve witnessed organizations where each management layer has an increasing authority to spend money (say, from $5,000 to $20,000, for example). I’ve seen other organizations where individual contributors can make sensible decisions to buy things they need without asking permission first. Still other organizations give everyone a fixed sum of money annually. There are many different approaches but, inevitably, organizations with a more complex approval process have greater waste. Which isn’t unexpected when you think about it. When faced with a painful approval process, people often purchase more than they really need, so they don’t have to ask again.

That’s wasted finances, but what about wasted time? Forcing managers to deal with expenses and other small tasks takes away from their ability to add meaningful value as leaders.

How about wasted opportunity? The same organizations that require a manager’s approval to take training, for example, also have complicated decision-making rules around who is entitled to make product and development decisions. As a result, managers become the bottleneck for decision-making.

After 25 years of Agile, I still see organizations strangling their decision-making process with so much overhead that the teams do low value work, waiting for all of the decisions.

The Agile approach is to push as much decision-making as possible down to the level of the teams and product owner. Instead of trying to make all the decisions perfectly, a resilient system accepts that small mistakes will be made. Instead of avoiding all mistakes, they build mistake recovery into the system.

Rules and Bureaucracy

Many organizations put in place rules and bureaucracy to stop people from doing the wrong thing. Instead, the rules make it difficult for most people to do the right thing. Often, people invent increasingly complex workarounds instead of dealing with the bureaucracy.

As we saw with the subprime mortgage crisis, complex rules don’t provide real protection[1]. Each additional rule appeared to help on the surface, however, each addition made it harder to see the big picture. Adding rules doesn’t always protect the system, instead they often make it harder to get quality work done.

When responding to an incident or mistake, first ask what can be eliminated, instead of seeking to add new rules. To help keep things manageable, consider eliminating one existing rule before creating a new one.

Product and Business Strategy

Many organizations have strategic roadmaps that span multiple years. The roadmaps make promises, and the promises become deadlines. The problem, of course, is that a promise made in January has an increasingly high likelihood of no longer being important by August, for example. As a result, many teams are working hard to build things that no longer matter. On top of this, they’re pressured to add new work that wasn’t on the original roadmap to their quarterly goals.

For the same reasons we need resilience in the first place, we need to recognize that long-term roadmaps, with their promise to deliver a list of features every quarter, don’t work. Worse, when teams are held to delivering, they do poor quality work both technically and from a usability perspective.

The Agile approach is to simplify and ditch the long-term roadmap completely, it’s fiction. Instead, Product Managers and Stakeholders talk regularly to make high-level decisions on what to work on next. If long-term roadmaps must be shared with clients, share them without dates and use them to have discussions around high level priorities.

Performance Metrics

“What is measured is managed” is a famous quote I can’t find clear attribution for (often mis-attributed to Peter Drucker). The damage this mindset has done over the past century is amazing. Some quick examples:

• During British rule of India, to reduce the cobra population, a bounty was offered for every cobra killed. This had the opposite effect of what was intended because it led to people breeding and killing cobras for income.
• In 2002, British officials in Afghanistan were paying farmers $700 per acre for destroying their opium crop. The result was that farmers planted opium to burn it.

Individual performance bonuses lead people to do things that might help get the bonus. This can be hoarding knowledge, refusing to help others and prioritizing your work. I’ve seen salespeople with regional performance bonuses fight over who gets credit for a large corporation buying their product. Instead of fostering collaboration and building client relationships, the salespeople were just as focused on undermining each other.

The more metrics that are in place, the more likely it is that these metrics will come into conflict with each other. For example, Quarterly Sales Bonuses often lead to:

• Discounts. If you need to lock in the sale to get a bonus, a 20% discount might do the trick. We win the sale, but it hurts the overall profit.
• Pressure on the product team to push more work out the door by the end of the quarter. In these cases, quality always suffers.

In one organization I worked in, we had an annual award to the person who was best at solving difficult customer problems. These same people were so busy solving problems that they also created the quality problems that became next year’s fires.

“Be careful what you measure. You will get it.” - paraphrasing Goodhart’s Law. Another way of saying the same thing is that we will never be able to predict all the interesting ways a measurement will affect the system, so only measure things that matter.

Simplifying Metrics:

• Before adding a new metric, can we eliminate one?
• Before adding any metric, examine the second-order effects (aka Systems Thinking).

Conclusion

When doing work, always ask the question, how could we simplify this system? What could we eliminate? Every time we make a decision to simplify, we make it easier for the person who follows.

Beware, complex solutions might help in the short term, but it often takes months for the deeper problems to become apparent.