Complexity Creep is a subtle, but destructive force that can affect products, projects, and processes of any kind. Complexity Creep can slowly take any good idea and render it useless. The worst part is, you don’t even know it’s taking over until it’s too late!
In this blog, we’ll be covering:
- What Complexity Creep is
- Distinguishing between complexity and sophistication
- Common instances in advice
- How to manage it
What is Complexity Creep?
Complexity Creep is when something has become increasingly complex over time. It can happen in a system, a process, a service offering, a document, a product, a car, a movie, or just about anything.
Sometimes complexity is required, sometimes it can bring powerful solutions. However, this blog isn’t about the benefits of being simple, it is about complexity unintentionally creeping in over time.
There are two main distinctions for Complexity Creep and where it comes from.
At the design phase
My favourite example of this is ‘The Homer’, in The Simpsons episode “Oh Brother, Where Art Thou?”. In the episode Homer’s long-lost brother asks Homer to design a car for someone like him, ‘an average schmo’. Without any experience, vision, or idea, Homer throws in everything he can think of and the result is a disaster.
Complexity Creep comes in over time as well. We see this with social media platforms, with services keen to continuously grow users, they add new features to try and attract more and more users. However, this makes the experience more complicated to new users and can alienate existing users, defeating it’s original objective.
Distinguishing between complexity and sophistication
Google can be considered the most complicated website in the world (powered by an incredible algorithm), or one of the simplest (with it’s extremely simple layout). Sophisticated, without being complex.
Another great example is McDonalds’ new self-service boards. Their beautifully simple interface allows you to quickly order something standard (Big Mac Meal, with Coke and fries), and also customise every single aspect. The user can engage complexity, when they want to. In the web design space this concept is called ‘progressive disclosure’.
In the advice context, it may be ok for our advice to be sophisticated but keep the client experience simple. It may be ok for our process to be complex behind the scenes, so long as it’s easy for the end user to be clear on what they must do and when.
The critical distinction is that sophistication by design is valuable, as opposed to complexity by accident which destroys value.
Complexity Creep in advice
Some common examples of Complexity Creep in advice are:
Policies, process, and procedure
Policies and procedures are a common one in advice. With so much change over the years, unless a policy is rethought from the ground up, it’s likely going to be subject to Complexity Creep.
A new regulatory guide released? A new white paper published? A new decision at AFCA? The typical way to respond is to take a look at the current system, see if there is now a shortcoming, and then band-aid it. It’s completely reasonable at the time, but do it enough and you move further and further away from the design intention.
Classic examples include:
- Advice templates, which are only ever added to and almost never reduced
- Advice processes, which require increasing checks and sign-offs
- Advice service packages that were designed around a compelling FDS, not what the client values
Technology in advice suffers from this in various quarters. One of the worst offenders is technology designed for decision makers who are power users (licensee experts, corporate clients, expert user groups) and not the average end user. In doing so, Complexity Creep can quickly become a problem as developers are rewarded for long functionality lists over simplicity.
Similarly, when practices want a given function they often look to add on a new tool to an existing system. Whilst admirable, and logical at each iteration, the increasing complexity comes at a cost which is rarely given enough weight. Had complexity been factored in sufficiently, perhaps another problem may have been a superior area to focus on.
Classic examples include:
- Feature rich software that is far more complex than business needs. (See my blog on Choosing your advice tech: Complexity vs. Ease of use.)
- Bolt on steps, technology, or spreadsheets that add limited value.
- Firms chasing a new piece of technology to solve a small problem, whilst ignoring a large one.
The marketing of advice, what we do, who we serve, the value we add… often gets lost.
There are different ways to approach the value we add and the services we provide. I’m no expert in this. However, I do frequently see messaging from advisers (on their website, in terms of engagement, and elsewhere) that detracts from a simple message.
It’s easy to get trapped in how much you can do, led by what your accreditations and authorisations are, but when it comes to messaging less is always more.
Managing Complexity Creep
Unfortunately, there is no silver bullet for Complexity Creep. It requires a range of strategies.
At the design phase
This is at the big picture step. You’re designing something new, or rebuilding something from the ground up. Either way, it’s a clean slate.
- Clarity of vision – Documenting exactly what you’re trying to achieve and the motivations behind it.
- Guiding principles – What is important in this process? What values are we applying here? Who are we trying to serve? Whenever we’re unsure which way to turn, our guiding principles should inform our decision.
- Clear roles – The RACI Model (Responsible, Accountable, Consulted, Informed) can help define roles. A clear ownership structure allows for decisiveness and remove scope for complicating half-measures.
- Minimise cooks – Everyone knows the saying ‘too many cooks spoil the broth’. Less is more.
- Minimal Viable Product – A concept from the technology space, it may be useful to focus on the minimum investment required to make this work and work well. Things can be expanded over time. A simple way to express this is categorising complexity as ‘must haves’ vs. ‘nice to haves’.
If you need to engage a ‘cook’, be clear on what you’re engaging them for.
Don’t just ask for their opinion, ask for feedback specific to their authority / subject matter expertise.
- Periodically ask ‘Why?’ – A leaf from the Kaizen philosophy, you should periodically review and ask why something is the case. If given a clean slate, is this what we would have come up with?
- Bring in fresh eyes – Listen to new staff. Show what is in place to an friendly outsider. Fresh eyes bring a valuable perspective which is often given lip service. Don’t just value it, seek it out.
- Price in the cost of complexity – Complexity brings risk. Complexity is taxing on staff. Complexity runs slow. Consider that cost when adding complexity to a process, and maybe there is a better solution or another problem that would be better targeted instead.
- Sunsets – If you have to make something more complex, put a sunset clause on it and schedule a review down the track.
- Eternal vigilance – Constant vigilance is required to keep unintended complexity at bay.
Next time you’re kickstarting a new project or you’re tweaking an old one, give Complexity Creep some thought and try to guard against it. Simplicity doesn’t come easily, it’s hard work.
We’d love to hear your thoughts or questions in the comments below.