The Anticulture of Digital Adoption — Part 2
Why Implementation Playbooks Fail and What High-Performing Organizations Do Differently
Part 1 argued that the anticulture of digital adoption is not a software problem but a human behaviour problem: five psychological dynamics (Comfort of Competence, the Continuity Trap, the Hierarchy of Adoption, Legacy Identity, and the Absent Consequence) that quietly sustain resistance to change, regardless of how capable the workforce or how well-built the software.
If that diagnosis is correct, it indicts the standard response. Most organizations still run digital rollouts through a conventional implementation playbook: scope, build, train, go-live, close, a sequence inherited from software engineering, not behavioural change. That playbook was never designed to counter the five dynamics; at best it ignores them, and at worst it actively reinforces them. This piece examines where those playbooks fail and what organizations that actually achieve adoption, not just deployment, do instead.
Where the Playbook Breaks Down
The conventional playbook is not negligent by design; it is simply answering the wrong question. It is built to deliver a working system by a deadline, not to change what people actually do once the deadline passes. Mapped against the five anticulture dynamics, the gaps are specific and recurring.
Training transfers information, not competence. Against the Comfort of Competence, playbooks schedule a handful of training sessions before go-live, treating skill as something installed once rather than rebuilt through repetition. Employees leave the session able to follow a script, not confident enough to recover when the real workflow deviates from it, so under pressure, they revert to what they already know. For instance, a finance team trained on a new ERP module in two afternoon sessions can process a textbook invoice correctly but reaches for the old Excel template the moment a vendor sends an unusual multi-currency bill.
Go-live is treated as a technical cutover, not a behavioral one. Against the Continuity Trap, the playbook assumes that flipping the switch on the new system retires the old workaround. It rarely does. The spreadsheet, the manual reconciliation step survive go-live because the idealized software logic doesn’t yet cover every edge case the old workaround quietly handled, and no one owns closing that gap. For example, a logistics firm rolling out a new route-planning tool often finds dispatchers still keeping a private group chat on WhatsApp to relay the real-time exceptions the system wasn’t built to handle.
Sponsorship is funded, not demonstrated. A regional director who still asks an assistant to print a paper copy of the new dashboard before a review meeting sends a clearer message than any town hall announcing the rollout. Against the Hierarchy of Adoption, playbooks assign an executive sponsor to unlock budget and air cover, but rarely require that sponsor to use the system themselves. The organization reads the signal correctly: leadership approved this for other people.
Data migration is scoped as IT work, not as a power transfer. Against Legacy Identity, playbooks treat opening up data visibility as a technical task: field mapping, access controls, validation rules, with no acknowledgement that for some employees, being the sole holder of certain knowledge is their leverage. Nothing in the plan replaces what democratization takes away, so resistance shows up as technical objections that are really something else. A sales operations manager who alone knows which client accounts are actually at risk may quietly delay “data cleanup” for months rather than hand that insight to a shared dashboard.
Get Excel Ukpohor’s stories in your inbox
Join Medium for free to get updates from this writer.
Success is measured at launch, not sustained. A retailer that declared its new inventory system “live” after a successful first week often finds, six months on, that half its stores have quietly gone back to the paper stock count they never fully retired. Against the Absent Consequence, the playbook’s success metric is almost always “go-live achieved,” and the project formally closes soon after. Usage is rarely tracked past that point, and reverting to old habits carries no real cost, so adoption follows a predictable curve: a spike at launch, driven by novelty and oversight, followed by a slow decay back toward the old way of working.
What High-Performing Organizations Do Differently
Organizations that convert software investment into genuine adoption don’t run a better version of the same playbook; they run a different kind of program, one built around the five dynamics rather than blind to them.
They build competence through repetition in a safe environment, not a single training event. Sandbox environments, paired “super user” mentors, and an explicit permission to make mistakes without penalty replace the one-off session. Confidence is treated as something earned over weeks of low-stakes practice, not transferred in an afternoon. One manufacturer rolling out a new production-management system ran a four-week practice line in parallel with the real one, letting operators break things safely before they ever touched live output.
They co-design the workflow with the people who do the work, before go-live. Rather than imposing an idealized process and patching resistance afterward, high performers pressure-test the digital solutions against real edge cases with frontline staff during design, closing the gap that would otherwise keep the old workaround alive. A hospital implementing a new patient-records system that embeds nurses in the configuration sprints tends to surface the awkward night-shift handover case in week three of design, not six months after launch when it finally causes an incident.
Leadership visibly uses the system first. A CEO who opens the new reporting tool live on screen during a quarterly review, typos and all, does more for adoption than any mandate memo. Executives review live dashboards in their own meetings, enter their own data, surface their own errors in front of the team. Adoption is modeled downward from the top, not delegated downward while leadership quietly keeps the old habits for itself.
They redesign incentives alongside the technical rollout, not after it. Where data democratization threatens someone’s informal leverage, high performers identify that person early and give them a new, visible role, such as data steward, product owner, or go-to expert, so the rollout replaces what it takes away instead of simply removing it. The sales operations manager who once gatekept client risk data becomes the named owner of the new risk dashboard, with their name on it in every leadership meeting.
They build real consequences and sustain reinforcement well past go-live. Usage metrics, not go-live status, become the success measure, often tied into performance reviews and tracked publicly on a dashboard. A defined hypercare period, typically three to six months, keeps a team actively auditing adoption and intervening before the usual post-launch decay sets in.
The Real Deliverable
The conventional playbook was built to ship software. It was never built to change behaviour, and the two are not the same deliverable, which is precisely why so many technically successful rollouts fail to move a single operational metric. The organizations that get this right don’t treat adoption as a by-product of good software; they treat it as the actual project, with the technology as one input among several.
The return on a digital investment is not released at go-live. It is released only when the five dynamics identified in Part 1 have each been deliberately designed for: competence rebuilt through practice, workflows closed against real workarounds, leadership visibly leading, legacy power redistributed rather than erased, and consequences sustained long after the launch slide deck has been archived.
Thanks for staying with in through these two parts. Please share your experience in the comment section below.
