Complexity Is Not a Theory Problem
By Chris and Penny Hamlin
There's a story engineering leaders sometimes tell themselves about complexity. It goes like this: complexity is a concept — a theoretical framework, a problem that can be understood and solved for — and once they've understood the idea, they'll know what to do about it on Monday morning.
It's a tidy story. It is also wrong in a way that costs organisations real time, real money, and real people.
Complexity is not a theory problem. It is an operational one. It does not yield to better models. It yields to a different kind of attention, a different repertoire of leadership moves, and — uncomfortably — a different relationship between senior engineers and the systems they are responsible for.
This is the second piece in the HancockHamlin series on the gap between how engineering leaders are trained and what they are actually being asked to do. The first piece argued that the gap exists. This one argues something harder: it cannot be closed by reading more about it.
Where the misunderstanding starts
Most senior engineers come up through environments that prize the same set of moves: decompose the problem, understand the components, recombine them into a working whole, instrument it, optimise it. That is good engineering. It works extraordinarily well on systems that are intricate but knowable — what Cynefin would call complicated. Most of an engineer's professional formation, the qualifications, the tooling, the language, sits squarely in that domain.
The trouble is that engineering leaders are increasingly not running complicated systems. They are running complex ones — socio-technical systems whose behaviour emerges from interaction patterns that no individual component, no individual team, and no individual leader fully controls. Supply chains touched by politics. Regulatory environments touched by environmental issues. Engineering organisations touched by the hiring market and by the mental health of the people inside them.
When you take a leader trained for complicated and put them in front of complex, they do what they were trained to do. They decompose harder. They optimise faster. They escalate from "investigate" to "intervene" too soon. And the system, perversely, gets less coherent.
It is not a failure of capability. It is a category error.
What people mean when they say "this is theoretical"
A pattern shows up almost every time we run this material with cohorts of senior leaders — including last week, when we delivered a joint workshop for senior leadership students from Northumbria University's Senior Leader Higher Apprenticeship and the Master of Business programme at Offenburg University. The room spanned sectors and nationalities, which is partly the point. The principles of leading complex change are not engineering-specific; the engineering leaders in the room recognised the same arc as everyone else, and tracked it, in our experience, more acutely.
At the end of day one, we shared Dave Snowdon’s infamous birthday party narrative (1) with the cohort . This succinctly exposes how adopting conventional scientific management in a complex system is wholly inappropriate and allowed the group to access their intuitive humanity in a systematic and robust way. The idea of complexity moves from being theory to being something that can be experienced.
That moment matters because it is the point at which complexity stops being a concept on a slide and starts being a description of the room. The leader is no longer thinking about complexity. They are inside an instance of it. And the question that follows — "so what do I do?" — is the question this work exists to answer.
When senior engineers tell us complexity feels theoretical, they almost never mean the model is wrong. They mean the model has not been connected to the action. The diagnostic exists; the practice does not. That gap is closable, but only by taking the practice as seriously as the theory.
Three concrete shifts that move complexity out of theory
From everything we have observed across cohorts of senior leaders — including the live conversations in last week's workshop — three shifts make the most difference. They apply broadly across senior leadership; they are particularly apposite for engineering leaders, because the gap they address is most acute when the leader's training was technical.
1. Shifting the unit of analysis from the technical system to the system-around-the-system
The most experienced engineers in a room can usually describe their technical system in remarkable detail. Asked to describe the human system the technical one sits inside — the decision-making patterns, the political constraints, the implicit incentives — they often pause. Not because they cannot see it, but because they have never had it formally named as part of their job.
It is. The first shift is to make that wider system as legible to the engineer as the technical one. Once it is legible, it becomes leadable.
2. Treating uncertainty as information rather than as a problem to be eliminated
Engineering culture, broadly, treats uncertainty as a defect to be reduced if not eliminated. In complex systems, uncertainty is not a defect — it is a signal about which parts of the system you do not yet have a relationship with, and the very thing that creates the space for creativity, where opportunity emerges. Shrinking the uncertainty too aggressively shrinks the relationship and stymies the imagination. The leader who has learned to hold uncertainty for long enough to listen to it has a different operating range from the one who has not.
Last week’s joint workshop showed how an accidental complex situation caused by IT challenges became a catalysing activity. The individual teams overcame these difficulties in their own unique ways, with no need for an imposed solution. The very fact of coming together in adversity fast-tracked the team formation activity and established deeper connections, respect and collaboration. Embracing the uncertainty and allowing teams to find their own path through it gave them agency and built trust in an unfamiliar environment. It provided the space and platform for ongoing creativity and collaboration.
3. Building reflective infrastructure as part of the operating model, not as an annual training event
Engineering leaders develop themselves the way engineering systems develop: through repetition, feedback, and deliberate adjustment. Most are doing this informally — over coffee, in the car park, in the post-mortem that ran over. Few are doing it as a designed feature of how the organisation operates.
Reflective infrastructure — coached conversations, structured peer dialogue, deliberate space for sense-making — is not a soft layer on top of the engineering. It is part of how complex systems get led well. Treat it as overhead and the gap stays open. Treat it as core, and senior engineers start to grow into the leaders the system actually needs.
Why "more theory" is the wrong response
Faced with the gap, the instinct of most engineering organisations is to commission more reading. Another framework. More systems thinking training. Another off-site. The leaders attend, absorb and agree conceptually, but on Monday morning find it has not changed what they actually do.
This is not because the frameworks are bad. Complexity science, systems thinking, the broader complexity literature — these are useful instruments. But an idea is not a practice. A map is not a route. The reason engineering leaders feel underequipped is not that they have not read enough; it is that they have not had structured opportunities to make the moves the frameworks describe, in the company of other senior engineers doing the same, with someone whose job is to help them notice what is happening.
The work that closes the gap is therefore not more material. It is structured practice — situated in the actual organisations these leaders are running, anchored to the actual decisions they are facing, and held by people whose own working life has been spent inside complex engineering environments.
What this looks like for an engineering leader
If the argument lands, the implication for any individual engineering leader is reasonably plain. The development that will most expand your operating range is not another technical course and not another generic leadership programme. It is a deliberate, repeatable practice of leading inside complexity, with feedback you trust, alongside peers who share the context.
That is harder to find than it should be. It is what we are building.
Coming next
Over the next two weeks Chris and Penny will publish companion pieces on what each of these three shifts looks like in practice — including specific moves senior engineers have used to install them in their own teams. There is also news at the end of this week about how engineering leaders can take the next step.
References: