By Ritvars Mētra, Founder of ReadinessCompassA year after go-live, somebody asks whether the change has really stuck.
The usual answer is a shrug backed by a usage figure. People are in the system, the numbers look acceptable, nothing has blown up. That is offered as evidence of embeddedness because no one has a test for it — “embedded” is used as a feeling rather than a claim about the organisation.
It does have a definition, and it comes with three things you can actually check.
Embedded means persistence without the props
Lynne Zucker’s work on institutionalization and cultural persistence, in the American Sociological Review, defines a highly institutionalised act as one that is objective — repeatable by another person without the meaning changing — and exterior, existing as part of external reality rather than as one individual’s way of doing things.
Her experiments measured three aspects of persistence, and they translate directly into tests a programme can run: generational uniformity (do new members do it the same way?), maintenance (does it persist without active effort?), and resistance to change (does it hold under pressure?). Greater institutionalisation produced more of all three. Zucker later developed this with Pamela Tolbert into a staged account — habitualisation, objectification, sedimentation — in which full institutionalisation is defined by survival across successive generations of organisational members.
Which gives a working definition worth adopting: a transformation is embedded when the new way of working persists after the things holding it up have been removed. The project, the champion network, the dashboard, the specific manager who cared, the original trained cohort.
High usage while all of those are still in place tells you nothing. It is the removal that constitutes the test.
Three tests you are already running
The useful part is that organisations generate these tests naturally. You do not have to design an experiment; you have to notice one happening and look at the result.
| Test | The natural experiment | What embedded looks like |
|---|---|---|
| Turnover | People who joined after go-live are now doing the work | New joiners perform it the same way, having never met the project |
| Withdrawal | The project closed; the champion moved; the dashboard stopped | The practice continues with nobody enforcing it |
| Pressure | A volume spike, a crisis, a deadline, a system outage | People stay with the new way, or return to it once the pressure passes |
The turnover test
This is the strongest of the three and the least used.
Find three people who joined after go-live and watch them do a core task. They were never trained by the programme; they learned from colleagues. What they do is not the designed process — it is whatever the team currently transmits.
If they perform it as designed, the change has been transmitted independently of the people who were trained, which is the substantive meaning of embedded. If they have inherited a workaround along with it, the change was never institutionalised; it was remembered by the original cohort, and it is now decaying at the rate of staff turnover.
That decay is invisible on a usage dashboard, because logins stay flat while what people do inside the system drifts.
The withdrawal test
Anything that requires ongoing enforcement is being held up rather than embedded. So look at what happens when the support is removed — which, conveniently, is what always happens anyway.
A useful version of this question: if the person who chases this left tomorrow, what would stop? If the answer is anything material, you have identified a dependency, not a practice. The same applies to reporting — a behaviour that persists only while it is being measured is a compliance response, and it will lapse when the measurement does, which is why what gets tracked after hypercare matters so much.
The pressure test
Under time pressure people revert to whatever is fastest and most familiar. That is not a character flaw; it is what pressure does.
So the informative moment is the bad week — the volume spike, the outage, the audit deadline, the month-end that went wrong. Did the new process hold? And if it did not, did people return to it afterwards, or did the crisis become the moment the old way was quietly reinstated?
Crises are where durable reversion begins, because an exception made under pressure comes with a ready-made justification. If nobody closes it afterwards, it stays.
The routine as described and as performed
There is a useful distinction for reading what you find. Feldman and Pentland’s reconceptualisation of organizational routines, in Administrative Science Quarterly, separates the ostensive aspect of a routine — its structure, the idea of it people refer to — from the performative aspect: the specific actions taken by specific people at specific times.
Embeddedness is the two matching without anybody checking.
The reframe worth taking from it: when the performative version has drifted and stabilised — when everyone does the same different thing — that is not a compliance failure. It is now the routine, and the documented process has become fiction. At that point the choice is to change the practice or change the documentation, and pretending the documentation still describes reality is the one option that helps nobody. This is the same distinction between the work as imagined and the work as actually done.
Embeddedness lives in artefacts, not memory
If a change exists only in the heads of the people who were trained, it has an expiry date set by staff turnover. Zucker’s criterion of exteriority — the practice existing as part of external reality rather than as an individual’s habit — has a concrete organisational form: the change is visible in artefacts that outlive individuals.
Six places to look, in rough order of how much they tell you:
- Onboarding and induction. Does a new starter learn the new way as simply “the way”, with no reference to the old one and no mention of a project?
- Job descriptions and role definitions. Do they describe the work as it is now performed?
- Performance measures. Is anyone still measured on something the new process makes impossible or irrational?
- Controls and audit. Does the control framework test the new process rather than the old one?
- System configuration. Is the desired behaviour supported by validation and workflow, or does it depend on people choosing correctly every time?
- The reporting pack. Is the old report still produced? While it exists, somebody is maintaining the old way to feed it.
The onboarding check is the single sharpest test on this page, and it takes twenty minutes. Read the induction material a new joiner receives. If it does not describe the current process, the organisation is actively teaching newcomers something other than the change you implemented — and turnover will do the rest.
Four ways it fails
- Held up by one person. Works beautifully until they change role. Common and rarely visible until it happens.
- Alive only in the original cohort. Passes every usage measure while quietly decaying through turnover.
- Enforced rather than embedded. Persists while someone reports on it, lapses within a quarter of the reporting stopping.
- Documented but not performed. The procedure says one thing, the work does another, and the gap has stabilised without anybody acknowledging it.
You cannot test this early
All three tests need time, because each depends on an event that has not happened yet at eight weeks. There has been no meaningful turnover, the support has not been withdrawn, and there may not yet have been a genuine pressure event.
Realistically the question becomes answerable somewhere between twelve and eighteen months after go-live, once a reasonable share of the population has turned over and at least one bad month has occurred. That is long after everyone has stopped looking, which is exactly why embeddedness is so rarely established rather than assumed.
Infrequent processes need longer still. Arthur and colleagues’ meta-analysis of skill decay found substantial loss over periods of nonuse, with cognitive and accuracy-based tasks decaying more than physical ones — which describes most finance and administrative work. An annual process has been performed once by the time you would otherwise declare the change embedded.
Somebody therefore has to own the question after the programme has gone. PMI’s research on sustaining benefits beyond the project makes the general case that post-project work needs the same ownership and attention as delivery; the embeddedness check is a specific, cheap instance — one review, a year on, by someone in the business.
The one-page version
A year after go-live, ask four questions and go and look rather than asking around:
- Do people who joined after go-live do it the same way as those who were trained?
- What would stop if the person who chases this left?
- What happened during the worst week, and did people come back afterwards?
- Does the induction material describe the process as it is actually performed today?
Four answers, obtainable in a morning, and considerably more informative than a usage report — because usage tells you the system is being opened, and these tell you whether the organisation has changed.
One gap undermines all of this quietly. The programme trained the population that existed at go-live, and ordinary turnover replaces a share of it within a year — so onboarding new joiners into the new process becomes a job nobody owns, and informal handover transmits workarounds rather than the design.
For what to keep tracking in the meantime, see what to measure after go-live; for the drift these tests detect, why users go back to Excel; and for what it costs when embedding fails quietly, why benefits leak after go-live.