Stop Managing Stakeholders. Start Engaging Them.

A transformation programme usually has a stakeholder plan.

Stakeholders are mapped.

They are categorised.

They are assigned communication plans.

They receive updates.

They attend steering meetings.

They are asked for feedback.

Then the programme moves forward.

The problem is simple.

Being informed about a transformation is not the same as helping shape it.

The executive question is not:

“Have we communicated with our stakeholders?”

The better question is:

“Who needs to participate in shaping the solution?”

A stakeholder who receives a presentation knows what the programme decided.

A stakeholder who helps shape the decision understands the trade-offs, contributes operational knowledge and has a stake in making the decision work.

Communication creates awareness. Participation creates ownership.

Stakeholder management starts with the wrong question

Most stakeholder approaches begin with:

Who needs to be informed?

The question sounds reasonable.

It also frames stakeholders as recipients.

A transformation affects different groups in different ways.

Some hold decision authority.

Some understand the customer.

Some understand the process.

Some operate the technology.

Some carry the operational risk.

Some know where previous transformations failed.

Some understand local conditions that do not appear in the programme design.

Treating all of these people as communication audiences loses valuable knowledge before the transformation begins.

The better starting point is:

Who has knowledge, authority, influence or accountability relevant to this outcome?

That question changes the engagement model.

A stakeholder map is not an engagement model

A stakeholder map tells you who matters.

It does not tell you how they should participate.

A transformation needs more than names, influence scores and communication preferences.

For each important stakeholder or stakeholder group, ask:

• What knowledge do they hold?
• What decision affects them?
• What decision could they influence?
• What authority do they have?
• What outcome do they own?
• At what point is their input required?
• What happens when their view conflicts with another stakeholder?

This turns stakeholder management from a contact exercise into an operating mechanism.

Communication is not participation

A transformation programme can communicate continuously and still exclude stakeholders from meaningful decisions.

Town halls create awareness.

Newsletters distribute information.

Dashboards provide visibility.

Steering meetings create a governance forum.

None of these activities guarantees participation.

Participation requires a different question:

What part of the transformation are stakeholders helping shape?

That might include:

• defining the problem
• testing the business case
• shaping requirements
• identifying operational constraints
• designing the future process
• sequencing implementation
• defining controls
• testing adoption
• validating benefits

If stakeholder input never has the possibility of changing a decision, the activity is communication or consultation.

It is not meaningful participation.

Participation should follow the decision

Not every stakeholder needs the same level of involvement.

The right level depends on the decision.

A useful progression is:

Inform → Consult → Contribute → Co-design → Decide → Own

Inform when awareness is sufficient.

Consult when experience or opinion is required.

Contribute when specialist knowledge affects the solution.

Co-design when the stakeholder is part of shaping the future state.

Decide when formal decision authority sits with the stakeholder.

Own when the stakeholder carries accountability for the resulting outcome.

The mistake is treating seniority as the primary determinant.

A senior executive might need to decide.

A frontline employee might need to co-design.

A regional process owner might need to challenge a global standard.

A technology architect might need to contribute without owning the business outcome.

Participation should follow the decision.

The people closest to the work hold critical knowledge

Transformation teams often have strong programme knowledge.

They know the roadmap.

They know the architecture.

They know the milestones.

They know the business case.

Operational teams know something different.

They know how the work actually happens.

They know where exceptions occur.

They know which process steps depend on informal work.

They know which customer expectations are difficult to see from the centre.

They know which controls create friction.

They know which previous decisions created workarounds.

This knowledge matters before the solution is designed.

The lesson is straightforward:

Do not wait for adoption to ask the people doing the work whether the solution will work.

Ask before the design hardens.

Engagement should change the solution

This is the test most stakeholder plans avoid.

What changed because stakeholders participated?

If the answer is nothing, the programme should ask why.

Meaningful engagement might change:

• the target process
• the technology requirement
• the sequence of deployment
• the control model
• the operating model
• the adoption approach
• the benefit assumption
• the implementation timeline

Participation does not mean every suggestion gets accepted.

It means relevant input receives consideration and has a visible path into the decision.

The distinction matters.

Input without influence is feedback collection.

Input with influence is participation.

Not every stakeholder gets a veto

There is another mistake on the other side.

Participation does not mean consensus.

Transformation still requires decisions.

Someone needs authority to decide when stakeholders disagree.

The operating model therefore needs four clear roles:

Who contributes?

Who recommends?

Who decides?

Who owns the outcome?

These roles do not need to belong to the same person.

A process expert might contribute.

A transformation lead might recommend.

An executive might decide.

A business owner might remain accountable for the outcome.

This is where stakeholder engagement connects directly to governance.

Without decision rights, participation turns into discussion.

Without outcome ownership, participation ends when the workshop ends.

Local participation matters in global transformation

Global transformation makes the distinction even more important.

A central team might define the global ambition.

A global architecture team might define common principles.

A programme office might define the deployment model.

But local teams experience the transformation through local customers, processes, regulations, data, suppliers, skills and operating practices.

