Change Management and Adoption

The cutover is not the finish line

A common pattern in FDE engagements: cutover succeeds, the celebration email goes out, the team flies home, and three weeks later usage quietly falls off. By month two, the dispatcher is back to the spreadsheet “for some things,” and by month four, the new system is a backup for the old workflow rather than the other way around.

The technical work shipped. The adoption work didn’t.

Change management is the discipline that converts a deployed system into a used system, six months out. It is not a separate phase that follows cutover — it runs in parallel, starts in week 1 of the engagement, and continues past the FDE’s departure.

Why adoption fails

Three failure patterns account for most of it:

Pattern 1 — The system requires effort the old way didn’t

The new morning view is objectively faster than the spreadsheet, if you’ve learned the keyboard shortcuts. Until then it feels slower. If the dispatcher quits in week 2 to escape the discomfort of new-tool-friction, you’ve lost her — the spreadsheet is right there, and the muscle memory is decades old.

Pattern 2 — The system breaks the social workflow, not just the technical one

The morning view shows the same information Maria used to email Doug at 6:15. Now Doug doesn’t need the email — but the email was also how Doug knew Maria was awake and on the job. Without it, Doug feels uneasy, and Maria misses the implicit “good morning” loop.

Software changes social workflows too. The change isn’t just a tool change; it’s a relationship change. If you don’t notice the social workflows, you don’t get adoption.

Pattern 3 — There is no consequence for not using it

If the spreadsheet still works, and nobody is measured on whether they’re using the new system, then “use it when convenient” becomes “use the old way when busy.” Usage decays.

Each pattern has a counter, and the rest of this lesson is about applying them.

The four roles in any change

Every customer organization, at the moment of a change, sorts into four roles. Recognize them; design for each.

You do not convert all four to champions. You shouldn’t try — the conscript who reliably uses the system is more valuable than the lukewarm champion who advocates without using.

For Northbound, the cast might be:

• Champion: Maria (saw the morning view from iteration 1, has shaped it)
• Skeptic: the IT director (worried about security, support load, vendor lock-in)
• Conscript: Jorge (the morning-shift dispatcher; will use what he’s told to)
• Avoider: one of the senior drivers (the new system creates visibility he doesn’t love)

The change plan is different for each. Maria gets the spotlight. The IT director gets data on incident rate. Jorge gets a 1-on-1 training. The senior driver gets gentle, persistent expectation-setting from his hub manager — not from you.

Training that produces use

Most operator training does not produce use. Two-hour webinars where someone clicks through screens are the canonical failure. The operators sit through them, nod, and three days later remember nothing.

What actually works:

Train on real work, not on demos

The training session is not a tour of the screens. It is the operator doing their actual job, today, using the new system, with the trainer next to them. If the dispatcher is scheduled to do the 6:30 morning batch on training day, training is the 6:30 morning batch — with you sitting beside them, not in a conference room.

Train one operator at a time

Group training feels efficient. It isn’t. The operators who already know the workflow get bored; the ones who don’t are afraid to ask. Train 1-on-1 or, at most, 1-on-2. A senior FDE will do 6-10 one-on-one training sessions in the cutover week.

Train with a written cheat sheet

A one-page laminated cheat sheet covering the 5-7 actions the operator will use most. Keyboard shortcuts, common gotchas, where to find help. Operators tape it next to their monitor and refer to it for weeks. Skip the 40-page manual — it goes in a drawer.

Train just before they need it, not weeks before

The training that sticks is the training that’s immediately practiced. If you train the dispatcher two weeks before cutover, they’ll forget by go-live. Train in the few days before, ideally on the day, with the trainer staying on hand for the first live use.

Train the trainer

Identify one operator per role who can train the next operator. Spend extra time with them. They become a peer-help node that scales after you leave.

For Northbound: Maria becomes the trainer for the other two dispatchers. Doug becomes the trainer for the other hub managers. The first hour you spent on Maria’s training is the seed for an internal training capability that runs without you.

Removing the old path

Adoption requires that the old path is harder or impossible. Three moves to consider, in order of severity:

