Managing Upwards in Complex Programmes — The Structural Story
The programme leader who waits for the escalation path to work has already lost the argument — the real navigation happens in the space between the org chart and the conversation.
The Navigation No Methodology Teaches
Every programme management methodology I have encountered — and the profession has produced no shortage of them — offers a model for governance, for risk management, for benefits realisation, for stakeholder engagement. What none of them offers is a credible account of how a programme leader actually navigates the senior landscape of a large organisation when the programme is under pressure.
This is not an oversight. It is a blind spot that runs deep in the profession. We treat managing upwards as though it were a communication problem — a matter of the right reporting format, the right escalation path, the right frequency of updates. In my experience, it is nothing of the sort. It is a structural problem, rooted in the way large organisations distribute power, allocate attention, and process uncertainty. And until we address it as such, programme leaders will continue to learn the hard way what the textbooks never told them.
The Structural Forces at Work
Consider the position of a programme director running a complex transformation in a large organisation. They sit at the intersection of multiple forces, each pulling in a different direction, and each controlled by someone more senior than they are.
The sponsor wants confidence. They have staked their reputation on this programme, and what they need from the programme director is assurance that their bet is paying off. This is not the same as wanting the truth. A sponsor who hears that the programme is in difficulty does not think first about the programme — they think about what the difficulty means for them. This is not cynicism; it is the rational calculation of someone whose career trajectory depends on a portfolio of commitments, of which this programme is one.
The finance function wants predictability. They have allocated capital on the basis of a business case that was, in all likelihood, constructed under conditions of radical uncertainty and then frozen into a number that everyone treats as though it were a fact. Any deviation from that number triggers a conversation that the programme director does not control and cannot easily win.
The operational leadership wants minimal disruption. They are measured on today’s performance, not tomorrow’s capability. Every demand the programme makes on operational capacity — for data, for testing, for user involvement, for change readiness — is a demand that competes with the operational leader’s own priorities and their own performance metrics.
And the technology function, where one exists as a separate entity, wants architectural coherence. They see the programme through the lens of the enterprise technology estate, and their concerns — about integration, about technical debt, about platform sustainability — may be entirely legitimate but are expressed in a language that the rest of the senior stakeholder community neither speaks nor values.
The programme director does not manage upwards into a unified hierarchy. They manage upwards into a set of competing interests, each with its own logic, its own metrics, and its own definition of what success looks like.
Why the Escalation Model Fails
The standard methodology answer to this complexity is the escalation path. When a programme encounters a problem it cannot resolve at its own level, it escalates — through the governance structure, to the steering committee, to the sponsor, and if necessary beyond. The assumption is that senior authority, once engaged, will resolve the conflict.
This assumption is almost always wrong, and the reasons are worth understanding.
First, escalation is a blunt instrument in an environment that requires precision. The issues that most threaten complex programmes are rarely binary decisions that a senior leader can resolve with a yes or a no. They are tangled interdependencies — resource conflicts, sequencing tensions, scope ambiguities — that require sustained negotiation across multiple stakeholder boundaries. Escalating such issues to a steering committee produces one of two outcomes: a superficial resolution that fails to hold once the meeting ends, or a deferral that sends the issue back down with instructions to “work it out at the programme level” — which is where it failed to be resolved in the first place.
Second, escalation carries a cost that the methodology does not account for. Every escalation signals that the programme director cannot manage their own domain. Used sparingly and at genuine moments of consequence, this cost is worth paying. Used routinely — as the methodology implicitly encourages — it erodes the programme director’s authority, the sponsor’s confidence, and the senior stakeholder community’s willingness to engage constructively with the programme at all.
Third, the escalation model assumes that the governance structure reflects the real power structure. In most large organisations, it does not. The person who can actually unblock a resource conflict may not sit on the steering committee. The person whose quiet opposition is stalling adoption may not appear in any stakeholder map. The escalation path takes the programme director to the wrong room.
The Real Work of Navigating Upwards
What effective programme leaders actually do — the ones who sustain complex programmes through the inevitable turbulence — is something quite different from what the methodology prescribes.
They build what I would describe as a navigational map of the senior landscape. Not a stakeholder matrix — those static grids of influence and interest that look reassuring on a slide but tell you nothing about how power actually flows. A navigational map is dynamic, informal, and continuously updated. It tracks not just who has authority but who has influence, not just who supports the programme but under what conditions that support might be withdrawn, not just who opposes it but what would need to change for that opposition to soften.
This map is built through relationship, not research. It requires the programme director to invest time in conversations that have no immediate transactional purpose — to understand what each senior stakeholder is genuinely worried about, what pressures they are under from their own superiors and peers, what their definition of a good outcome looks like, and where the programme sits in their personal hierarchy of priorities. This is not manipulation. It is the foundation of intelligent navigation.
From this map, the effective programme director makes three kinds of choices that the methodology never discusses.
- What to surface and what to absorb. Not every programme difficulty needs to travel upwards. The programme director who escalates every risk, every delay, every resource tension is not being transparent — they are being overwhelming. The art is in distinguishing between the issues that senior stakeholders need to know about (because they can act, because the consequence affects them, because early warning protects their position) and the issues that the programme team should resolve internally (because escalation will produce heat but not light, because the solution is within the programme’s gift, because the cost of senior attention exceeds the benefit).
- How to frame what is surfaced. The same fact — a three-month delay, a cost overrun, a scope reduction — lands entirely differently depending on how it is framed. This is not about spin. It is about understanding that each senior stakeholder processes information through the lens of their own priorities and risks, and presenting programme reality in a way that connects with that lens. The finance director needs to know what the delay means for the business case. The operational leader needs to know what it means for the go-live impact on their teams. The sponsor needs to know what it means for the narrative they are holding with the board. The same truth, told three different ways, to three different people, with three different implications drawn out. This is not dishonesty. It is the basic craft of communication in a complex organisation.
- When to ask for help and when to ask for cover. These are fundamentally different requests, and conflating them is a common mistake. Asking for help means the programme needs a senior leader to do something — to intervene, to release resources, to make a decision. Asking for cover means the programme needs a senior leader to not do something — to not react to a piece of bad news, to not withdraw support at a moment of vulnerability, to hold the line with their peers while the programme team works through a difficulty. The second request is harder to make and harder for the senior leader to grant, because it asks them to spend political capital without visible return. But it is often the more important of the two.
The Structural Deficit in Programme Leadership Development
The reason this navigational skill remains underdeveloped in the profession is not mysterious. Programme management training and certification are built around process, method, and technical competence. They assume that the organisational environment is a given — a stable context within which the programme operates — rather than a dynamic, political landscape that the programme must continuously navigate.
“We certify programme managers in the mechanics of delivery and then place them in environments where the primary determinant of success is political navigation — a skill we have never taught them and barely acknowledge exists.”
This deficit shows itself most clearly at moments of crisis. When a programme hits serious difficulty — when the business case is under pressure, when the timeline has slipped beyond the point of easy recovery, when a key stakeholder has turned hostile — the programme director who has only process competence is lost. They escalate, they report, they update the risk register, they follow the methodology. And the programme fails anyway, because the methodology has nothing to say about the conversation that needs to happen in the car park after the steering committee, or the lunch that needs to be arranged with the CFO’s chief of staff, or the quiet word that needs to be had with the non-executive who is asking uncomfortable questions at board level.
Towards a More Honest Account
None of this is comfortable territory for a profession that prides itself on rigour, structure, and repeatable method. The skills I am describing are messy, contextual, and resistant to codification. They cannot be reduced to a framework or a maturity model. They are learned through experience, through observation of people who do them well, and through the painful consequences of getting them wrong.
But acknowledging their importance is the first step toward developing them more deliberately. Programme leadership development that includes structured exposure to political navigation — through mentoring, through scenario-based learning, through honest post-programme reflection on what actually determined success or failure — would produce programme leaders better equipped for the reality they face.
The structural story of managing upwards is not a story about communication. It is a story about power, about competing interests, about the gap between how organisations say they make decisions and how they actually make them. Until programme management as a profession takes that story seriously, its practitioners will continue to learn the most important lesson of their careers the hard way: that the programme plan is not the programme, and the governance structure is not the decision-making system.