Chapter 24: The Leader Who Has to Change¶
This chapter is not addressed to the engineers who have been overridden. They know the problem.
It is addressed to the leader who made the programme decisions described in Chapter 1. The one who confirmed the delivery date at the first programme board despite the risk register. The one who noted the three red items and moved to task status. The one who accepted the three-point estimate by extracting the best-case number and filing the conditions. The one who, when the programme failed eight months late, concluded that the engineering team had not delivered what they committed to.
This leader is not the villain of the story. Part One was clear about that. They were behaving rationally in the systems they were in — responding to the commercial pressures, the governance cultures, the incentive structures, and the organisational norms that shaped what good leadership looked like in their context. The intent was never to produce a programme that failed. The outcome was produced anyway, by a system that the leader owned without recognising that ownership as the source of their accountability.
This chapter is about what changing that system requires. Not from the system perspective — Part Two addressed that in full. From the personal leadership perspective. What specifically must change in how a leader thinks, decides, and behaves to produce different outcomes. What it costs. And what makes it so consistently difficult even for leaders who genuinely want to do better.
The diagnostic before the prescription¶
Before addressing what needs to change, it is necessary to be honest about how the leader who most needs this chapter will encounter it.
The leader who rubber-stamps gate reviews because the programme needs to proceed on schedule will not read this chapter and think “that is me.” They will read it and think “that is the kind of leader I am trying to avoid being.” The leader who applies pressure to estimates because they believe engineers are sandbagging will not recognise the sandbag assumption as their own belief. They will recognise it as a belief held by other people in their organisation.
This is not hypocrisy. It is the natural human response to diagnostic material that describes a pattern. We see the pattern in others before we see it in ourselves. The specific failure behaviours described in this chapter are behaviours that feel, from the inside, like good leadership — commercial discipline, governance rigour, appropriate challenge of engineering conservatism, maintenance of accountability. They are experienced as their opposites only from the outside — as commercial pressure that overrides honest assessment, as governance theatre that protects the governance layer from accountability, as the undermining of the honest estimation that produced the estimate being challenged, and as accountability displaced onto people who held the accurate information and were overridden.
The diagnostic exercise this chapter asks of the reader is therefore specific: not “do I recognise these patterns in other leaders I have worked with?” but “when I search for these patterns in my own behaviour, under the specific conditions of commercial and delivery pressure, what do I find?”
That is a harder question. It requires accessing memories of specific decisions — not the principles the leader operates by but the decisions they made when the principles were under pressure. The programme board that confirmed the date. The estimate that was challenged. The risk that was noted. The status report that was accepted without the operational knowledge to evaluate it.
The specific behaviours that produce Chapter 1¶
The failure in Chapter 1 was not produced by a single dramatic leadership failure. It was produced by a sequence of governance decisions, each of which seemed reasonable in isolation and collectively produced a programme that failed predictably.
Accepting commitments made without adequate engineering input. The date was set before the engineering assessment existed. The leader who accepted that date — or who allowed it to be set without requiring the engineering assessment first — made a commitment on behalf of people who had not been consulted. This is the commitment problem Chapter 3 described. The specific leadership behaviour that produces it is the acceptance of commercial commitments without the discipline to require that those commitments be grounded in honest engineering assessment before they are formalised.
This behaviour feels like commercial pragmatism from the inside. The client needs a date. The business needs to win the contract. The delay required to produce an honest assessment would cost the opportunity. These are real pressures. They do not change what the behaviour produces: a programme that begins with a committed date that nobody has verified is achievable, handed to an engineering team as a fixed constraint within which they must find a way.
Treating the risk register as a reporting artefact. The programme board reviewed the risk register, noted the three red items, requested mitigation plans, and moved to task status. The specific leadership behaviour that produced this outcome was the treatment of the risk review as an information receipt rather than a decision requirement — the implicit message that the appropriate response to a red item is to acknowledge it and ensure it is being managed, rather than to ask what decision is required from the governance layer and make that decision.
This behaviour feels like appropriate delegation from the inside. The risk register has been reviewed. The risks are known. The programme management layer is managing them. The board’s role is to be informed. But the risks in Chapter 1 were not manageable at the programme management level. They required decisions — client conversations, procurement approvals, independent validations — that were above the programme management layer’s authority. The governance layer’s failure was not ignorance of the risks. It was the failure to recognise that knowing about a risk is not the same as managing it, and that managing it required a decision that only the governance layer could make.
Applying pressure to estimates rather than accepting conditions. When the engineering team produced a most likely estimate of seventeen months against a committed date of fourteen months, the governance response was to challenge the estimate rather than to accept the conditions attached to it. The specific leadership behaviour is the treatment of the gap between commitment and honest estimate as an estimation problem — requiring the engineering team to find a way to close the gap — rather than as a commitment risk that requires governance action to address the conditions.
This behaviour feels like appropriate commercial accountability from the inside. The contract says fourteen months. The estimate says seventeen. Someone needs to find three months of efficiency. That is the engineering team’s job. But the three months were not hidden in the estimate. The estimate was honest. The three months represented the risk that would materialise if the conditions attached to the estimate were not met. Pressuring the estimate to close the gap did not change the conditions. It made the conditions invisible — removing the honest signal from the governance process and proceeding on a fiction.
Governing through task status rather than risks and issues. After the risk register was noted, the programme board review moved to task status — the percentage of tasks complete, the milestone progress, the RAG dashboard. The specific leadership behaviour is the choice of information source — selecting the information that provides reassurance over the information that requires decisions.
Task status provides the appearance of control. It tells the governance layer that things are happening, that progress is being made, that the programme is moving. It does not tell the governance layer whether the programme is moving in a direction that will produce the outcome it is committed to. The risks that will determine that outcome are not visible in task status. They are visible in the risk register — which the governance layer reviewed, noted, and set aside in favour of the more comfortable information.
Displacing accountability when programmes fail. When the programme missed its delivery date by eight months, the lessons-learned exercise concluded that the engineering team had not delivered what they committed to. The specific leadership behaviour is the attribution of failure to execution rather than to governance — the conclusion that the people who held accurate information and were overridden are accountable for the outcome, rather than the people who made the governance decisions that determined it.
This behaviour is not conscious dishonesty. The attribution is genuinely believed. The programme had a committed date. The engineering team delivered eight months after it. The engineering team did not deliver what they committed to. The logic is internally consistent. What it omits is the chain of governance decisions that determined the outcome — the commitment made without engineering input, the risk register noted rather than acted on, the conditions stripped from the estimate, the honest signal suppressed in favour of the comfortable one.
The authority-experience gap — what it requires of leaders¶
Chapter 2 described the authority-experience gap — the structural condition in which leaders with significant programme authority may not have the direct experience of delivery that would allow them to recognise the difference between an honest estimate and a conservative one, between a risk that is being managed and a risk that has been documented, between a governance process that is functioning and one that is performing.
This is not a reason for leaders without delivery experience to defer entirely to engineers on all matters — commercial context, portfolio priorities, and strategic alignment are genuinely the governance layer’s responsibility. It is a reason for leaders without delivery experience to develop specific compensating behaviours that substitute for the experiential knowledge they do not have.
Asking questions rather than asserting conclusions. The leader who does not have the operational knowledge to evaluate whether an estimate is honest or conservative cannot improve their evaluation by asserting the conclusion. “This estimate is too conservative” is not a governance insight. It is a commercial preference presented as an engineering assessment. The question that produces better outcomes is: “Help me understand what makes this the most likely case rather than the best case. What conditions are you assuming about the risks attached to this estimate?” The question creates the space for the honest information. The assertion closes it.
Treating uncomfortable information as valuable. The leader who responds to bad news with questions about why it was not caught earlier, or with pressure to find a way to solve the problem without the governance implication, has taught their team that bad news is dangerous. The leader who responds to bad news with “thank you for telling me early — what do you need from me to resolve this?” has taught their team that bad news is welcome. The difference in the information that subsequently flows is substantial and immediate.
Understanding what you are approving. Gate reviews approved without adequate understanding of what is being approved are not governance. The leader who approves a gate because the programme management team has prepared a good presentation has performed governance theatre. The leader who asks “what would have to be wrong for this gate to not be ready?” — and who is genuinely prepared to receive the answer — is performing governance.
Distinguishing between process compliance and outcome achievement. The process has been followed. The risk register has been reviewed. The gate criteria have been met. The programme is proceeding. This is not the same as the programme being in good health. The leader who conflates process compliance with outcome achievement will be surprised when a programme that followed the process produces the outcome Chapter 1 describes. The question is not “have the governance activities occurred?” It is “do the governance activities produce informed decisions that address the programme’s real risks?”
What it costs to change¶
The behaviours described above are not comfortable to change. They are embedded in governance cultures, reinforced by the incentive structures that determine what gets rewarded and what gets punished, and protected by the social norms that make certain conversations difficult and others impossible.
Accepting a three-point estimate rather than challenging it requires the leader to have a different conversation with the client — a conversation about realistic timelines rather than the commercially convenient one. That conversation is uncomfortable. It risks the relationship. It may cost the contract. The leader who has that conversation is taking a risk that the leader who does not is avoiding. The programme in Chapter 1 represents the consequence of avoiding that risk — an eight-month overrun that cost the programme, the client relationship, and the business substantially more than the month-one conversation would have.
Treating the risk register as a decision instrument rather than a reporting artefact requires the leader to make decisions in programme board meetings that they might prefer to defer. Decisions are uncomfortable. They can be wrong. They carry accountability. Deferral — asking for more information, requesting a mitigation plan, moving to task status — feels more prudent than a decision made on incomplete information. It is not more prudent. It is the systematic accumulation of deferred decisions that arrive as programme failures.
Displacing accountability accurately — attributing failure to the governance decisions that produced it rather than to the execution of the people who held accurate information — requires the leader to examine their own governance behaviour as a cause of the outcome. This is uncomfortable in proportion to the degree of accountability it involves. The attribution to execution is easier. It locates the failure externally. It does not require the leader to change their own behaviour to prevent the next one.
None of these changes are easy. They are, however, available. And they are what the difference between programmes that fail in the way Chapter 1 describes and programmes that do not actually looks like in practice.
The political reality¶
Chapter 5 described the political obstacle most commonly encountered in organisations attempting to change delivery governance: not a named person resisting change, but a system — process as power, plan as authority — that has been designed around the assumption that change is failure and that control produces outcomes.
The leader who wants to change their governance behaviour in an organisation whose culture has not changed will encounter this system. The decision to accept a realistic estimate in an organisation that treats estimate challenge as commercial discipline will be visible as a deviation from the norm. The decision to make decisions on escalated risks rather than request mitigation plans will be visible as a change in governance behaviour that challenges implicit cultural expectations about what programme board members do.
This is not a reason not to change. It is a reason to change with awareness of the political context.
The most effective path through the political obstacle is the one that produces visible results before the politics can close it. A governance behaviour that generates decisions rather than notes, and that prevents a programme failure that the previous behaviour would have produced, makes the political argument for itself. Organisations change their delivery governance norms when they see a different approach produce better outcomes — not when they are presented with a framework that argues for different outcomes in principle.
The practical implication: the first change of governance behaviour should be applied to the programme most likely to succeed with better governance, not to the programme most resistant to it. The first genuine risk register review that generates decisions rather than notes should be on the programme whose risks are most clearly actionable, not the one whose governance culture is most entrenched. Evidence of better outcomes is the most powerful political argument available.
The leader who is the problem¶
Part One made the structural argument that failure is produced by systems rather than by individuals. This chapter has maintained that framing. But there is a specific case that requires direct treatment: the leader whose own behaviour — not the system they are in — is the primary source of the programme’s dysfunction.
The leader who creates fear rather than psychological safety. Who punishes honest risk escalation. Who treats the risk register as evidence of engineering failure rather than as a management instrument. Who makes decisions by overriding the people with the most relevant knowledge and then holds those people accountable for the consequences. Who confuses the appearance of control with the reality of good governance.
This is not a character assessment. These are specific, observable behaviours with specific, predictable consequences. They produce the information environment described in Chapter 18 — one in which bad news travels upward only when it can no longer be avoided, in which risk registers reflect what the governance layer wants to see rather than what the programme needs them to know, in which estimates are calibrated to what will be accepted rather than to what the work requires.
A leader who exhibits these behaviours and reads Firmitas will recognise the failure patterns. They may not recognise themselves in them — for the reasons described at the opening of this chapter. The diagnostic question is not “do these failure patterns occur in my organisation?” It is “when I am under commercial and delivery pressure, what do I do with information that is uncomfortable? How do I respond to an engineering team that tells me the estimate is not achievable? How do I respond when a programme board member raises a risk that requires a decision I would prefer not to make?”
The answers to those questions, observed honestly across the specific decisions of the last several programmes, are the diagnosis. The framework provides the alternative. The change is a choice that only the leader can make.
What changing looks like in practice¶
Structural change does not require dramatic announcements or comprehensive framework rollouts. It requires specific, consistent changes in specific, observable behaviours — the governance behaviours that determine what information the programme produces, how it is used, and what outcomes it generates.
The programme board meeting changes. It starts with escalated risks and issues. It does not move on until the decisions those items require have been made or explicitly deferred with an owner and a date. Task status is reviewed after the risk and issues discussion, not before, and not as the primary governance instrument.
The estimate review changes. The response to a three-point estimate is not a challenge to reduce the most likely case. It is an assessment of the conditions attached to the estimate and the decisions the governance layer must make to create the conditions for the best case to be achievable.
The gate review changes. The question is not “is the gate pack complete and well-presented?” It is “what would have to be wrong for this gate to not be ready, and is there evidence that those things are not wrong?”
The failure attribution changes. When a programme misses its commitment, the first question is not “why did the engineering team not deliver?” It is “which governance decisions shaped the conditions under which this programme was running, and what would different governance decisions have produced?”
None of these are process changes. They are governance behaviour changes — specific, deliberate changes in how the leader uses their authority in the governance moments that determine whether the programme’s honest information reaches the people who can act on it, and whether those people act on it.
That is what change looks like. It is not a transformation programme. It is a decision, made repeatedly in the specific moments when it is uncomfortable, to govern differently from the way the system has always governed.
It is available to every leader who is willing to look honestly at the specific decisions they have made and ask whether different decisions would have produced different outcomes.