By Ritvars Mētra, Founder of ReadinessCompassThe programme trained 1,400 people and closed. Fourteen months later, ordinary turnover means several hundred of the people doing those jobs were not trained by anybody, because the training function was disbanded, the environment was decommissioned and the super users have moved on.
New joiners learn the system the only way available: by sitting next to whoever has time. And that is where the real damage happens, because sitting next to someone does not transmit the process. It transmits what that person actually does.
Workarounds become hereditary
Markus and Tanis observed that operational staff adopt workarounds to cope with early problems and then fail to abandon them once the problems are resolved. Informal onboarding takes that and makes it permanent.
A colleague showing a new starter how to raise an order will demonstrate the version they use, including the spreadsheet they keep alongside it and the field they skip because it was broken in week three of hypercare. The new joiner has no way to know which parts are the design and which are the scar tissue. Two years and three cohorts later, nobody in the team can tell either.
This is the mechanism by which a well-implemented process quietly diverges from itself, and it is invisible in every metric a programme leaves behind. The system reports transactions completing normally.
Why the gap exists
It is an ownership problem rather than an oversight. Nobody decided not to onboard people; the responsibility simply had nowhere to land.
| Who might own it | Why it does not land there |
|---|---|
| The programme | Closed. Budget released, team redeployed |
| Central HR onboarding | Covers policies and payroll, not role-specific system tasks |
| The learning function | Has the capability but was never funded for this system, and the content is programme-owned |
| IT service management | Owns incidents and access, not capability |
| The line manager | Owns it by default, with no materials, no environment and no time |
The last row is where it always ends up, which is why the answer is a colleague and a spare afternoon.
Decide it before the programme closes
This has to be settled while the programme still exists, because afterwards there is no one with the authority or the material to settle it. Five decisions, none expensive:
- Name the owner. A function, and a person in it, accountable for role-specific capability in this process from the closure date. Write it in the closure report.
- Keep a practice environment. The single most consequential item, and the one most often decommissioned to save licence cost. Without somewhere to try things, onboarding is watching.
- Hand over the materials in an editable form, with the role-and-task matrix. Materials that cannot be updated are abandoned at the first configuration change.
- Fund a refresh cadence. Someone has to update the content when the system changes, or it becomes actively misleading within a year.
- Keep two trained people per team whose role includes onboarding, and replace them deliberately as they move on — the succession problem a super user network has to solve anyway.
Make the informal route better rather than banning it
Learning from a colleague is not the problem. It is how most workplace capability is acquired, and the research on peer influence supports it: Homburg, Wieseke and Kühnl found that observing colleagues and superiors use a system strengthens adoption.
The problem is an unguided informal route with nothing to check against. Two cheap correctives:
Give the colleague a one-page checklist of the tasks a new joiner must be able to do unaided, so the handover has a defined end point rather than stopping when the shadowing feels finished. And schedule a short check at four weeks with someone outside the team — asking a new starter to complete three core tasks unaided catches inherited workarounds while they are still one person’s habit rather than the team’s method.
That check is also the only routine mechanism most organisations will ever have for detecting process drift, which makes it worth more than the twenty minutes it costs.
More on what has to survive a programme in the Adoption Risk Hub, or read how to tell whether a transformation is genuinely embedded.