Much has been written about ways of working in complex environments — but not yet by me, so, here we go.

I actually do believe that there is a certain view on tackling complex challenges, stemming from a combination of systems thinking and agility, that at least hasn’t jumped at me in researching this.

This view is about transitioning between those two methodologies, when and how to do it, and of course most of all: why it matters.

But first let’s quickly define how I’m going to use the terms complicated, simple, and of course complex.

Meet Complicatedness 🪨

Sometimes things are hard. Really, really hard. My personal experiences here come mostly from science and maths, where there are no shortcuts or clever tricks around some problems (at least for mere mortals). You just gotta solve them.

In business, of course much of R&D work will be complicated. Financial models can be complicated, or quite a lot of technological hurdles. For instance, if you’ve never done it, there’s a reason why programming and bug fixing are so deeply interlinked.

It’s important to remember that complicated things can be very “small” in a way. If you just have a large cluster of interlinked challenges, this doesn’t necessarily mean any of it is complicated.

On the other hand, there is a very subjective element to all of this. It might be very difficult for me to analyse the legal aspects of a certain new technology, but for a lawyer it might be piece of cake.

So our mnemonic can be: for many people, solving Schrödinger’s equation is complicated.

Meet Simplicity 🌻

Many times, things really are very easy. Most of us probably don’t think too long about how to order items in a list, even for an important presentation. Or we can just breeze through everyday tasks which might look difficult for outsiders, but we’ve done them enough times already to do them on autopilot.

I could write a lot of lengthy phrases on this, but in the end let’s just keep it simple between us.

Meet Complexity 🍝

This is the interesting one — complex topics are mostly very intricate sets of interlinked and interdependent parts. There’s this metaphor that I really like of a bowl of spaghetti. If you pull on one, a whole bunch of other spaghetti on the other side (or several sides) of the bowl move as well. It doesn’t matter how smart and dexterous you are, there’s no way around moving more spaghetti than you wanted to.

Complex systems — this is important — consist of several parts. And each of those parts can be relatively simple or complicated. What makes complexity challenging is the interdependencies of the individual parts. A scientific concept which showcases complexity is chaos — chaotic systems show wildly different outcomes for just very mildly different inputs. This typically happens due to some of the parts of the system being in feedback loops.

In any case complex systems, complex challenges are what we typically are faced with in our more important business decisions. So we should think about how we deal with them. And this is where I believe we need more and new ideas than what is already out there.

Embrace 🫂 and Reduce ✂️

There are two typical ways to deal with complexity: you either reduce it or you embrace it. Agility — as in the scrum methodology for instance — is a successful framework in complexity reduction, while on the other hand many coaching approaches like systems thinking embrace complexity.

Reduce it!

The trick behind agility is the same as in lean startup or other modern management models. While in the old times (TM) it was believed that planning just has to be done particularly diligently and with enough intelligence in order to manage complexity, these modern approaches follow the scientific method: test, learn, adapt.

They keep scope small and manageable and put a focus not on long-term planning but fast experimentation cycles. Imagine the spaghetti: instead of trying to figure out which spaghetti you could pull and how you would have to do it in order not to move too many others, agile says “pull a little bit and see what moves – outcomes will stay manageable and we will find out where to pull in the end”.

If you want to read up on this approach, I recommend to take a look at the classics: Eric Ries’ Lean Startup and of course Scrum.

Embrace it!

On the other hand, post-modern ways to tackle complex challenges leverage holistic and systems thinking. There you don’t reduce scope in order to learn, instead you embrace yourself in the complex system as much as possible and after a while “sense” how it functions. You could say you develop an intuition for it.

Nowadays, this methodology is getting more and more en vogue in therapeutic settings as well, because it allows a certain wholeness and self-actuation of therapy patients. The same holds true in coaching or even consulting models leveraging systemic ideas.

Let’s use the spaghetti metaphor again: embracing complexity would mean something like accepting that they will all stick together somehow, appreciating that this is also what makes it special to eat a bowl of spaghetti, and then not even trying to get a single spaghetto. After time you will realise that this is the way to eat spaghetti and all potential side-effects like spilling sauce on your shirt you can still intuitively avoid.

An organisational perspective on this way to work with complexity which I really like comes from Frederic Laloux and is described in his book Reinventing Organizations.