Move 1 — Soft deprecation

The old tool still works but is labeled “deprecated — use the new platform.” The morning email Doug used to send is still possible but is no longer “the official channel.” This works when the old path has some genuine value the new one can’t yet replace, and you’re giving the team time to migrate.

Move 2 — Hard deprecation

The old tool is retired on a specific date. The spreadsheet is no longer updated; the export feed that filled it is turned off. The cutover-complete memo (from the production deploy lesson) lists what is now retired, and the customer’s team enforces it.

Move 3 — Path-of-least-resistance redesign

The most elegant move when available. The old path is technically still possible but the natural action now goes through the new system. The shared dashboard everyone looked at every morning is now your screen. The Slack channel where loads were tracked is now an embed of your morning brief. The default new-employee training documents now point at your platform.

Most healthy engagements do all three over the first 60 days post-cutover. Soft deprecation immediately, hard deprecation around day 30, path-of-least-resistance redesign continuously.

Handling the skeptic

The skeptic is the role engineers most consistently mishandle. The instinct is to either avoid them or to “win them over” with more demos. Both are wrong.

The skeptic is, in most engagements, partially right. Their concerns may be:

• The new system depends on vendor X they don’t trust
• The new system creates a support burden their team will absorb
• The new system makes a workflow more rigid that benefits from flexibility
• The new system surfaces data that they prefer remained ambiguous (sometimes a real concern; sometimes a political one)

A senior FDE does three things with a skeptic:

1. Name their concern in writing, accurately

Before you respond, reflect what they said back to them in writing. “Our understanding is that you’re concerned about the on-call rotation your team will inherit.” Get them to confirm or correct the concern. Many objections evaporate when accurately named; the rest sharpen into something specific you can address.

2. Address each concern with a concrete commitment or trade-off

Not “we’ll handle it.” A specific commitment: “We’re funding an on-call retainer for 6 months. We’ll cover incidents through Q1. Your team takes over at month 7.” Or, if you can’t meet the concern: “We’re not able to remove that dependency. The trade-off we’re accepting is X.” Honesty about trade-offs builds more credibility than over-promising.

3. Provide an honorable off-ramp

The skeptic should be able to be wrong about you without being humiliated. Don’t run a victory lap. When the system is six months in and they admit it’s working well, the right response is “your concerns made it better” — and mean it, because they usually did.

Specifically don’t try to politically isolate the skeptic. They almost always have a reason for the position they hold — institutional history, technical depth, a previous bad experience. Honor it. Engagements where the FDE made an enemy of the skeptic to “get things moving” have a way of imploding in month 7 when the skeptic surfaces a real issue that you ignored.

The honeymoon and what follows

A common arc:

                          adoption
   100% ┃                                                          
        ┃     ╱─╲                                                  
    75% ┃    ╱   ╲           ╭─────────╮                           
        ┃   ╱     ╲         ╱           ╲___                       
    50% ┃  ╱       ╲       ╱                                       
        ┃ ╱         ╲_____╱                                        
    25% ┃╱           trough                                        
        ┃                                                          
     0% ┴────────────────────────────────────────▶ time            
         cutover  honeymoon  crash    recovery    steady-state     
                  (3 wks)    (1-2 mo) (1-3 mo)   (durable)         

The honeymoon is real and so is the crash. Many engagements end in the trough, because the FDE flew home thinking cutover was the finish line.

What drives the crash:

• The novelty wears off
• An edge case nobody tested for emerges in week 4
• A skeptic finds an issue and the rumor mill amplifies it
• Operators who tolerated friction during the honeymoon stop tolerating it
• An organizational change (a layoff, a reorg, a quarter-end push) shifts attention away

What drives recovery:

• A few operators developing genuine fluency and proselytizing
• The system surfacing new value that wasn’t initially obvious (an analytical insight, a previously-impossible query)
• The retired old path no longer being a viable fallback
• Continuous small improvements that respond to real complaints

A senior FDE plans for the trough explicitly. The post-cutover engagement plan has scheduled improvements through month 3, not just maintenance. The customer hears “the trough is normal, here’s what we do about it” before they experience it.

