The leadership contract behind effective program delivery

Jon Dunn

Published: October 09, 2026

Large transformation programs rarely fail because nobody designed a governance model; they fail because the model isn’t experienced consistently, by teams, in the flow of work.

Even if the organization has a program structure, robust role descriptions, forums, backlogs, risk logs and delivery cadences, it’s not uncommon to find teams waiting for permission, decisions to be revisited, meetings multiplying and dependencies remaining implicit. Bad news travels slowly, which holds up positive change.

This is rarely a problem of documentation; it’s really about leadership. More precisely, it’s a gap in the leadership contract: the unwritten agreement about who sets direction, who decides, how challenge is handled, what accountability means and how authority moves as people gain confidence.

I recently worked through this challenge in a complex transformation involving a large operational organization, a strategic capability and several multidisciplinary delivery teams. The specific context is deliberately removed here, but the lessons are applicable to program leaders working in technology, data, product, operations and organizational change.

The central lesson is this:

Empowerment isn’t about removing accountability; it’s the deliberate transfer of decision-making authority to the people with the best information, within clear outcomes and guardrails.

Actually doing this in practice is where things get challenging; and that’s what I’m going to focus on here.

The operating model is only real when people use it under pressure

Many organizations announce a move towards product-led, cross-functional or empowered teams. They change team structures, rename roles and introduce new ceremonies. But if leadership behavior remains unchanged, the old system survives inside the new design.

Teams may be told they own outcomes, even while important decisions continue to be made elsewhere. They may be asked to move quickly despite every meaningful choice requiring approval. They’re probably encouraged to challenge assumptions even though disagreement gets treated as disruption. They’re granted autonomy, but only after producing enough material to make autonomy unnecessary.

The result is a confusing hybrid:

New structures with old decision rights.
New ceremonies with old management habits.
New language with old incentives.
New accountability without corresponding authority.

People experience this ambiguity as control. When nobody knows who can decide, the safest behavior is to wait, escalate or seek retrospective permission. This is why the first test of an operating model isn’t whether it’s been published, but whether a team can answer, in the moment:

What outcome do we own?
What decisions can we make ourselves?
What constraints must we respect?
Who needs to be consulted?
What would require escalation?
What evidence would change our direction?

If the answers to these questions are unclear, the operating model is not yet operational.

Leadership should set intent, not prescribe every move

The most useful shift in an empowered delivery model is from controlling execution to creating the conditions for good decisions.

Leaders should provide:

A clear problem to solve.
The outcome that matters and why it matters.
The priority and the main trade-offs.
Constraints that cannot be breached.
Access to the right context, data and stakeholders.
Support, coaching and obstacle removal.
Clear thresholds for escalation.

The team should determine how best to achieve the outcome within those boundaries. This doesn’t mean an absence of leadership; it should instead be understood as leadership at the right altitude.

A useful example is a team asked to improve the performance of an important operational capability. A directive-led approach would specify the technical task: optimize a particular component, migrate a particular service or rewrite a particular query.

An intent-led approach would say:

Reduce response time to the agreed target, protect the integrity of the existing decision logic, maintain compliance and demonstrate the improvement with evidence.

The team may discover the bottleneck isn’t where it expected. It may choose to change a data access pattern, simplify an interface or run a controlled experiment. Ultimately, the team owns the reasoning and the consequences while leadership owns the clarity of the intent and the quality of the boundaries. This distinction matters because delegating a task isn’t the same as delegating authority.

If leaders retain control of every important decision, they’ve created task distribution, not empowerment.

Decision rights are a delivery mechanism, not a governance document

A 'decision rights' model is often treated as an organizational design exercise. It is more useful when treated as a delivery tool. For each significant area of work, teams need a lightweight view of four categories:

Decisions the team can make independently.
Decisions requiring consultation with a named person or forum.
Decisions requiring approval because of material risk, cost, safety, security, regulatory or policy impact.
Decisions retained by program, product, business or portfolio leadership.

The aim is not to document every possible decision. The aim is to remove hesitation from the decisions that recur in delivery.

The most effective decision-rights models also define escalation triggers. For example, escalation may be required when a decision changes the intended outcome, affects another team’s interface, breaches a guardrail, moves a committed milestone beyond tolerance or requires authority that is not available locally.

This creates a useful principle: escalate because the impact exceeds the boundary, not because the decision feels uncomfortable.

That principle protects both speed and safety. It allows teams to decide locally while ensuring that decisions with wider consequences receive the right level of scrutiny.

Program leadership is about integration, not supervision of every team

A program exists because the whole is more than the sum of its projects, products or delivery increments. Its role is to coordinate outcomes, dependencies, sequencing, risk, readiness and benefits. It shouldn’t become a remote control for every team.

A practical division of accountability looks something like this:

Portfolio or executive leadership decides whether the investment, strategic priority and risk appetite remain right.
Program leadership coordinates the integrated outcome, dependencies, capacity, milestones, risks and benefits.
Product leadership steers value, direction and evolution.
Product ownership sequences near-term work and accepts increments against clear criteria.
Delivery leadership enables flow, transparency, forecasting and impediment removal for a defined area.
Technical leadership and the delivery team decide how to build safely and effectively within agreed boundaries.
Business and operational owners provide acceptance, readiness, ongoing service ownership and benefits realization.

These roles are complementary rather than hierarchical. The same person may perform more than one role in a smaller setting, but the accountabilities should remain explicit.

The program leader’s question should rarely be, “Why did the team choose this implementation?” Instead, it should more often be:

Is the program still pursuing the right outcome?
Are the dependencies visible and actively managed?
Are decisions being made at the lowest sensible level?
Is the organization ready to adopt and operate what is being delivered?
Are we building a capability that can continue without the original team or supplier?

That is the difference between program coordination and program interference.

