By Ritvars Mētra, Founder of ReadinessCompassLeaders don’t usually wake up wanting a “readiness update.”
They want to know whether the launch will hold. Whether the business can absorb the next release. Whether the new system will be used properly. Whether managers are aligned. Whether the planned benefits are still believable. Whether something ugly is hiding under the green status.
That’s readiness.
Why leaders do not need change jargon
The mistake change teams often make is that they present readiness in change language rather than business language. They talk about stakeholder engagement, resistance management, change impacts, sponsor alignment, adoption journeys, awareness, desire, reinforcement, personas, champions, sentiment, heat maps. None of these terms are wrong. Some are very useful. But in an executive briefing, they can become a fog machine.
Senior leaders hear the vocabulary and mentally file it under “people-side update.” Important, perhaps, but not urgent in the same way as budget, scope, technical defects, regulatory risk, customer impact, or go-live readiness. That’s a problem because organisational readiness is not separate from those things. It is often the condition that determines whether those things turn into business results.
So the first rule is simple: don’t brief readiness as change management. Brief it as risk to execution.
A good readiness briefing should show leaders:
- what is ready,
- what is not ready,
- where adoption risk may affect business outcomes,
- what decision or support is needed,
- what will be checked next.
Brief readiness as execution risk
A weak readiness briefing says, “Stakeholder engagement is amber.” A stronger briefing says, “The sales managers in Germany and Italy are not yet using the new pipeline rules in weekly reviews. If this continues, CRM data quality will not be reliable enough for the September forecast.”
Same issue. Entirely different conversation. The second version has a business consequence, a location, a behaviour, a time horizon, and a decision implication. It does not ask leaders to care about “engagement.” It shows them why low engagement may damage forecast accuracy. Suddenly readiness is not soft. It is operational.
This matters especially in software, ERP, CRM, AI, shared service, and operating model transformations. Leaders may believe the hard part is design and delivery: build the tool, configure the workflow, migrate the data, approve the operating model, hit the launch date. Readiness exposes the inconvenient truth that delivery is not the same as use. A system can be live and still not be adopted. A process can be documented and still not be followed. An AI tool can be available and still not be trusted. A new governance model can be approved and still not shape decisions.
Readiness is the distance between “we built it” and “the organisation can actually work this way.” That sentence usually lands better than a slide titled “Change Readiness Assessment.”
Translate readiness signals into business consequences
Executives also need brevity, but not simplification to the point of uselessness. There’s a difference. A good readiness briefing should feel like a cockpit view, not a weather report written by committee. It should show where the initiative can fly, where the turbulence is manageable, and where someone is pretending the engine noise is normal.
Avoid the temptation to show every data point. The readiness survey, stakeholder interviews, manager feedback, training completion, support-ticket themes, workshop notes, adoption metrics, sentiment comments, business readiness checklists—these are inputs. Leaders don’t need all of them. They need the judgement that comes from them.
The trick is to translate each readiness dimension into executive language. “Awareness” becomes “Do people know what is changing and when?” “Desire” becomes “Do affected groups see a reason to cooperate, or are they complying on the surface?” “Knowledge” becomes “Do they know how the new process works?” “Ability” becomes “Can they perform it under real working conditions?” “Reinforcement” becomes “Will managers, metrics, and governance make the new way stick?”
The five questions every readiness briefing should answer
The briefing should answer five plain questions:
Are people clear on what will change? Are managers ready to lead it locally? Can users perform the new work? Is the business creating enough time and attention for the transition? What decisions or trade-offs are needed now?
No jargon needed. None.
That last question—reinforcement—is often where the whole thing cracks. A business can train people beautifully and then reward the old behaviour. It can announce a new standard process and then tolerate exceptions from powerful regions. It can ask employees to use a new reporting dashboard while executives keep requesting the old spreadsheet. It can say AI adoption matters but provide no clear rules on risk, review, or accountability. In each case, the readiness issue is not employee attitude. It is leadership inconsistency.
You can brief that without sounding accusatory. Try: “The main readiness gap is not user training. It is reinforcement. Teams are receiving mixed signals because local managers are still accepting the old process. We need a leadership decision on whether the new process becomes mandatory from go-live or whether exceptions remain allowed during transition.” That is a useful sentence. It gives leaders something to decide.
Business consequence
Decision needed
Action owner
Next evidence check
Example: executive readiness briefings work best when each signal is translated into a consequence and a decision.
How to turn readiness gaps into leadership decisions
Readiness briefings fail when they only describe conditions. They work when they convert conditions into choices.
There is a subtle art here. Leaders do not need to be entertained with change theory. They need to be confronted with reality in a form they can act on. Not aggressively, not theatrically. Just clearly.
Instead of saying, “There is resistance in Operations,” say, “Operations is concerned that the new workflow adds four approval steps during peak demand. Unless this is resolved, they are likely to keep using the offline workaround.” Instead of saying, “Managers need more enablement,” say, “Line managers cannot yet answer the three questions employees are asking most: what changes in my role, what happens to current exceptions, and how performance will be measured after go-live.” Instead of saying, “Stakeholder alignment is low,” say, “Finance and Sales are giving different answers on who owns customer master data. This is now blocking training content and will create conflicting instructions for users.”
The pattern is simple. Harvard Business Review has documented that effective leaders communicate in specifics rather than abstractions — a principle that applies directly to readiness briefings. Name the business area, name the behaviour or gap, name the consequence, name the decision. Here is how to brief readiness without jargon in five steps:
- Name the business area — which function, region, or team is affected.
- Describe the behaviour or readiness gap — what is happening now versus what needs to happen.
- Explain the consequence — what business outcome is at risk.
- Ask for a decision or action — what do leaders need to do differently.
- Define the next evidence check — how will you know if the action worked.
Use evidence without overwhelming the room
This is also how you avoid the fake comfort of red-amber-green reporting. RAG status has its place, but it can become corporate camouflage. “Amber” means everything and nothing. Leaders have seen too many amber statuses that were actually red with better manners.
If you use colours, pair them with evidence. Not “Manager readiness: amber.” Say, “Manager readiness: amber because only 42% of managers in impacted teams have completed scenario practice, and interview feedback shows they are not confident explaining role changes.” Better still, add the consequence: “This increases the risk of inconsistent local guidance during the first two weeks after go-live.” Now amber has teeth.
Data helps, but don’t worship it. Readiness is partly measurable and partly interpretive. Survey scores can show confidence. Training records can show completion. System simulations can show task performance. Adoption metrics can show usage. Support-ticket patterns can show confusion. Interview themes can show trust issues. None of these alone tells the full story.
A readiness briefing should combine evidence with judgement. Leaders usually respect this when it is done plainly. Say, “The data is mixed. Training completion looks strong, but practice results show users are still making errors in exception handling. Our judgement is that go-live can proceed only if floor support is increased for the first ten business days.” That’s much better than hiding uncertainty. Executives can handle uncertainty when it is structured. What they cannot use is vague reassurance.
The best readiness briefings are also selective about bad news. Not every concern deserves steering attention. Some issues belong with the project team. Some belong with workstream leads. Some belong with line managers. Leadership attention is scarce; spend it on the gaps that require authority, prioritisation, trade-offs, or visible sponsorship. A useful filter is: can the project team solve this alone? If yes, don’t drag leaders into the weeds. If no, brief it clearly.
Common mistakes in executive readiness briefings
There’s another thing: avoid moral language. Don’t say people are “resistant” unless you can explain what that means. The word can make leaders impatient. It can also make employees sound like the problem before the programme has earned that conclusion.
Use sharper descriptions. “Users are concerned the new process will increase customer response time.” “Managers are not confident explaining why local reports are being retired.” “Super users are supportive, but they do not have protected time to support colleagues.” “Employees understand the tool, but they do not believe leadership will stop accepting old ways of working.” These statements are harder to dismiss because they are specific. They also shift the conversation from attitude to conditions. Conditions can be changed.
This approach aligns with what McKinsey calls the “people power of transformations”—the idea that leadership communication must connect directly to operational decisions. Similarly, PMI research shows that executive communication about project readiness is most effective when it focuses on actionable risk rather than status updates.
Research from MIT Sloan Management Review reinforces that leaders in transformation settings need evidence they can act on, not data that merely describes. And Gartner has observed that change-ready organisations build readiness communication into leadership governance, not just project reporting.
A simple readiness briefing structure
A good leader briefing on readiness should probably fit on one page, or one slide if your organisation still worships slides. The structure can be very plain: what is ready, what is not ready, what happens if we do nothing, what decision or support is needed, what will be checked next.
That’s enough. The supporting detail can sit behind it, ready if challenged. And it will be challenged. It should be. Readiness is judgement under uncertainty, not scripture.
The tone matters too. Don’t sound like a change manager pleading for attention. Sound like someone protecting the business outcome. Because that is what you are doing.
“We are not ready” can sound dramatic. Sometimes it is necessary, but use it carefully. More often, the better phrase is, “We can proceed, but not safely under the current assumptions.” Or, “Go-live is technically possible, but adoption risk is high unless these three actions happen first.” Or, “The business is ready to start, but not ready to sustain without manager reinforcement.” This avoids the silly binary of ready/not ready. Most transformations are partially ready. Some areas are fine. Others are fragile. A mature briefing shows the pattern.
It’s also worth separating launch readiness from adoption readiness. Leaders often ask, “Are we ready for go-live?” The better question is, “Are we ready for people to work differently after go-live?” A system can launch on Friday and fail socially by Wednesday. The launch is an event. Adoption is a sequence of repeated choices under pressure. Brief that.
For AI implementation, the distinction is even more important. Leaders may ask whether the tool is deployed, whether licenses are assigned, whether guidelines are published. Readiness asks whether people know where AI is appropriate, whether managers encourage experimentation, whether review standards are clear, whether risk teams are aligned, whether employees trust the organisation’s intent, and whether use cases are connected to real work rather than demo theatre. Just say, “The tool is available, but the organisation is not yet ready to rely on it in core workflows.” That sentence will get attention.
In the end, briefing readiness without change jargon is not about dumbing the work down. It is about respecting the decision context. Leaders need to know whether the transformation can deliver, where adoption may break, and what they must do about it. They don’t need a tour of the method.
Use business words. Say “people can’t yet perform the new process” instead of “ability gap.” Say “managers are giving mixed messages” instead of “sponsor cascade risk.” Say “the old workaround is still faster” instead of “reinforcement challenge.” Say “benefits are at risk because behaviour has not changed” instead of “low adoption maturity.”
The work behind the words can still be rigorous. Actually, it must be. The cleaner the briefing, the stronger the analysis behind it needs to be. Leaders don’t need less truth. They need it translated into consequences, choices, and action.