The law of the requisite complexity

Consultants tend to be hired because of their expected content knowledge and extensive experience in tackling specific challenges, similar to the ones the client faces. Therefore, there is an inherent tension between the experience of the consultant helping the client, and the experience of the client themselves. Of course, consultants have proven models and methodologies that codify their experience. But, good consultants will adapt their models and methodologies to the specifics in a client environment.

So, what does ‘adapting to a client environment’ mean, in practice?

I would suggest ‘adapting’ has two key angles in this context.

• How to ensure the models and methodologies resonate with the day-to-day experience of the clients’ people (see the ‘Organisations as Conversations’ post in April 2017)?
• How can any solutions from these models and methodologies be successfully implemented in the clients’ context?

I am using a concept that I have found very helpful. A generic rule that we can apply, almost like a ‘law of nature’, determining how to best address the ‘adaptation’ challenges.

I call it ‘The law of the requisite complexity’ or sometimes ‘the law of the requisite maturity’.

The basic premise of this ‘law’ is that it is very difficult, if not almost impossible, to get any concept adopted that is much more complex than the client’s perception of the challenge we face. My experience is that that perception depends on the maturity of a client in the specific business area.

I have seen, and worked with, many consultants that get quite frustrated when a client “just doesn’t get it”. Even openly using that language! To me, it is not a problem of the client at all, but an inherent, common -and fatal- failure of the consultant!

The law of the requisite complexity implies that for any concept to be adopted, the level of complexity of that concept must match the maturity of the client in the specific business context. To help the client forward, one needs to adapt the models and methodologies to ensure the requisite nature remains intact. With manageable steps with increasing complexity so that the client’s maturity and associated understanding can stay in step. A respected consultant colleague of mine likes to use a bunny trail as an analogy. For the client to reach a point of more maturity, we must jointly lay out a trail of tasty salad leaves, bits of cabbage, carrots, and so on, that are always within reach at any moment in time. And leading forward along a manageable, agreed path. After all, bunnies will never reach a huge pile of vegetables in the far distance if they simply cannot see it, smell it, or see a path to get there.

Let’s look at some of my recent client examples.

We were asked to create an implementation methodology for a complex organisational transformation journey. Yes, like most consultants, we have large integrated methodologies in our toolkits. They are, after all, the codification of many decades of experience covering many pitfalls, challenges and contain general good practice. But, this specific client had never done anything like this before. They were very ‘immature’ in organisational transformation. So, we created what one could call a Minimum Viable Product (a term borrowed from the marketing world), that had only the minimum number of steps in it to ensure we stay roughly on the right track. Yes, we eliminated many details and therefore possible benefits. But, had we not done this, the client would have been totally swamped in the complexity of the methodology. No one in the client could have owned and led the change. And it would have died a quiet (but very expensive) death.

In another example, we helped the client to develop a new strategic operating model. Our consulting team used an advanced operating model methodology to help create the concept. But… we started by interviewing a wide variety of client staff, on multiple hierarchical levels. To understand their language and organisational maturity in these areas. Only after having done that, we adapted the operating model concepts in their own language, taking care to only introduce 1 to 3 new concepts at the time. And, once adopted, we introduced other concepts, where appropriate. Yes, this slowed down the journey. But this is deliberate to ensure there is requisite maturity and complexity to address the issues.

Can you think of examples where you were struggling with the complexity in certain concepts? Where it seemed there was a mismatch in organisational maturity and expectations? And, how did that affect the outcomes?