Adoption metrics that matter

The customer’s exec wants to know “is this working?” The metrics most often reported — logins, page views — are noise. The metrics that matter:

A worked example for Northbound, month 1 post-cutover:

Adoption — Month 1

DAR:                   3 / 3 dispatchers, 5 / 5 days
Workflow completion:   morning batch 100% on-platform
                       reassignment   91% on-platform
                       (9% manual override, all via the platform's emergency-override action)
Old-path usage:        spreadsheet opens 0/week (after week 2)
Time-to-action:        morning batch → call with Doug
                       was 45 min, now 6 min (median)
Self-resolution rate:  68% of operator questions resolved with cheat-sheet or peer; rest to FDE
Outcome:               on-time delivery 86.7% (was 78% baseline)

Six rows. Each measurable. Each tied to a decision.

What this report is not:

• A count of logins
• A list of features deployed
• A snapshot of NPS

Vanity metrics flatter the engagement. The metrics above tell the truth.

Common failure modes

Treating training as a one-shot event

A 90-minute training session in week 4 satisfies a project plan and produces almost no use. Replace with embedded, 1-on-1, on-the-actual-task training, repeated weekly for the first month.

Skipping the social workflow

You modeled the data; you didn’t notice the morning email. Some social workflows need to be deliberately preserved (by building them into the platform — e.g., a “Doug pinged” event), some need to be deliberately retired (with comms), but none should just disappear without acknowledgment.

Letting old tools linger indefinitely

Without a hard retirement date, operators triangulate against the new system “just to be safe.” The triangulation never ends. Set the date, communicate it, hold it.

Designing the change like an engineer

A status email that says “the platform now supports cross-hub reassignment, with audit trail and idempotent action design” reaches no operators. Translation: “you can now reassign loads across hubs from the morning view; the system remembers who made the change and you can undo it.” Same content, different audience.

Ignoring the trough

Counting on the honeymoon to last. It doesn’t. Plan for the trough, schedule the improvements, brief the sponsor that the trough is normal.

Forgetting the trainer

You train Maria; she trains nobody; six months later when the engagement renews and Maria moves to a different role, nobody else knows the system at her depth. Train the trainer.

The 90-day post-cutover plan

A useful artifact to produce alongside the cutover-complete memo. Three columns: week, planned improvement, owner.

WEEK   FOCUS                          OWNER
1      First-week stabilization       FDE on-site
2      Operator 1-on-1 training round FDE + Maria
3      First retro with all roles     FDE
4      Identify and ship 3 quick wins FDE + customer eng
5      Skeptic check-in               FDE + IT lead
6      Trough briefing to sponsor     FDE
7-9    Targeted improvements          Customer eng (FDE backup)
10     Train-the-trainer formalization Customer ops
11     Owner-transition check         FDE + customer eng
12     90-day recap to sponsor        FDE + customer ops
13     FDE transitions to retainer     —

The plan is signed by the sponsor and the customer’s ops lead. Adherence is reviewed weekly during a 30-minute Monday touch.

Closing

The cutover lesson said: “operating is not the same as adopted.” This lesson is about closing that gap. Done well, by day 90 the system is not just live — it is the way the work is done, and the customer’s team is performing it competently without you.

That outcome is the platform on which hand-off is finally possible. The next lesson — Hand-off to the Customer Team — covers the discipline that ensures the platform survives your departure.

Key terms to remember

• The four roles — champion, skeptic, conscript, avoider
• Train on real work — the training session is the actual job, not a demo
• The trough — the inevitable adoption dip after the honeymoon
• Path-of-least-resistance redesign — making the new way the natural default
• Adoption metrics — DAR, workflow completion, old-path usage, time-to-action, self-resolution, outcome
• Train-the-trainer — building internal training capability before you leave

What’s next

Adoption is taking hold. The system is the workflow. But you are still on site, the customer’s team still calls you for changes, and you are personally the keeper of how things work. The final lesson of Phase 5 — Hand-off to the Customer Team — covers the careful transfer of ownership that determines whether the platform is yours forever or theirs from now on.