Governance should increase confidence, not create a queue

Good governance is not the same as more governance. A useful governance system has different speeds for different decisions:

Portfolio cadence for investment, capacity and strategic priority.
Program cadence for outcomes, dependencies, benefits, readiness and material risks.
Product cadence for roadmap and value sequencing.
Team cadence for backlog, quality, delivery flow and learning.

Each forum should have a clear purpose, the right participants and a defined output. If a meeting isn’t reaching a decision, resolving a blocker or dependency, collaborating on work, inspecting evidence or improving the system, it should be shortened, combined or removed.

Visibility should come from lightweight artefacts rather than universal attendance. Useful artefacts include:

An integrated roadmap.
A decision log with owner, rationale and consequence.
A risk and dependency view with next actions.
A delivery forecast that shows confidence, not only activity.
A benefits view connected to measurable outcomes.
An operational readiness and ownership view.

The test for any artefact is simple: does it improve a decision, make uncertainty visible or reduce coordination cost? If not, it’s probably administrative residue.

The transition into delivery is a change program in its own right

One recurring failure point is the transition from discovery into delivery. Discovery creates insight, decisions and possible solutions. Delivery requires a shared operating rhythm, clear ownership, usable backlogs, agreed evidence, realistic capacity and a way to handle what is still unknown.

The assumption that teams will naturally move from one mode to the other is dangerous. A deliberate transition should make the first delivery period explicit:

What outcome is being pursued?
What is the smallest valuable slice?
What is known, assumed and still open?
What evidence will demonstrate progress?
Which dependencies matter now?
What decisions can the team make?
What support will be available?
How will the team learn and adjust?

This isn’t a request for exhaustive up-front specification. It’s a request for enough shared understanding to begin safely and learn deliberately.

The first few delivery cycles should be treated as an adoption experiment. Leaders should observe where the model creates friction, adjust the support, protect specialist build time and use evidence before scaling the approach further.

A team isn’t empowered because a presentation says it’s empowered. It becomes empowered through repeated experience of making decisions, receiving constructive challenges, seeing those decisions stand and learning from the consequences.

Psychological safety is an operational control

Psychological safety is sometimes presented as a cultural benefit separate from delivery discipline. In complex programs, it’s an operational control.

If people don’t feel safe to raise uncertainty, the program loses access to early warning signals. If people are punished for bad news, the organization receives good news until the problem is too large to ignore.

High support does not mean low standards. High challenge does not mean public humiliation. The productive combination is high challenge and high support:

Ask difficult questions about assumptions, evidence, value, risk and quality.
Challenge the thinking, not the person.
Invite dissent before important decisions close.
Thank people for surfacing risks.
Separate learning from blame.
Give direct feedback privately and recognition appropriately.
Make it safe to say, “I do not know,” “I disagree” or “we need help.”
Hold people accountable for what they do with feedback and new evidence.

The real test comes under pressure. Many leadership teams can describe healthy behaviors when the program is calm. The question is what happens when a milestone is threatened, a dependency fails or an executive asks for certainty that the evidence does not support.

Perverse incentives and the necessity of a ‘Just Culture’

Beyond immediate team dynamics, psychological safety is heavily governed by the organization's broader incentive structures. In many transformation programs, perverse incentives reward quiet disempowerment while severely penalizing visible, transparent failures. When leaders risk public censure or career damage for exposing emergent risks, the rational response becomes risk aversion: holding tight control, burying bad news or legislating to avoid individual liability.

Addressing this requires adopting Sidney Dekker’s concept of a Just Culture. A Just Culture draws a clear distinction between human error or honest mistakes — which arise in complex systems and should be met with learning — and intentional malicious behavior or reckless disregard for safety, which warrants disciplinary action. When leaders lack this distinction, driven by fear and misaligned metrics, they tend to legislate for the worst-case scenario. They implement oppressive compliance gates that stifle innovation, slow delivery flow, and undermine trust across teams.

To establish true psychological safety, organizations must realign incentives so that surfacing early truth is recognized as constructive stewardship, and systemic improvement takes precedence over assigning personal blame.

That's when the leadership contract becomes visible.

Resilience means designing for continuity, not individual heroics

A useful test for any role is:

If I were unexpectedly unavailable tomorrow, would the work continue safely, effectively and transparently?

This isn’t a question about making people personally replaceable; it’s a test of organizational resilience.

At team level, resilience means shared documentation, visible decisions, pairing, cover and clear runbooks. At program level, it means an integrated view of commitments, dependencies, risks, capacity and readiness. At senior level, it means building the capability, ownership model and investment conditions required for the organization to continue beyond the immediate delivery horizon.

Handover should therefore not be treated as a final event. It should be demonstrated progressively through:

Shared knowledge.
Transferable processes.
Operational readiness.
Clear ownership.
Accessible evidence.
Practical capability transfer.
The ability to operate, govern and evolve the product or service after delivery support reduces.

The outcome isn’t simply a delivered solution, but is rather durable organizational capability.

The most effective interventions are usually small and visible

When an operating model is struggling, the instinct is often to create more documentation, add a new forum or launch another communication campaign. Sometimes those things are necessary. More often, though, the better intervention is smaller and closer to the work:

Close every material decision with an owner, rationale, consequence and next date.
Bring the supplying and consuming teams together around the next real dependency.
Replace a general role workshop with a live decision about who owns the outcome.
Review recurring meetings and remove those without a clear purpose.
Use a short readiness conversation before work enters a delivery cycle.
Make the end-to-end flow visible through the next thin slice.
Let one group demonstrate the desired behavior, then transfer facilitation to the client team.
Measure decision age, blocker age, build time and early risk visibility rather than attendance at ceremonies.

These interventions work because they make the operating model tangible. They change what people experience, not only what they have been told.