Illustrative. This lesson continues the composite engagement from Discovery, Scoping, and ROI & Risk: the logistics company, the veteran dispatcher. The dialogue is invented to teach the move and contains no statistics.
First, an account of the weeks between the VP's sign-off and the first flag, because the calendar filled with work no demo will ever show. Read access to the routing system took the customer's security review: a data-handling questionnaire, a call walking their infosec team through exactly which fields the hook would touch, then waiting. The data was a project of its own. Hazmat codes turned out to be recorded three different ways by three depots, one of them a retired coding scheme a depot had never migrated off, so you built the translation table by hand from a depot supervisor's memory and a box of old manifests. The hook itself cleared the customer's change-advisory board on the second attempt, and those weeks of forms, mappings, and meetings are the integration half of the week that The Job, Week to Week prices.
You've built the flagging system, and in a test it works. It catches the risky routes. Now comes the phase that quietly kills more deployments than any technical problem: getting people to actually use it. A great model nobody trusts is worthless. And the person whose trust you most need is the one from discovery: the fifteen-year veteran who's sure he's never wrong, and who will experience a system that flags his routes as an accusation.
The Morgan Stanley engagement is the touchstone here: OpenAI reports 98% adoption among advisor teams, and the reading this course takes from that engagement, argued on its page, is that the figure measures trust rather than logins, with the engineering effort (daily evaluation, human review) bent toward earning it. Adoption is not a rollout email. It's the work of making people choose to rely on you.
Before reading on
The system is ready to turn on for the veteran dispatcher. He didn't ask for it, he thinks he's never wrong, and he'll read a flag on his routing as management saying he can't do his job.
How do you introduce it to him so he uses it instead of ignoring or resenting it?
Not with a training email, and not by telling him it'll catch his mistakes. You reframe the tool as his, and you make the first experience one that respects his expertise. Watch.
Move 1 — reframe the tool as theirs, not a judgment of them
The flag can be experienced two ways: "the computer is checking up on you" or "here's a second pair of eyes on the tricky ones, so nothing bites you later." Same feature, opposite adoption. You choose the frame, and you choose it in his terms:
You (to the veteran): "You know this stuff cold. I've watched you. This isn't here to second-guess you on the routes you do in your sleep. Hazmat regs change under everyone, and this catches the rare case where a rule moved and nobody sent a memo. It's a backstop for the gotchas, so a shipment of yours never gets held up over a technicality. It works for you; it's not a report card."
You didn't claim he makes mistakes. You located the tool's value in something outside his competence, rules that change without notice, so using it costs him no pride.
Move 2 — earn the first win on his terms
Trust is won by evidence the user sees for themselves, and lost by the first false alarm that makes him feel policed. So the rollout is careful:
You start it in a quiet mode: it flags to him, privately, not to his manager. The first week, it catches one genuine case, a hazmat rule that had changed, and he catches it before a hold. You make sure he gets the credit for the save, to his manager, in his words.
Veteran, a week in: "It caught the ammonium nitrate reclass. I'd have missed that one. The rule changed in March."
You: "That's exactly what it's for. And notice it stayed out of your way on everything else."
Now the tool has proven, on his desk, that it makes him look good in front of his manager. He'll defend it. And a veteran who defends the tool converts the rest of the floor faster than any rollout plan you could write.
Bad / Good / Great — turning it on for the skeptic
Bad — "we email everyone that the new compliance tool is live and mandatory." You made it management's tool, imposed on them. The veteran complies by ignoring the flags, or games them, and adoption dies quietly while the dashboard says "deployed."
Good — "we train the dispatchers and explain the benefits." Better: you invested in the people. But if the framing is "this catches errors" and the flags go to management, the veteran still hears "surveillance," and training doesn't overcome that.
Great — "we introduce it to the veteran privately as a backstop for changing rules (his tool, not a report card), start it flagging only to him, make sure the first real catch is credited to him, and let him become the advocate." You designed the social rollout as carefully as the software, around the one person whose trust unlocks everyone else's. It's the same insight that carried discovery.
The probe to expect
Interviewer (or the VP): "That's slow. Why not just mandate it? Compliance is compliance."
You: "Because a mandated tool the dispatchers resent gets worked around, and a worked-around compliance tool is worse than none: it gives you false confidence. Adoption you earn is adoption that sticks. I'd rather have one veteran championing it in month two than a hundred people ignoring it in week one. Slow-to-trusted beats fast-to-ignored."
Interviewer (or the VP): "The regulator audits us next quarter. I don't have time for 'earn it' — I need to show coverage, now."
You: "Then those are two different clocks, and we run both. For the audit, I'll get you coverage fast: turn the flagging on everywhere in log-only mode, so every routing decision is checked and recorded and you can show the regulator the control exists on day one. That's the number you need, and it asks no one to trust it yet. The 'earn it' work is a separate track, whether dispatchers act on the flags, which is what actually reduces holds but isn't what the audit is asking for. You get coverage on the regulator's clock and behavior change on the slower one. What I won't do is fake the second to hit the first, because a coverage number that isn't changing behavior is exactly what an audit is built to catch later."
The move: the VP had a real deadline that "earn it" ignored, so you split the goal, coverage for the audit (fast, mandatable, honest) from adoption for the outcome (slow, earned), instead of defending your original timeline. You conceded the audit needs speed and held the line on not faking behavior change.
The week it went backward
Six weeks after go-live, the system flagged one of the veteran's routes as a hazmat misclassification. By then the quiet phase was over. With the veteran advocating, flags had gone live to the whole floor, and the audit's log-only track was recording every decision, so this flag was public: logged, visible on the shift, and wrong. He said the load was compliant, and he was right; he'd run that route for years. But the flag was in the audit record, so compliance held the shipment while they verified, and the verification took two days and came back clean. The cause was yours. The hand-built translation table from the build weeks had mapped one retired depot code to the wrong hazmat class, so a correctly classified load looked misclassified. The plumbing had come back, and it picked the worst place to fail: a public false alarm, on the one dispatcher the deployment's trust ran on, on a route he was right about.
The VP heard the same day: the system bought to reduce holds had just caused one. What saved that conversation was the ROI discussion from weeks earlier, where false flags were named as the honest risk and the plan was to start narrow and tune: a failure you predicted reads as tuning, and the same failure unpredicted would have read as a broken promise. That bought patience upstairs. On the floor it bought nothing.
On the floor, he didn't argue and didn't escalate; he stopped acknowledging flags. They aged in his queue (three, then nine), and the dispatchers who had started reading flags because he did began waving them off because he did. His discovery-phase skepticism, the thing the rollout had carefully disarmed, was now standing evidence: he'd said from the first week that he didn't need a machine checking his routes, and the machine had just proved him right by holding a clean shipment.
You found the bug in a day and shipped the fix in two more. You told him directly what the table got wrong, which depot's codes it affected, and why it wouldn't recur, then posted a plain write-up where the floor would see it. He heard you out, said "Appreciate you telling me," and turned back to his screen. The flags kept aging. The repair attempt fails, and it fails for a clear reason: the code was never what he distrusted. What broke was his standing. A screen told his shift, wrongly, that he can't classify a load, and a bug-fix notice does not reach that ledger.
The repair that held took the better part of a month, and it had two parts. The data first: you went back to the depot that owned the retired scheme, rebuilt the translation table against live manifests instead of a supervisor's memory, and added a check so any code the table can't translate cleanly comes to you as a data question before it can become a flag against a dispatcher. Then the posture: every flag now shows its evidence, the code as the depot recorded it, the translation applied, the rule it matched. Any dispatcher can mark a flag as bad data, which reclassifies it in the audit log as a system error and routes it to you to fix.
You (to the veteran): "The flag was wrong because I trusted a table I built by hand, and you paid for that in front of your shift. I can't take that back. Here's what's different: every flag now shows you the data it's standing on, and when the data's bad, you kill the flag. The log records it as the system's error, and fixing it becomes my job. You've been checking this thing's work since the day it turned on. Now that's official."
He read the evidence trail for a while, said, "We'll see," and went back to work. The flags in his queue kept aging for another two weeks.
No line of yours got him back; his behavior moved first, and slowly. You noticed him expanding a flag's evidence before dismissing it. Checking the tool's homework is still reading the tool. Then he marked his first bad-data flag, and it was one: a second retired code the rebuild had missed, and the fix went out crediting the catch to him, the same discipline as the first win pointed in reverse. Weeks after that, he acted on a true flag without a word about it. The holds-avoided board kept a flat stretch from those weeks, and you left it in the VP's view unexplained-away, because relabeling it would have spent the credibility the honest ROI framing had bought. When a new dispatcher eventually asked him whether the flags could be trusted, his answer was thinner than the advocacy you had before the false alarm, and sturdier, because it had survived one: "Check what it's standing on. It'll show you."
The move: a false alarm in front of peers costs more trust than ten true catches earn, and it charges the account of the person you can least afford: the converted skeptic, whose old doubts it re-arms. When it happens, the apology and the bug fix are necessary and insufficient: they repair the code and leave the social damage standing. The repair that works is structural: hand the skeptic the means to audit the system, so the next bad flag is his catch instead of his humiliation. Then time, with the trust returning slower than it left and only partway at first. A rollout plan is only real if it survives the week the engagement goes backward, because one comes.
What "adoption" actually means
You've driven adoption when the tool is used without being enforced, when the people it's for reach for it because it makes their work better or safer, and when the skeptic has become the advocate. Watch for the real signal over the vanity one: not "logins," but "did the veteran change his behavior, and does he defend the tool to his peers?" The observability you built measures the first; the second you learn by being on the floor. And hold the state loosely: it took one false alarm to lose the veteran and the better part of a month to get him partway back, so treat "adopted" as a state you keep re-earning, one that can slip in a single bad week.
The transferable pattern
Adoption is trust, and you earn it by making the tool feel like it belongs to the skeptic (reframed in their terms, rolled out to protect their standing, with the first win credited to them) and you keep it by planning for the false alarm that will spend it. The technical work makes the tool correct; the adoption work makes it used. A correct tool nobody trusts moved no number, so the adoption work isn't soft. It's the other half of the deployment.
Next: Handover & Scale. The engagement ends when the customer's team runs this without you, and that endgame is where one deployment becomes a capability.NextHandover & Scale