Global Standardisation Does Not Mean Global Uniformity established the principle:

Global standardisation does not mean global uniformity.

This piece takes the argument one step further.

Local variation needs local knowledge.

If local stakeholders participate only after the global design has been finalised, their role becomes exception management.

The better approach is earlier participation.

Ask local teams:

• What must remain common?
• What needs local configuration?
• Which assumptions do not hold locally?
• Which risks are invisible from the centre?
• What would prevent adoption?
• Which variation improves the outcome?

This turns local stakeholders from recipients of the global model into contributors to its design.

Engagement is a feedback loop

Participation should not happen once.

A transformation evolves as evidence appears.

A stakeholder might influence the initial design.

New evidence might challenge the assumption.

The solution might need to change.

The stakeholder needs to see what happened to their input.

The loop becomes:

Input → Interpretation → Decision → Response → Adaptation → Outcome

The response matters.

If stakeholders provide information and never see how the information affected the decision, participation loses credibility.

Engagement therefore needs closure.

Not every recommendation will be accepted.

Every significant recommendation should have a visible disposition.

Accepted. Rejected. Deferred. Tested. Escalated.

The reason matters as much as the decision.

The shadow operating model starts where engagement fails

Formal operating models describe how work should happen.

Transformation programmes describe how change should happen.

Neither always captures how people actually get decisions made.

When formal engagement fails, informal mechanisms appear.

Side conversations.

Unofficial approvals.

Personal escalation routes.

Spreadsheets.

Local workarounds.

Preferred contacts.

Shadow forums.

Undocumented exceptions.

These mechanisms are often treated as resistance.

Sometimes they are.

Sometimes they are evidence.

They show where the formal model does not provide enough access, authority, information or responsiveness for the work to function.

The previous piece called this the invisible operating model.

This piece adds another dimension:

The invisible operating model often reveals where stakeholders have been excluded from the formal one.

The response should not always be to eliminate the informal behaviour.

First ask why the behaviour exists.

Engagement creates ownership

Ownership does not begin when a name is added to a governance chart.

Ownership grows when people understand the outcome, contribute to the design and accept responsibility for making the new model work.

This creates a useful progression:

Participation → Influence → Understanding → Commitment → Ownership → Adoption

The progression also explains why communication-heavy transformations often struggle.

People receive the case for change.

They receive the future-state design.

They receive training.

They receive implementation dates.

Yet they never had a meaningful role in shaping the change.

The programme then describes resistance as a people problem.

Sometimes the design created the resistance.

Measure engagement by influence, not activity

Transformation teams often measure stakeholder engagement through activity.

Number of workshops.

Number of meetings.

Attendance.

Communications sent.

Stakeholder groups contacted.

These measures show effort.

They do not show influence.

Better questions include:

• Which decisions were influenced by stakeholder input?
• What changed because stakeholders participated?
• Which operational risks were identified early?
• Which assumptions were challenged?
• How many stakeholder concerns remain unresolved?
• Where did local input change the design?
• How quickly were stakeholder issues resolved?
• Which stakeholder groups show adoption?
• Where are informal workarounds appearing?
• Which benefits depend on stakeholder behaviour?

The measure should move from:

“How much engagement did we conduct?”

to:

“What changed because stakeholders participated?”

Engagement is an operating capability

Stakeholder engagement is often placed inside communications or change management.

The stronger position is broader.

Engagement affects:

• decision quality
• operating-model design
• adoption
• risk
• governance
• local execution
• benefit realisation
• organisational capacity

This matters because transformation rarely sits within one team's authority.

The people required to deliver the outcome often sit across business units, functions, regions and technology teams.

The transformation therefore needs a mechanism for bringing their knowledge into decisions.

Engagement is one of those mechanisms.

The executive test

Before approving the next major transformation decision, ask:

1. Who needs to participate in shaping this decision?

2. Which stakeholders hold knowledge the programme does not?

3. Where does stakeholder input have genuine influence?

4. Which decisions require participation rather than communication?

5. Who contributes, who recommends, who decides and who owns the outcome?

6. Where does local knowledge need to influence the global design?

7. What changed because stakeholders participated?

8. Where are stakeholders working around the formal model?

9. How are unresolved concerns being handled?

10. Who owns the outcome after stakeholder participation ends?

These questions expose the difference between stakeholder activity and stakeholder influence.

From stakeholder management to stakeholder participation

Stakeholder management starts with a list.

Stakeholder engagement starts with a decision.

The difference matters.

A list tells the programme who needs attention.

A decision tells the programme where participation is required.

The stronger model is:

Inform → Consult → Participate → Influence → Decide → Own → Adopt → Realise

Not every stakeholder needs to be involved in every decision.

Not every decision needs consensus.

Not every stakeholder has the authority to decide.

But every important transformation decision should make participation deliberate.

The objective is not more stakeholder meetings.

The objective is better decisions, stronger ownership and fewer surprises when the solution reaches the organisation.

Stakeholders should not only receive the transformation.

They should help shape the transformation they are expected to deliver, operate and sustain.