A few years ago, my colleague Jon and I were observing an executive team during one of their monthly meetings. A couple of days before the meeting, the agenda and papers had arrived in our inboxes – and left them groaning under the weight of the volume. We run a paperless system in Waldencroft, but on the day of the meeting we saw what that paper bundle looked like when printed out – and it sat more than 6 inches high.
The agenda had 32 items and there were a range of different things in there. All indicative of a large, complex organisation with lots going on. Some papers were for policy ratification. Others, conceptual. Others still, data heavy that required a steer from the executive team on what they should do next.
The meeting was an all day affair from 09:30 until 16:30 and I chose to forgo my usual, gentler morning tea, for strong coffee. Something told me this was going to be a long day.
The ease with which this team got through very complicated project decision sign-offs for major multi-generational engineering projects was impressive. The way they discussed and debated investment decisions relating to tens and hundreds of millions of pounds was eye watering.
And then something really strange happened.
In what everyone assumed would be a relatively straightforward item completely tripped the team up. It was the staff engagement survey. There was a lot of data, and on the whole the picture wasn’t very good. What was causing low staff engagement? Why were there such discrepancies in the data across different functional areas or geographies? What should the executive team DO about this?
Jon and I realised that this was the first complex problem the team had been confronted with that day. The others, requiring technical expertise, had been complicated in nature.
What happened next to the team dynamic was extraordinary.
The ease and speed through which the team had progressed in the meeting thus far came to a stuttering halt. The jovial, relational way of interacting was replaced with bad temper and sharp outbursts. For some time they went round in a fractious circle. The team didn’t have a roadmap for solving this gnarly, complex problem and before too long they batted it away with the request for ‘more data’.
The next time it happened, it was with an IT security issue. The Board’s preferred solution had unintended consequences for an underrepresented stakeholder group and the impact of getting it wrong for them was potentially dire. Left with the challenge of doing the right thing or pleasing the Board, the team oscillated in an irritable argument. Eventually batting the problem away, like the previous one, with a request for ‘more data’.
What was it about these two problems that was so different from the ones this highly able and motivated team were able to solve?
Breaking free of the dominant logic in problem solving
We all function based on a set of underlying assumptions about how the world works. It informs everything we think and everything we do.
Most of us acquire this mental model through a lifetime of operating in a culture that takes certain things for granted. In the West, one such taken-for-granted is that organisations operate much like machines. It’s from this basic assumption that we design organisations as if they can be controlled based on our wants; we see empirical data as the holy grail of decision-making; and assume clear chains of cause and effect. Success, on the basis of these assumptions, results from measures, procedures and controls.
But then we try to tackle complex issues by applying mechanistic approaches, and invariably end up wondering why these issues seem immune to change. That’s because working with complex problems requires us to see things not as if they were cogs in a machine-like wheel, but instead as an interconnected system that can adapt to all of the myriad of actions of everyone within it.
The problems the team were struggling with were complex in nature – in contrast to the merely complicated problems that were amenable to the technical solutions the team found relatively easy to solve.
Complex problems and complicated problems are structurally different. To be cognitively fluent means that you have the intellectual capacity to diagnose the difference and then apply a different logic, a different approach and a radically different leadership style to deal with both.
Emergent problems require emergent thinking
For executives to create, develop and sustain healthy, regenerative organisations, they must learn how to think in novel and emerging situations in novel and emerging ways.
The size of the opportunity such leaders see is dependent on the size of their mind. Leaders are taught, trained, promoted and rewarded on the basis of their ability to apply critical thinking and deploy logic in solving problems. Which is great news for the types of problems where this logic is appropriate.
But it’s disastrous for complex problems which have an inherently different structure.
If we think about the executive team I’ve outlined at the start, you can see that someone else – the ‘authors’ of the papers brought the executive team all the knowledge they thought they required to make a decision. And in many cases the executive team were able, on the basis of a well-structured paper backed by appropriate and clear data, to make a decision.
I have issue with this for two reasons. In these cases, where the executive team were able to make relatively straightforward decisions, I believe that wasn’t an issue for the executive team at all. I believe these issues were only on the agenda because it reached a certain financial threshold. But any senior leader with the same facts presented to them would have been able to make the same decision. Couldn’t these decisions happen in a committee structure better suited to such decisions?
The difference with the problems the executive team failed to solve wasn’t lack of data – they had everything that was available. Indeed one of the characteristics of a complex problem is that there is often insufficient data. What’s required, therefore, is the creation of collaborative knowledge acquisition by the team. The wisdom to know what to do didn’t exist outside of the team in some data as yet undiscovered – the job of the executive team was shared sensemaking to find a way through the messiness.
The role of the team in working effectively with complex problems was in shifting their thinking from objectifying the problem as ‘out there’ through their logical understanding of it, to one in which the framing, scoping and articulating the problem was as much part of the approach to problem solving as the finding of some objective truth.
In my soon to be published research – you can access your copy here – I’ve outlined the ways of thinking, acting and being that executive leaders must become fluent in to lead well in a disrupted world.
Cognitive fluency is the second of these. It’s the ability to be able to consciously work with multiple frames of reference and different types of problems.
Human beings are naturally able to intuitively categorise things (we have no problem seeing that our children ‘operate’ different from our fridge) and to treat different categories of things differently.
Where we do this categorisation both intuitively and, largely, effectively is outside of the work environment. We seem to forget it once we’re in the context of an organisation.
When teams of people are met with organisational problems, it’s all too common to see them apply the wrong logic. So, for example, we apply the rules and assumptions from the physical sciences to those of human and social issues. This is a category error.
When we deploy a category error in solving complex problems we’re faced with a double whammy.
The first is that the problem we are trying to solve is already gnarly and complex. But then we apply the wrong knowledge, rules, assumptions and it leaves the problem unsolved and the problem solver feeling confused and frustrated.
Cognitive fluency is a skillset and a mindset that leaders can hone to consciously both diagnose the category of the problem they are dealing with and then apply or deploy methodologies that are suited to the problem at hand.