The Adoption Playbook

There is a specific heartbreak in operational software: the build worked, the demo landed, and three months later the team is back in the old spreadsheet. Post-mortems call it a change-management problem, which is a way of saying nobody designed the adoption.

Adoption is designable. It has a sequence, known failure modes, and measurable checkpoints — the same as the software itself. This manual is the protocol.

01The physics of tool trust

• ▸Trust transfers from people, not demos. A team adopts what their most respected operator uses. Identify that person early — they're usually the skeptic — and invest accordingly. One convinced veteran outperforms any launch memo.
• ▸New tools are judged by their worst output. The incumbent process gets judged on its average; the newcomer gets judged on its most memorable failure. Plan for this: early exposure should be in draft mode, where a bad output is a shrug, not a story.
• ▸Habits beat mandates. A mandate produces compliance for exactly as long as someone checks. A habit forms when the new path is genuinely the path of least resistance — which is a design requirement, not a communications one.
• ▸Silence is data. Teams rarely announce they've stopped using a tool. Usage decays quietly. If you're not watching the volume number weekly, you'll learn about abandonment at renewal time.

02The rollout sequence

The order matters more than the calendar. Compress or stretch the timeline, but do not skip steps:

• ▸1. Co-design with the skeptic. Before the build finishes, the toughest operator has reviewed the outputs and their edge cases are in the test set. Their fingerprints make the tool credible by association.
• ▸2. Draft-mode pilot with three users. Not the whole team. Three people, chosen for influence and honesty, using the automation in draft mode on real work. Everything they send still carries their name.
• ▸3. Publish the miss log. A visible running list: what the automation got wrong, what changed because of it. This single artifact converts skeptics faster than accuracy stats — it proves someone is watching.
• ▸4. Open to the team on evidence. The pilot trio presents their own numbers — time saved, edits made, misses caught. Peer evidence lands where vendor claims bounce.
• ▸5. Graduate by vote. Automation levels rise (draft → queue → auto, per DSP-03's trust ladder) when the reviewers say so. The team that promotes its own tool defends its own tool.

03The jobs conversation, scripted

Every rollout has a moment where someone asks — usually not out loud — "is this thing here to replace me?" Unanswered, that question becomes resistance with perfect camouflage: edge cases multiply, reviews slow, enthusiasm evaporates.

The script is honesty with specifics. If the hours are being reinvested, name where: "the four hours a week this returns go to the backlog reviews we keep skipping." If roles will change shape, say how and when. And if leadership hasn't decided, the rollout isn't ready — deciding what freed hours are for is a launch prerequisite, not an HR detail.

04Measuring adoption honestly

Adoption has leading and lagging indicators, and the leading ones are cheap to watch weekly: share of eligible work flowing through the new path (the volume truth serum), median edit distance on drafts (falling = trust rising), review latency (a queue nobody opens is a tool nobody trusts), and unprompted mentions — the first time someone references the tool in a meeting you didn't organize, adoption has started.

The lagging indicator is the one that matters at renewal: would the team fight to keep it? Ask directly at day 60. If the answer is a shrug, treat it as an incident — something in the sequence got skipped, and it's cheaper to rerun it now than to relaunch later.