So how to tackle complexity then?

This website is about business and not about coaching (even though there are similarities), so what does this all mean for your work?

Arguably, most interesting and challenging problems in business are complex ones, consisting of both simple and complicated parts. I think there is a natural way to deal with complexity in a business context. It draws from agility and systemic approaches, and it shares certain characteristics with the “U” approach from Theory U. And it is very simple, so I drew it up:

The purple line is meant to symbolise the process to deal with a complex problem:

• Start in “embrace” mode: consider contexts, embed yourself in the problem, sense it.
• After a while you’ve collected a lot of knowledge of the problem and the system having the problem. You probably have a good idea of a first goal to pursue and can move to “reduce” mode, where you break down the challenge and work in iterative experiments.
• When you’ve reached that goal or learned that is not a good goal, you should move back to “embrace” mode and sense what your progress means for the overall system, possibly showing you a new goal to follow.
• Repeat this alternating process until — ideally — you end up in “embrace” mode and sense that there is nothing left to do for you at that moment. Congratulations, you’ve solved a complex problem. In reality, most of the times you won’t really be finished. Sometimes your work reduced the entire system complexity enough and you can follow your favourite way to work on non-complex challenges. Other times, you learned so much and the environment changed so much that you really need to rethink the system and challenge overall.

I believe that good ways of working in either of the two modes — “embrace” and “reduce” — can be found in the literature. However, there is a question open: how do you transition well between the two modes? Let me start with a drawing as an outline again:

E-mode and R-mode (“embrace” and “reduce”, I’ve grown tired of typing that out) present different toolsets and proven processes to deal with complexity, as mentioned before. These methods focus on the task at hand, at the system you’re in, and the tools you have available. In contrast to that, I want to argue that the transition phases are phases of inner work and readjustment of your attitude. While this may sound a little esoteric to some, I really only mean a very basic necessity: your mindset and attitude dictate your way of working.

E-to-R transition: focus!

In E-mode you are very aware of context and sense how the system reacts to your actions and other factors like external influences. That’s a cool state of being, but typically it is not easy to start doing work this way.
In order to actually get going, you need to find things to do that make sense to do. Luckily, by being in E-mode, you have a great understanding of what making sense means for your system.

I suggest to follow a couple of steps to focus your understanding of the system and the challenge into an action plan that can be solved in R-mode:

• You could use design thinking techniques to create a shared vision of a goal you want to reach with your colleagues and other important stakeholders in the system.
• Then you should break down the goal into subgoals — probably, coming from E-mode, you will be pretty grand in your thinking and your vision might be quite encompassing. So try to reduce the vision into smaller pieces — either in temporal order (what comes before what) or in a functional split (what parts have to move together to create your goal).
• Then, you could create an understanding about the relative difficulty and impact of the subgoals to your grand vision.
• Then just take it from there: fill an ordered backlog with the subgoals and use your favourite agile methodology to work on the backlog.

R-to-E transition: contextualize!

Now imagine you’ve been following a couple of agile sprints in R-mode, learning about the system from experiments and iterative work towards the goals you had defined in the E-to-R transition. After a while you might have reached those goals or you start realising that somehow you don’t generate a lot of impact anymore. Those are good signs that you should go to E-mode again. But how do you go from R to E-mode?

R-Mode narrows the scope of changes to the system and in turn allows for more control and progress according to a plan. In E-mode on the other hand, we need a wider scope. So we have to drop control and directed progress for a while. This is extremely hard for most organisations and most professionals, so here’s again a short list of activities which may help you to perform an R-to-E transition — contextualize:

• Take a break — consciously stop making progress for a while, maybe a week.
• Talk to your team, your clients — people from the system outside your reduced scope. I suggest using circular questions (“how would your family rate your product”) in order to activate the context-sensing way of thinking for them.
• If you can, observe how the system reacts to you and to your solution using qualitative and anecdotal evidence on an equal footing to quantitative research.
• After having invested time and energy into your solution in R-mode, you will be biased towards it. Try to overcome that bias, for instance by playful methods like “kill your idea” exercises.

---

I hope this article inspires you — it is only scratching the surface, of course. Nevertheless, I would like to thank Henning Werner for all the inspiration and conversations about questions like the one addressed here.