No matter what industry you’re in, you have to deal with complexity on a daily basis. From the complexity of computer systems you use to get work done, to the complexity of the projects you’re managing – it seems a byproduct of the information age is complexity.
The Cost of Complexity
Complexity weighs on us. Organisations can suffer from too much complexity, which leads to a decrease in profits, reduced organisational flexibility and dissipating energy. Product complexity often has a negative effect on company processes and cost structures. The complexity of technology systems increases the cost of maintaining them over time and also leads to higher costs associated with user adoption, training and support.
What Is Complexity?
According to the Cambridge dictionary, complexity is the state of something having many parts and being difficult to understand. So how then do these organisations, projects and systems get complex? Is it just something inevitable that happens over time?
The issue of runaway complexity has plagued software engineers for decades. In 1992 Ward Cunningham coined the term ‘technical debt’ considering complexity as a form of debt that needed to be repaid:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation.”
– Ward Cunningham, 1992
How to Think About Complexity
Considering debt as a metaphor for complexity is very useful. The rules of debt seem to transcribe nicely to complexity, however, Cunningham’s metaphor seems to be lacking in one key area: the point at which debt is first accrued. Why is “Shipping first-time code” like going into debt? What is it about the process of developing code that has this effect? Is the same true of organisations and projects? Does it just ‘happen’? I would argue it doesn’t.
Software, projects, and organisations all share a common feature: they are a product of many small decisions. Complexity is insidious. More often than not, each small decision has complexity implications that are either not recognised or not acknowledged for their impact until much later.
So what differentiates the lower-complexity software, projects and organisations? How do they think about complexity to recognise it and control its impact?
There are two aspects to controlling complexity; controlling its impact and controlling its introduction.
Cunningham’s debt metaphor was focused squarely on controlling the impact of complexity once it had been introduced, recognising the compounding effect of adding complexity on top of existing complexity. Cunningham’s way to repay the debt was to reflect on the state of the environment and then seek to simplify. This implies projects and organisations that seek to control complexity need to explicitly spend time and energy reflecting on it and addressing it. The expediency of ignoring complexity in technology, systems and processes must be deliberately balanced with the long-term cost of reflection and remediation.
The more difficult aspect of complexity is controlling its introduction in the first place. There are many ways of controlling the introduction of complexity, however, one would have to argue that controlling complexity is cultural; a set of principles about how people should deal with the millions of small choices that compose every technology, every project and every organisation.
Here are three strategies you can use to start thinking differently about complexity:
1. Apply Occam’s Razor:
William of Ockham, a Franciscan friar who studied logic in the 14th century, devised a principle known as Occam’s Razor. In Latin, it is sometimes called lex parsimoniae, or “the law of briefness” which translates roughly as “More things should not be used than are necessary.” – Occam’s Razor can be applied to manage incoming complexity by framing new ideas, features, or changes in the context of the underlying mission: what is really necessary?
2. Invest in Clarity:
The ambiguity introduced by a lack of clarity is a sure way to introduce complexity. Just as accrued complexity can be seen as debt, taking the time to obtain clarity first could be considered an investment. Just as debts accrue interest, investments provide dividends over time. Defining and communicating a clear vision up front helps to anchor every decision made over time to a collectively understood end-state. Indeed, a stitch in time does save nine.
3. Be Great at Filtering the Signal from the Noise:
The Signal-to-noise ratio is a measure used in science and engineering that compares the level of the desired signal to the level of background noise – like measuring the amount of static in a television broadcast. Thinking about all information as having a signal-to-noise ratio is a powerful strategy because it keeps you and your team listening for what is important to determine the signal (important information) from the noise (irrelevant information).
This concept is also useful when considering who you put on your teams. A person with a low signal-to-noise ratio most likely means complexity will creep into designs, projects plans and other output of their activities. Furthermore, don’t think that just because someone is an expert in an area that they have a low signal-to-noise ratio. Experts can embed spectacular levels of complexity into their solutions, and often those less technically astute feel as though they are not qualified to call it out.
Taking on these strategies as habits to control the introduction of complexity, and taking the time to reflect on, and remediate existing complexity will help you deliver effective projects and drive effective organisations that fulfil their purpose.