"Transformational leadership" is a phrase I have been careful with for most of my career. It has been so heavily co-opted by consulting decks that the substance has been hollowed out. I want to write about what the practice actually looks like inside technical organisations, based on the leaders I have learned from and the rooms I have run.
What it is not
Transformational leadership is not a vision deck.
Visions are useful. The decks are useful. They are the artefact, not the practice. A leader can have a strong vision and a clear deck and produce no transformation at all, because the work that follows the deck is the actual job.
Transformational leadership is not the willingness to fire people.
Some leaders are valorised for being decisive about performance. Decisiveness is necessary in some cases. It is not transformation. A leader can fire half the team and produce a smaller version of the same organisation, with the same patterns and the same outputs.
Transformational leadership is not a list of bold initiatives.
The bold initiative is rhetorical. The transformation, if it happens, is in the operational machinery underneath. The initiatives are downstream of the transformation, not the mechanism of it.
What it actually involves
The practice, in technical organisations, has consistent elements.
A diagnosis that the team trusts. The leader has spent enough time inside the work to understand what is broken and what is not. The diagnosis is granular. It names specific systems, specific workflows, specific patterns. The team can read the diagnosis and recognise the organisation they work in. If the diagnosis is generic, the team will treat the leader as performative.
A small set of decisions that are unambiguous. Transformation is paid for in decisions, not in directions. The leader makes specific calls. We will sunset this product. We will reorg along this axis. We will replatform on this stack. The decisions are clear enough that no one is confused about what is being chosen and what is being declined. Decisions that everyone agrees with were not the decisions that needed to be made.
A constant willingness to absorb the operational cost. Transformation is expensive in attention. The leader has to spend time in the rooms where the new patterns are being established, defending the new patterns against drift, and resolving the conflicts that the old patterns produced. This is not a quarterly review activity. It is a daily activity for several quarters.
A bench of mid-level leaders who can be trusted with execution. The most important hires in a transformation are not the senior figures the press release mentions. They are the directors and senior managers who run the new patterns day to day. Without that bench, the leader becomes the single point of failure for the transformation, and the transformation rolls back as soon as their attention shifts.
The technical organisation specifics
Technical organisations have failure modes that transformational leadership has to engage with directly.
The system the team has built is the team's identity. Asking a team to replatform, to deprecate a product, or to change a core architectural pattern is asking them to set aside the work that defines them. This has to be acknowledged explicitly, not steamrolled. The leaders who do this well make space for the grief that comes with the loss, while holding the line on the change.
The senior engineers are often the gatekeepers of the patterns being changed. They have credibility, deep context, and operational responsibility. A transformation that does not bring them along will fail. A transformation that defers to them will not change anything. The leader has to find the middle path. Engage the senior engineers in the design. Listen to their objections. Decide. Be willing to overrule when the design requires it.
The work has to keep shipping during the transformation. Customer-facing systems do not stop while the team is being restructured. The leader has to navigate the trade-off between the speed of the transformation and the steadiness of the operational delivery. Pushing too fast breaks delivery. Pushing too slowly stalls the transformation.
The judgement that is hardest to develop
The judgement that distinguishes the leaders who actually transform organisations is about pace.
Some changes have to be made fast, before the political window closes. Some changes have to be made slowly, because the team needs time to absorb them and the operational risk is high. Confusing the two produces predictable failures.
A transformation that is paced too fast for the team produces resignations and incidents. A transformation that is paced too slowly produces fatigue and reversal. The leader has to read the system well enough to know which kind of change they are making and which pace it requires.
This judgement is built by doing it badly a few times. There is no shortcut. The leaders who learn to read pace correctly are usually leaders who have produced a few transformations that did not go well, learned from them, and adjusted.
What to ask of yourself
A short list of questions I ask myself when I am leading a transformation.
What is the diagnosis, in concrete terms. Have I tested it with people who would tell me if I had it wrong.
What are the few decisions I am taking. Are they unambiguous. Have I been explicit about what is being declined.
Where am I spending my time. Is it in the rooms where the new patterns are being established. Or is it in the rooms where the old patterns are being negotiated about.
Who is on the bench. Are they trusted. Can I let them run. Or am I the single point of execution.
What is the pace. Am I pushing faster than the team can absorb. Am I pushing slower than the political window allows.
The questions are not glamorous. The work is not cinematic. Most of the leaders who actually transform technical organisations are not the ones who feature in the case studies. They are the ones who answered these questions honestly, repeatedly, for several quarters, and let the transformation be a consequence of the answers.