By Ritvars Mētra, Founder of ReadinessCompassEvery complex transformation has a small group of people who carry an invisible workload. They are not sponsors. They are not project managers. They are the experts: the process owners, super users, business analysts, key operators, and senior practitioners who know how the work actually gets done. When a new system, AI tool, operating model, or process is introduced, these experts become translators, trainers, testers, defect reviewers, data cleaners, user supporters, and emotional shock absorbers—often simultaneously, often without protected time, and often without anyone formally acknowledging the cost.
This is expert overload. It is one of the most reliably destructive patterns in large-scale change, and it is almost invisible from a steering deck.
Why expert overload is a predictable adoption risk
Expert overload matters because the people who are most essential to adoption are also the people most likely to burn out before go-live. They carry the cognitive load of understanding both the old process and the new one. They are the default answer for everyone’s questions. They sit in every workshop because “we need someone who knows.” They are pulled into testing, cutover preparation, data migration, and hypercare planning.
When these experts become exhausted, disengaged, or resentful, the programme loses its critical adoption infrastructure. The new process may be technically correct, but the local capability to make it work has been quietly eroded.
Expert overload impacts transformation success by:
- removing the people best positioned to model and reinforce new behaviours,
- creating hidden delay—decisions, testing, and issue resolution slow down as expert capacity shrinks,
- increasing the risk that critical local knowledge is lost when overwhelmed experts leave or disengage,
- delaying adoption because frontline users have no one local to turn to for help,
- undermining readiness confidence because expert feedback becomes negative or absent.
How to recognise expert overload before go-live
Expert overload does not announce itself loudly. It appears in small signals that accumulate. The same three people are in every meeting. Testing feedback is superficial because no one has time to think deeply. Questions from frontline users go unanswered for days. Key decisions are delayed because the expert has been pulled into another workstream. The expert starts saying things like “I haven’t had time to look at that properly” or “We’ll figure it out during hypercare.”
The most dangerous signal is silence. When a normally vocal expert becomes quiet, it often means they are too overloaded to engage properly, or they have decided the programme is not worth the personal cost and are protecting themselves. Neither is good for adoption.
How to protect critical experts during transformation
Protecting experts is not about being kind. It is about protecting the programme’s ability to land the change. Experts need protected time, clear prioritisation, and visible recognition of their contribution. They need someone to manage their workload actively, not just thank them for their effort. They need to know which meetings they can skip and which decisions require their input.
Programmes that manage expert capacity well do several things differently. They identify the critical experts early and map their current workload. They negotiate time with line managers rather than assuming goodwill. They sequence work so experts are not needed everywhere simultaneously. They bring in temporary support for routine activities. They make expert workload visible to sponsors so that capacity decisions are made consciously rather than by default.
According to McKinsey, transformation programmes that actively manage key-person capacity are significantly more likely to sustain adoption after go-live. Harvard Business Review has documented how change resistance often originates from overload and uncertainty rather than active opposition. Gartner research shows that role overload is one of the most common but least recognised barriers to change adoption.
Workload mapping
Protected capacity
Knowledge retention
Sustainable adoption
Example: protecting critical experts from overload preserves the local knowledge and capacity needed for sustainable adoption.
How to build expert capacity into programme planning
Expert capacity planning should be a governance topic, not a side conversation. It requires several deliberate steps: identify the experts who are critical to adoption, not just those who are most visible. Map their current workload before adding programme demands. Agree protected time with their line managers and sponsors, not just the experts themselves. Monitor expert engagement and workload during the programme, looking for early signals of overload. Have a plan for what happens if a critical expert leaves, becomes ill, or burns out.
Programmes that do not do this often discover the cost too late. The expert who resigns two months before go-live takes years of local knowledge with them. The expert who is physically present but cognitively absent makes decisions on autopilot. The expert who resents the programme but cannot say so becomes a quiet source of local resistance.
Common mistakes in managing expert workload
The most common mistake is assuming goodwill is infinite. Experts often want to help, but goodwill depletes when it is not reciprocated with practical support. A second mistake is treating all experts as interchangeable. Different experts carry different knowledge, different influence, and different emotional investment in the change. A third mistake is failing to distinguish between adding value and being present. Many experts are invited to meetings where their presence is appreciated but not essential. A fourth mistake is rewarding expert contribution with more work rather than recognition, career development, or genuine appreciation.
A practical expert readiness checklist
Before go-live, ask: Do we know who the critical experts are for each core process? Have we mapped their current workload? Have we agreed protected time with their managers? Are we monitoring expert engagement? Do we have a plan if a critical expert becomes unavailable? Are we giving experts the information they need to answer frontline questions effectively? A programme that cannot answer these questions confidently is relying on heroism rather than planning—and heroism does not scale.
The hidden cost of expert overload is not paid by the programme budget. It is paid by adoption. When the people who should be leading the change locally are too exhausted to lead, the new system may go live technically, but the organisation will not be ready to use it. Protecting experts is not soft. It is some of the hardest, most practical work in transformation.