Navigating Complexity: Why Traditional Transformation Approaches Fail and How to Embrace Continuous Change

That’s what a client said to me at the end of a 12-month consulting engagement. We had got off to a tough start because the sales team (not at 1ovmany!) had sold him what he asked for, before I arrived with a strong conviction that it wasn’t the way to approach the problem.

This sort of mismatch between the wants or expectations of someone who buys transformation consultancy services, and what experienced transformation practitioners know they will likely find the buyer will need, is not at all uncommon. This article will explain why I believe this happens and hopefully save some pain down the line for other people.

The Problem Statement

So let’s start with what my client had quite reasonably asked for. He ran a large software delivery function with a few programmes of work that delivered very complicated, safety critical technical solutions.

The flagship programme was years behind schedule and the end date didn’t seem to be getting any closer. There were about 15 dev teams, cloud infrastructure teams, programme managers, product owners, scrum masters - all-in-all a couple of hundred super busy, stressed out individuals struggling to make any headway at all.

There was a litany of pain points and frustrations, with management blaming their teams and teams blaming the management.

My sponsor wanted an analysis of the problem, an “agile maturity assessment” and a transformation designed, planned and executed; an idealised future state defined, and a plan of action to get from A to B.

And that is what a lot of people would ask for in that situation. After all, that’s how we solve problems, isn’t it? We identify an issue, then we analyse, design and implement solutions, right?

Well, it’s complicated. Or should I say complex?

Complexity

A lot of people use the terms ‘complicated’ and ‘complex’ interchangeably but in systems theory, there are important distinctions that can have a profound impact on which types of decision-making or problem-solving approaches are most effective.

The Cynefin framework is a useful tool to help us understand of what type of system we’re operating in. Devised by Dave Snowden, it is a sense-making framework that divides systems into five categories: clear, complicated, complex, chaos and confusion.

The Cynefin Framework

The Cynefin Framework | Dave Snowden

• Clear is well understood and very predictable; an ordered system. It’s obvious what to do in this domain and we can apply standard operating procedures. These could be standardised production tasks, routine maintenance or repairs, vendor selection, etc. Clear is the domain of best practice and the decision model appropriate here is sense-categorise-respond.

• Complicated systems are another type of ordered system and they are still predictable but require some expertise. With analysis, cause and effect is understandable and the system responds to changes in consistent ways. They are mechanistic and deterministic, like a car engine. With enough expertise we can diagnose and fix problems in predictable and repeatable ways. Complicated is the domain of good practice and the decision model most appropriate here is sense-analyse-respond.

• Complex systems are dispositional. They are difficult to analyse because cause and effect is not always obvious or consistent, except retrospectively. They are adaptive and their behaviour is emergent, so sometimes the system responds one way to a change and other times it responds differently. We can try the same thing twice and get different results. A small change might make a big difference and a large change might make very little difference. Attempted “fixes” can have unintended consequences. These are more like ecologies, weather systems or the stock market. Complex is the domain of emergent practice and the best decision model for this domain is probe-sense-respond. This means experimenting (probing), measuring for impact (sensing) and then amplifying the things that work and dampening the things that don’t (responding). Iterative & incremental agile approaches like Scrum are designed for working in complex domains, btw.

• In the Chaos domain all bets are off. Causal relationships are confusing and often the situation is urgent. There isn’t time to analyse or probe, you just need to act on instinct and make sense of things later. Examples are things like natural disasters, terrorist attacks, nuclear reactor melt-downs, etc. Chaos is the domain of novel practice and the decision framework is act-sense-respond where the imperative is to act quickly, restore order and try to move the problem into the complex or complicated domains.

• Confusion is simply the state of not knowing which of the above domains apply to the current situation.

For ordered systems (clear & complicated) you can pull out your playbook, analyse, plan and execute; we can follow good or best practice and follow a well-trodden path towards a known solution (sense-analyse-respond).

That’s naturally what a lot of people think they should buy when engaging a transformation consultancy. And unfortunately, that’s what some consultancies will sell them, which is why I believe so many transformation efforts fail.

Which domain do you think applies to human systems like businesses, business functions, teams, teams of teams, etc? It might be tempting to think of them as machines, but they are complex adaptive systems.

In the context of the client mentioned earlier, the software solution under construction was complicated. The system of work, with its multitude of relationships and interactions between the numerous teams and individuals required to build, test and deploy it was complex.

A better change approach: continuous transformation capability

Changing systems of work whilst keeping the lights on requires a change approach that prioritises experimentation, feedback and adaptability over analysis and planning. It’s not realistic in advance to plot a clear path from where we are now to some idealised future state. There are too many variables. On top of all that, the competitive environments in which we must operate are constantly changing too.

Transformation work therefore requires experimentation (probe-sense-respond); trying things, doing more of what works and less of what doesn’t; more of a now-to-next strategy moving from where we are in the current moment to the next adjacent possibility. Each next step only becomes visible as you approach it.

In my experience, transformations are never “done”. There is always something else. What’s really needed is not one huge change initiative, but rather an incremental series of changes. Instead of undergoing one-off “transformations”, there is more value in embracing complexity and uncertainty, accepting change as a way of life, getting good at it, and practising it continuously.

Change needs to continue long after the consultants have left the building. This means developing a learning operating system for your business. It means developing safe-to-try experiments. It means putting in place a system of data to measure for impact and provide rapid feedback about what works and what doesn’t. It means getting comfortable with emergence.

So don’t buy a transformation. Buy a continuous transformation capability. Embrace complexity, uncertainty and change and invest in a learning operating system.

Discover 1ovmany's approach to Digital Transformation in one of the world's largest banks, decreasing decision latency & saving over £5m in Directors' time.