By Ritvars Mētra, Founder of ReadinessCompassThe communication plan is complete. Town halls delivered, cascade packs issued, intranet updated, 94% reach reported. The comms workstream is green.
And the finance team in Spain still does not know what to do with consignment stock, because the new process does not describe their case and nobody can tell them whether the local variation is still allowed.
So they invent something. By month two it is standard practice, and it is wrong.
Reach was never the constraint. The constraint was that a specific question needed a specific answer from somebody with the authority to give it, and no communication channel can supply that.
The cascade assumes meaning travels
A cascade is a transmission model drawn as an org chart. Put the message in at the top, it passes down the layers, and it arrives at the bottom intact.
The linguist Michael Reddy named the assumption underneath that. The conduit metaphor is the idea, built into how we talk about talking, that language is a pipe through which meaning is transferred — that we “put ideas into words” and others “get the message across.” His point was that this is a fossilised metaphor rather than a description of what happens. Meaning is not transferred; it is reconstructed by each listener out of what they already know.
That is not a semantic quibble when the listeners have materially different context. A cascade sends one message to a warehouse supervisor in Rotterdam, a credit controller in São Paulo and a shared-service clerk in Kraków, each of whom reconstructs it against a different process, different exceptions and different local history.
Which is why a cascade can achieve near-perfect reach and almost no resolution. Everyone received it. Nobody’s actual question was answered.
The questions that block adoption are not message-shaped
Communication is genuinely good at the questions it is designed for — why are we doing this, what is changing broadly, when. Those matter, and senior leaders are the right senders for them.
But the questions that actually stall adoption look like this:
- The new process has no path for a partial delivery against a blanket order. What do we do until it does?
- Our regulator requires a second signature the workflow does not support. Do we stay compliant or follow the process?
- The master data standard says one thing and our customer contracts say another. Which wins?
- Is the local spreadsheet still allowed for month-end, and until when?
None of those is a communication gap. Each is a decision that somebody has to take and own. Broadcasting more clearly does not resolve any of them, and the team asking will not wait indefinitely — they will decide locally and move on, which is precisely how spreadsheets end up running processes the new system was supposed to own.
Which makes it a decision-rights problem
Paul Rogers and Marcia Blenko’s work on clear decision roles in Harvard Business Review argues that organisations stall wherever there is ambiguity or tension over who gets to decide what, and identifies four recurring bottlenecks. The first is global versus local.
Anyone who has run a multi-country ERP programme will recognise that as the template-versus-local-variation argument, and it is usually left unresolved at role level. There is a global design authority. There are local users. In between, frequently, there is nobody with a named right to decide whether a specific local case is an exception, a defect or a misunderstanding.
So the question travels upward, joins a queue, and takes three weeks. Decision latency, not message reach, is the binding constraint on adoption in the weeks around go-live. A team that gets an answer in a day adopts. A team that waits three weeks builds a workaround, and the workaround outlives the answer.
What a process owner actually is
Worth being precise, because the term gets used loosely for anyone who knows a process well.
In Michael Hammer’s process and enterprise maturity model, published in Harvard Business Review, owner is one of five process enablers alongside design, performers, infrastructure and metrics — defined as the person accountable for the process and its performance end to end, not merely someone who participates in it.
That accountability is what a subject-matter expert does not have. An SME can explain how the process works. A process owner can change it, or rule that a case is out of scope, or say that a local variation is permitted until March. Adoption questions need the second kind of person.
Most large programmes have global process owners. Far fewer have named local process owners — someone accountable for the process as it runs in a particular site, country or entity, with delegated authority inside an agreed boundary.
Why the local one matters most
Because the global design is, necessarily, work-as-imagined.
Erik Hollnagel’s distinction between work-as-imagined and work-as-done holds that formal descriptions omit the adjustments that make work function under real conditions. A global template is the clearest possible example: it is an idealised account of a process that will meet twelve countries’ realities, and the divergences are not defects in the countries.
The local process owner is the person who sits exactly where the template meets reality and can settle what happens there. Their job at go-live is a specific one:
- Decide, inside a boundary. This case follows the template. That one is a permitted exception until the design is fixed. This third one is people not yet knowing the process.
- Escalate genuine design gaps to the global owner, with evidence, rather than absorbing them locally and quietly.
- Close temporary permissions. An exception granted with no end date is how a workaround becomes permanent infrastructure.
That third one is the most frequently skipped and the most expensive.
Cascade or process owner: which answers what
| Question | Answered by | Why |
|---|---|---|
| Why are we doing this? | Senior leader, via cascade | Organisational rationale; preferred sender is the top of the house |
| What does this mean for my role? | Line manager | Personal impact; preferred sender is the immediate supervisor |
| How do I do this task? | Training, job aid, super-user | A capability question with a documented answer |
| What do we do about this case? | Local process owner | A decision, not a message. Needs authority, not clarity |
| Is the old way still allowed? | Local process owner | Requires someone able to grant and withdraw permission |
| Is this a defect or are we doing it wrong? | Local process owner, escalating if needed | Requires process authority to classify |
The bottom three rows are where adoption is won or lost, and they are the three that no communication plan covers. This is also the distinction from the manager and champion layers: managers reinforce behaviour and champions carry credibility, but neither can rule on the process. Reinforcement without a decision route just produces a manager repeatedly telling a team to follow a process that does not fit their case.
How to tell whether you have this gap
Three checks, none of which requires a survey.
- Name the owner. Pick a process and a site and ask who decides whether a local variation is permitted. If it takes more than a few seconds, or two people give different names, the role does not functionally exist.
- Measure decision latency. Take the last ten “how do we handle X” questions and find how long each took to get a binding answer. Anything past a week is generating workarounds while it waits.
- Look at where workarounds cluster. They concentrate where questions went unanswered, which is a map of your missing decision rights — and the same signal a well-run impact register should already be capturing.
What to put in place
Four things, none of them expensive.
A named local owner per process per site. Publish the map so anyone can find who to ask in ten seconds. Most of the value is in the map existing at all.
A stated authority boundary. What they can decide alone, what needs the global owner, and what needs neither because it is already documented. Without the boundary they either over-reach and fragment the template, or escalate everything and become a queue.
A decision service level. Something like: binding answer within two working days during hypercare, or an explicit temporary permission with an end date. The end date is the important half.
Open questions on the readiness reporting. Count of unresolved process questions, and how long the oldest has been waiting. It is a better leading indicator of adoption trouble than most survey items, because it measures a queue rather than a feeling — and unlike sentiment, somebody can clear it.
The reframe
None of this argues against communication. Cascades do real work, and a programme without one has a different and equally serious problem.
The argument is that communication and process ownership solve different failures, and organisations reliably over-invest in the first because it is easier to plan, easier to measure and entirely within the change team’s control. Naming local process owners with real authority requires somebody senior to give something up, which is why it is so often left undone.
When adoption stalls and the comms plan is green, the next question is not how to communicate better. It is: who is currently allowed to answer the question this team is stuck on, and how long are they taking?
For the layer that reinforces the behaviour once the decision exists, see what line managers need before go-live; for finding where the template meets reality in the first place, role impact assessment. Unresolved decisions that cannot be settled before cutover belong in the transformation RAID log with a named owner and a date.