Why complexity is killing your business

dependent adjective

de· pen· dent | \ di-ˈpen-dənt  \

determined or conditioned by another

If you ask 10 people why Digital Transformations fail, you’ll get 10 different answers, often with phrases like “buy-in” and “culture” thrown around. Although there isn’t a simple answer to this question, I’d like to talk about one that often gets ignored. Dependencies.

You have a dependency if something is contingent on another, here are some examples:

• “Getting this work complete is contingent on the tests passing.”
• “We need the platform team to spin up a test environment before we can run the tests.”
• “We need to have sign-off before we can allocate time to create the instance.”

It’s very easy to miss the signs of dependency overload if you’re already used to it. So what’s the problem with dependencies anyway, surely waiting for a few hours isn’t what crippling us? The problem is that dependencies are almost never isolated, they network, and then you have a matrix.

A Dependent System

Imagine a system where you have a single dependency. The development team is able to fully execute on their work except for a single, small part. They need another team to make a small change at the end of the process. This isn’t too bad as long as we collaborate, we give them plenty of warning so that they can schedule a time to complete the needed work when needed. We finish our bit, then hand it over on time for them to do theirs, they hand it back, and we get it out the door. No problem.

Let’s add another one in, now the dependency team has its own dependency on another team. So what, our coordination cost has gone up, but it’s still doable?

What happens when each team has multiple dependencies?

So we end up with this spider’s web of dependencies across the entire system. Our coordination cost is massive, so we draft in armies of project managers to try and tame the complexity.

To drive out uncertainty, we expand on the detail, eliminating autonomy. If we plan out everything in meticulous detail, then we can coordinate it effectively. The work will be broken down and detailed exactingly in a requirements document. We then feed this into the individual teams for their estimates. This has been quite an expensive problem to solve, taking hundreds of hours of work, without delivering the smallest amount of value. But finally, we have it: The Plan.

The Problem

Less than a day after this mammoth effort was completed, something changes. In isolation, this shouldn’t matter, but we have dependencies. Now that small change reverberates across the entire system, creating delays, all the while growing. Before long, this slight delay has affected every node in the system. The coordinators are running around trying to get updated estimates, but it’s no use.

It doesn’t often occur quite as apocalyptically as this, but it’s still happening. As long as there are dependencies, you will have delays, expensive coordination costs, poor predictability, and difficulty in making course corrections. Delays are obvious, as are the coordination costs, but what’s that about predictability?

Destroying Your Predictability

Assuming a perfect system, where everything happens exactly when we expected, then we shouldn’t see any deviations from The Plan. Unfortunately, that’s not how life works. I’d like to introduce some new terms, a way of categorising dependencies.

Inbound Dependency

If another team or person needs you to do something for them to fully execute on their work, then you have an inbound dependency. In this instance, the work is contingent on you, this can cause some problems for us.

In a perfect system, where we learn about the external need with plenty of time, then it might not affect us too greatly. Unfortunately, this is rarely the case. What happens when a serious issue occurs? You’ve already got your plate full, but now someone needs something from you desperately? How do you decide which takes priority? And what if parking your current work causes a delay for someone else? Should we give in and risk introducing further delays or try and cut the avalanche short?

Even without priority issues cropping up, what if multiple teams need you for something around the same time in the plan? This is where we end up with capacity planning absurdity. I’m guessing you could name at least one entity in your own organisation that everything needs to go through.

This is why inbound dependencies ruin our predictability. When we don’t know when work will arrive, and how to respond when it does, all bets are off. But at least we can continue executing on our own work.

Outbound Dependency

If there is one thing worse than an inbound dependency, it is an outbound one. With an inbound dependency, at least we are never fully blocked from executing our own work. When you have an outbound dependency, you are reliant on another to complete your work. This has all of the predictability challenges previously mentioned, with an additional one. If you can’t bribe, persuade, or cajole your dependency to do what you need, then you really are stuck. Having an outbound dependency means that you have no control over your predictability, you are truly contingent on another.

Fixing It

Not to be glib, but the only way to effectively accelerate is to eliminate your dependencies. What we’re trying to do is snip the strings that are currently tieing everything else up. Although complex systems often deny useful visualisations, it can be done and will often yield quite interesting results. I’ve found that dependencies often gather in a small number of patches within the organisation. By identifying these, and then breaking them, you will often see a significant cascading reduction in complexity across the entire system. Here are some rules of thumb:

1. Visualise your dependencies
2. Order your areas by the count of outbound dependencies
3. Further order by the count of inbound dependencies
4. Begin to isolate the most dependent areas, making provision for orphaned dependencies (where we break an outbound dependency)

I recently ran a dependency workshop at a large company with a significant IT department. After analysing the data, I found that by isolating a single unit, we could reduce complexity across the entire estate by a whopping 28%. The modelling showed that when this was achieved, 2 new units would become completed free to isolate. This is a pattern that continues to repeat itself. By isolating areas of particular complexity, the entire web starts to unravel.

Conclusion

There is no panacea for accelerating your organisation, but the first thing I do when consulting for any company is to start thinking about the dependencies. They are expensive, frustrating, and preventing you from scaling.

I work at DevOpsGroup, helping our clients solve complex problems relating to Agile, Lean, culture, organisational design and data-driven business.