Make Complex Things Understandable

“What is the most underrated skill in the software industry?”, someone recently asked me.

“The ability to make complex things understandable”, I replied.

(I know they were expecting something like “Scala”, “React”, “JavaScript” or “AWS”)

But of all the things that I’ve found to be missing in software teams, an ability to make complex ideas understandable and approachable to others is by far the most glaring and underrated.

Photo by Markus Spiske on Unsplash

Most people can learn a programming language, a framework or a technical topic in enough detail to make practical use of it. Most people can also gain a decent understanding of a complex software project in order to make an individual contribution to it, adding features and code. With both, it takes the investment in time, focus and patience to build enough knowledge and skill to be productive.

But fewer people can reverse engineer that process, opening it up to others, taking the complex details, deriving and distilling the principles behind them, then breaking it all down so that others can more easily approach the same topics or project.

To my mind, that’s the skill it is hardest to find and the one we are often lacking in organisations.

But why do we need people who can do that?


Without people who can lead others through complexity, there is a limit to the amount of it that a team can handle via individual contribution alone.

When combined individual contributions go beyond that complexity tipping point, progress often slows as the team’s efforts to understand what they have already built begin to outweigh their capacity to contribute further to it. Communication is laboured and less effective, the level of understanding of individual contributors drops and the resulting software the team builds is ever more complex, and often unnecessarily so.

Much of what we call technical debt in software is not consciously left on the table for later; a less ideal solution now to be replaced by a harder or better solution later. Instead, it is unintended illogical complexity created by people who didn’t quite grasp what already existed before they started adding to it.

When time and understanding are in short supply, we add our own slightly misaligned contribution on top of it all and further compound the complexity, making it even less approachable to the next person… and the cycle perpetuates.

Further work becomes more like an archaeological dig in which only the upper layers are ever truly understood, leading to yet further misaligned and illogical contributions… and an ever-deepening complexity problem.

This is where much of our “debt” comes from.


Instead, we need to dive deep into complexity, distil the principles behind the details we find — which are often subtle and not explicitly laid out — then, beyond just contributing further to it, capture, disseminate and align that with other people’s understanding, leading each other collectively through it and pointing to logical future directions. That’s how we can truly scale an organisation’s ability to build complex software products.

Beyond individual contribution, we need to build concise, focussed and up-to-date artefacts such as diagrams, summary docs or more verbal/one-on-one means of spreading our hard-won knowledge about that complexity, validating the team’s understanding of it and our collective direction through it.

When a team’s understanding of what they have already built (or inherited) improves, the addition of further illogical complexity is minimised and replaced with simpler and better-aligned concepts. Capacity to build ever more complex software products increases and the complexity tipping point for the team is effectively raised.

It goes without saying that people who are able to make complex things understandable should also strive to teach others to do the same. There’s no point having a wiki if only one person updates it, no point in having tech talks if it is the same people giving them. As well as raising levels of understanding, they also need to tip the culture towards one of communication and collaboration.

So in our search for tech talent to grow a team, let’s not just seek out people who can build software via strong individual contribution; the so-called “rock star” developers and “unicorns”.

We also need people who can distil and communicate all of that complexity, who can help others to understand it, to meaningfully and productively join in and contribute to it, and to scale the complexity of software a team can collectively build.