The Form Is the Failure: Why Engineering Leadership Development Keeps Missing

By Chris and Penny Hamlin

Picture an organisation that has done everything right. It has accepted that its senior engineers are running into something their technical training never prepared them for. It has taken on board that this is not a personality problem but a mismatch between the work people were trained for and the work they were promoted into. It has even accepted the harder point: that you cannot close the gap by reading about it, that complexity is operational rather than theoretical, and that what is needed is practice, not more content. So it commissions a leadership development programme built around practice. Good facilitators. Real exercises. Warm feedback in the room.

Twelve months later, very little has changed.

This is the part of the story that gets the least attention, and it is the most important. The organisation did not fail because it chose poor content. In many cases the content was excellent. It failed because of the form the development took. And the form, it turns out, is doing far more of the work than anyone tends to admit.

This is the third piece in our series on the gap between how engineering leaders are developed and what they are actually being asked to do. The first piece argued that the gap is real. The second argued that it cannot be read or instructed across. This one argues something more uncomfortable for the whole development field, ourselves included: that most of how leadership development is structured is quietly destined to fail at precisely the thing engineering leaders need most.

Content is not the problem. Form is.

We have already made the case that engineering leaders do not lack for material. The frameworks exist, the reading is plentiful, and the diagnosis is by now reasonably well understood. The reframe at the centre of this piece is the next step: even the right content, delivered through the wrong structure, will fail to build the capability it describes. The question worth asking of any development programme is not only what it teaches, but what shape it takes. And on closer inspection, the standard shape is misaligned with the capability it aspires to create in three specific and reinforcing ways.

The first failure: the generic cohort

Most leadership programmes assemble their participants horizontally, by seniority, across functions and sectors, on the theory that leadership is a generic capability and that mixing backgrounds enriches the room. For some purposes it does. For engineers crossing the complexity threshold it strips out the one thing that makes their development land, which is shared professional context. An engineer who has to spend the first portion of every conversation explaining what a P&ID is, why a turnaround cannot simply be moved, or what it means to carry process safety accountability, never reaches the actual work. Context here is not background colour. It is the medium in which an engineer's judgement was formed, and it cannot be redeveloped in its absence. The other engineers in the room are not a logistical convenience. They are, as we will argue at greater length in the next piece, the most underused developmental resource in the building.

The second failure: the event

Development is sold and bought in discrete units: the two-day offsite, the module, the residential, the programme with a clean beginning and end. This suits diaries and budget lines. It does not fit the capability it should be building. No engineer acquired technical judgement at an event. They acquired it over years, through repeated contact with real problems, with feedback from people who could see what they could not yet see for themselves. The capacity to lead in complexity is built the same way, because it is the same kind of learning. A learning event can open a door. It cannot build a practice. When the development stops, the leader walks back into an organisation that has not changed, applies the insight alone, and watches most of it evaporate within a fortnight.

The third failure: the expert at the front

The default shape of a development event is an expert at the front, transmitting what they know to an audience who receive it. This is a perfectly sound way to convey complicated knowledge, the kind that has a right answer which can be taught and then verified. It is the wrong shape entirely for complex capability, because judgement under ambiguity cannot be transmitted. Nobody can hand you the ability to read a room that will not move, to hold an uncertainty long enough to learn something from it, or to act without the comfort of a model that guarantees the outcome. That capability is developed by working real problems in conditions close to the real ones, with someone alongside you whose role is not to supply the answer but to help you notice what is happening as you reach for it. The distinction is the whole point: the help that works is practitioner-facilitated, not expert-led.

Why these failures are structural, not accidental

It would be easy to read all of this as a complaint about lazy providers. It is not. These three failures are not mistakes by individual programmes; they are the predictable output of how development is commissioned and procured. Generic cohorts are easier and cheaper to fill than context-specific ones. Events fit neatly inside budget cycles and can be counted, tracked and signed off. The expert-led model fits the way organisations account for value, because we can see what we paid for when we paid for the expert. Every incentive in the commissioning system selects for the form that is easiest to buy, and the form that is easiest to buy is the one least able to build the capability in question. This is why the problem persists even when everyone involved is competent and well intentioned. We keep solving the wrong problem, because the system that purchases the solution is optimised for the wrong variables.

And the cost of getting this wrong is rising. As we argued at the start of this series, AI and digital tooling are absorbing the complicated work and pushing engineers into complex, ambiguous territory sooner, and in greater numbers, than before. The window in which the new capability has to be built is narrowing, while the development system that should build it remains structurally stuck in the old shape. The gap is widening, and the standard response is becoming less fit for purpose, not more.

What actually closes the gap

If the failures are structural, then so is the answer. The development that closes the gap shares three features, and each is the inverse of one of the failures above.

It is situated. It is anchored to the real decisions the leader is facing, inside their own organisation, rather than to invented or simplified case studies that resolve too cleanly. The problem the leader brings is the curriculum.

It is peer-held. It happens alongside other engineers who share the context, who do not need the acronyms explained, and who recognise the problem because they are living a version of it themselves. There is a particular relief in that recognition, and it is not a soft benefit. It is the condition under which honest reflection becomes possible at all.

And it is practitioner-facilitated. It is held by people whose own working life has been spent inside complex engineering and socio-technical environments, and whose job is to help participants notice and adjust, not to lecture them. We can be direct about why we trust this form. It is the form through which we were developed ourselves, in the coaching and systems traditions we came up through, and the form we have seen change how capable people lead. The mechanism is not mysterious. It is simply, and tellingly, the form that is hardest to buy and therefore the one rarely commissioned.

We’ve experienced this personally. It’s the way that coaches are trained, and it’s universally the way that personal transformation and growth journeys are enabled. The theory is relevant, and there’s a place for expert-led teaching, but learning ornithology doesn’t make you a bird, and understanding angular momentum isn’t how you learn to ride a bike.

Beyond the Blueprint

This is the thinking behind Beyond the Blueprint, the programme we have been building and are now opening. It is an seven-month cohort programme for engineers and STEM professionals who are crossing, or have recently crossed, the complexity threshold. It is situated in the real challenges participants bring, held by a peer cohort of engineers who share the professional context, and facilitated by practitioners rather than delivered by an expert at the front. It is structured as a sustained practice rather than an event, because that is the only structure that builds the capability it concerns itself with. The founding cohort begins in October 2026. To explore whether it fits your situation, take a look at the programme and complete the Explore Further form.

If the argument across these three pieces holds, then the most important decision an organisation makes about developing its senior engineers is not which content to buy. It is which form to commission. Get the form wrong and the best material available will not survive contact with Monday morning. Get it right and something that has felt intractable begins, quietly, to move. The open question is no longer whether engineers can learn to lead in complexity. It is whether we are willing to build the kind of opportunity in which that learning can actually happen.

Image credit: AI-generated image created with ChatGPT Images by OpenAI, prompted by PJ Hamlin, 8 June 2026.