Three weeks before go-live, line managers receive a cascade pack. Twelve slides, a set of key messages, and a request to brief their teams by Friday.

They are the group most responsible for whether the change holds, and the group told about it last. They are expected to answer questions they have not been briefed on, about a system they have not used, while delivering the same operational numbers as last month.

Then, when adoption is patchy afterwards, the finding is that manager reinforcement was inconsistent.

It was. That was designed in.

Managers are an affected role that nobody assesses

Here is the structural error, and it is visible in almost every impact register.

Programmes assess what changes for end users. They do not assess what changes for the manager of those users — because the manager is treated as a delivery channel for the change rather than as somebody experiencing one.

But the manager’s job changes materially at go-live. Their team’s output will dip and they remain accountable for it. Their reporting pack changes or disappears. Escalation routes are different. Some decision rights they held are now enforced by a workflow. They must supervise work they cannot themselves perform, using a system they were not trained on, while people ask them daily whether the old way is still acceptable.

Every one of those is an impact. None of them typically appears in the register, because nobody ran a role impact assessment on the manager role.

That single omission explains most of what follows. You cannot brief your way out of an unassessed role change.

They will make sense of it with or without you

There is a strong piece of research here that changes how you think about the briefing question.

Julia Balogun and Gerry Johnson’s longitudinal study of organizational restructuring and middle manager sensemaking, in the Academy of Management Journal, followed managers through an imposed restructure and found that their understanding of the change was constructed largely through lateral, informal interaction with each other — peer conversations, often in the absence of senior management — and that change outcomes emerged from that socially negotiated process rather than from the official communication.

The practical implication is uncomfortable and useful. Managers will arrive at an interpretation of your change regardless of what you send them. They will do it sideways, with each other, in corridors and message threads, filling gaps with inference and previous experience. The only question is whether anything you provided is in the room while that happens.

Two things follow:

Most programmes do the opposite: broadcast to managers individually and never put them in a room together.

What managers actually need

Five things, in rough order of how often they are missing.

1. Information before their team has it

Even a few hours is enough. The failure mode is specific: a manager learns something material at the same all-staff session as their team, is asked about it immediately afterwards, and cannot answer.

That moment does real damage. It signals to the team that their manager is not close to the decision, which quietly removes the authority you are about to depend on for reinforcement. Sequencing the briefing is close to free and is skipped constantly.

2. Answers to the questions they will actually be asked

Cascade packs are built around the business case. Managers are not asked about the business case.

Prosci’s benchmarking on preferred senders is consistent on this split: employees want the business reasons for change from senior leaders, and the personal impact from their immediate supervisor — how this affects my role, what it means for me. The manager is the preferred sender for exactly the questions the pack does not answer.

So equip them for those: what changes for each role on their team, what happens to workload during the transition, whether anyone’s job is at risk, what happens if someone cannot cope in week one, and where the old way is still acceptable and for how long. Include the answers that are unwelcome. A manager who can say “yes, this will be slower for about six weeks” keeps credibility; one who repeats an optimistic line does not.

3. Enough capability in the change itself

Managers are routinely assumed competent in the new system and routinely are not. Many have not performed the operational task for years, and the new process is often materially different from the one they last did.

They do not need full end-user proficiency. They need enough to judge whether someone is struggling, to recognise a genuine defect from an unfamiliarity, and to avoid being visibly less capable than their team — which is its own disincentive to engage with the system at all.

This matters beyond the manager’s own confidence. Baldwin and Ford’s foundational review of transfer of training identifies the work environment — specifically supervisory support and the opportunity to apply what was learned — as one of three determinants of whether training transfers to the job at all. The manager is not an add-on to your training investment. They are a condition of it working.

4. Time

The most consequential and least discussed. Reinforcement is real work: observing, coaching, running exception conversations, chasing blockers, attending the peer forum.

It is almost never funded. Managers are asked to add it on top of an unchanged operational load, during the period when their team’s output is temporarily worse, which is precisely when they have least slack. Faced with that, most rationally protect the day job — and the programme records it as weak commitment.

Put a number on it. Two to four hours a week during hypercare, agreed with whoever owns their operational targets, is a real conversation. “Support your team through the change” is not.

5. Authority and permission

Specifically: permission to reprioritise their team’s work during the transition, a direct escalation route that bypasses the ticket queue for genuine blockers, and explicit permission to say publicly that something is broken.

Most managers will not say “this part does not work yet and here is what is being done” unless told they may. Without that permission they either defend a system they know is failing, which costs them credibility, or go quiet, which costs you the signal.

The role-conflict problem

Underneath all five sits a well-documented organisational condition.

Rizzo, House and Lirtzman’s work on role conflict and ambiguity in complex organizations, in Administrative Science Quarterly, distinguishes two states with known dysfunctional consequences. Role ambiguity is the absence of clear information about what is expected of a position. Role conflict is receiving incompatible demands from different parts of the organisation.

A line manager at go-live has both, by design. Ambiguity, because “support the change” is not a specification. Conflict, because operations wants unchanged throughput while the programme wants time spent on reinforcement, and nobody has reconciled the two.

Both are fixable with writing and a conversation. Write the manager role down — what they do, how often, for how long, and what they are accountable for. Then have the programme and the operational line agree the trade-off explicitly, rather than leaving each manager to resolve a contradiction on their own every week.

Manager readiness Counting on managers who were briefed last? Book a 20-minute scoping call to assess manager readiness as its own role — capability, time, authority and what they will be asked.
Book a 20-minute scoping call

Measure manager readiness separately

Managers are usually a small population inside a much larger survey, so their scores average away into the general result. Report them as their own segment, and ask questions specific to the role rather than the generic readiness set.

What they needHow you know they have it
Information ahead of their teamManager briefing precedes each all-staff communication — check the calendar, not the intent
Answers to personal-impact questionsCan name what changes for each role on their team, unprompted
Capability in the changeCan complete a core task unaided, or explain where they would get stuck
TimeAn agreed number of hours per week, known to whoever owns their targets
AuthorityCan name their escalation route and has used it at least once
Role clarityCan state what they are accountable for during hypercare
Peer forumAttends, and the programme hears what was raised

The third row is worth observing rather than asking about, for the same reason self-reported confidence is a weak proxy for capability anywhere else — the gap that UAT observation exists to expose. Managers have more incentive than most to overstate their readiness.

Three things to stop doing

The test

Pick one line manager a fortnight before go-live and ask three questions. What changes for each person on your team? What will you do differently in your Monday meeting? How many hours a week have you been given for this?

If the answers are vague, the problem is not that manager. It is that nobody defined the role, assessed the impact on it, or funded it — and no amount of asking for stronger reinforcement afterwards will retrofit any of those.

Manager readiness is not a communication task. It is a role that has to be specified, resourced and measured like any other.

For why this layer determines adoption in the first place, see the manager as adoption multiplier; for the practical instruments managers use once equipped, the manager toolkit for ERP and AI adoption. Where local credibility needs to extend beyond the management line, a change champion network supplements manager reinforcement without replacing it.

Capability is only part of it — training is not adoption explains why exposure and proficiency come apart — and how to measure whether managers are ready to reinforce covers how to measure the result without relying on self-assessment.

Ritvars Mētra

Ritvars Mētra

Founder of ReadinessCompass

Ritvars Mētra is the founder of ReadinessCompass, where he develops practical tools for understanding and managing organisational change complexity. His work focuses on adoption readiness, stakeholder analysis, and evidence-based change management for large-scale software and AI implementations.

View full profile →