It Shipped — So Why Is No One Using It?

Show me the incentive and I will show you the outcome.

— Charlie Munger

The system finally went live.

The acceptance review was a picture of decorum: every technical metric checked off one by one, the project leads from both sides shaking hands for a photo, and once the customer's IT department read out "the system is now officially in operation," the applause came right on cue.

Three months later, a follow-up visit turns up a different picture: the last login is still stuck in week two after go-live, the business team's backbone users still have the same six-year-old spreadsheet open on their desktops, and when you ask about the system, the answer is "oh, that thing — I open it once in a while."

No incident, no complaint, no pushback — the system simply died, quietly and with perfect decorum.

This chapter takes up the question: once a system is live, has passed every technical acceptance check, and shows green on every metric, why does the business side still refuse to use it?

I. Go-Live Is a Process. Activation Happens in Behavior.

Start by pulling apart two words people conflate. "Going live" completes an administrative process — procurement and acceptance: the contract is fulfilled, deployment is finished, the acceptance form is signed. Whether a system is actually alive is judged by exactly one standard: has the target user group built a stable habit of using it in their day-to-day work — not applause at the demo, but the system still getting heavy use three months later, with nobody having to chase anyone.

The enterprise software industry has never been short on projects like this: every item on the feature checklist ticked off, and only five percent of people actually using it; the system hits four nines of availability, and the business side still prefers its spreadsheets.

Why do enterprise deployments so consistently die at activation? Because the three gates it has to pass are none of them in the code: users find it awkward — one extra step over the old habit, and nobody uses it; users don't trust it — one mistake, and trust resets to zero; users see it as none of their business — and then nobody touches it.¹

None of the three gates can be cleared back at headquarters. They can only be passed one at a time, at the customer — in their conference rooms, on their shop floors, at their desks.

This is exactly the watershed between an FDE and traditional "deliver and leave" implementation: traditional implementation treats the acceptance sheet as the finish line; an FDE treats a change in the customer's behavior as the finish line.

II. Dying Quietly After "Successful Launch"

A frontline FDE practitioner, on a podcast, boiled the causes of failed projects down to three:

First, the executive sponsor's expectations of what AI can do exceed reality. They assume that once AI is switched on, the company simply takes off — they treat it as a superhero, not a tool. Expectations set that high are guaranteed to crash, and the crash ends in abandonment.

Second, the project gets initiated by the technical department instead of the business department. The business side treats itself as the client and the technical team as the vendor — a system initiated this way is almost guaranteed to fail, because the business team is the one who understands the business, and the technical team can't supply the knowledge and judgment behind product selection, forecasting, or negotiation. The system ends up as the technical team's achievement, not the business's tool.

Third, and most fundamental: the organization's incentive structure never changed to match. In the guest's own words — "Don't think of this as a piece of software going live. Think of it as a batch of new employees going live — a new wave of productive capacity has arrived, and the relations of production have to change."² In plain terms: the system isn't just one more piece of software, it's a batch of "new hires" — and when new hires come on board, performance metrics, division of labor, and reporting lines all have to be rearranged accordingly. Keep managing it the way you'd manage a tool — leaving performance metrics and division of labor untouched — and this batch of "new hires" naturally can't perform.

Notice what these three failure modes have in common: not one of them happens before go-live. All of them happen after "successful launch." At the moment of going live, the project is still scoring full marks; the death happens quietly, day by day, over the following three months. Of the three causes, the first two point at the executive sponsor (unpacked in full in the next chapter); the third — incentives — is what this chapter focuses on. First, a look at more real feedback from the field.

One engineer who ran four iterations on a customer-service project — the four versions evolving from an orchestration framework all the way to a locally deployed system with a full engineering shell — was technically a success. Asked what the project actually did for the business, his answer was blunt:³ without headcount cuts, there's no way to show a return. Not one person was let go from their customer-service team; the time saved just went toward "creating more value" — but that made the ROI impossible to pin down, because in most bosses' arithmetic, time saved doesn't count, only headcount saved does. Here, the ROI math and the employees' interests collide directly.

Another practitioner complained: "With AI we're on 997 [9am–9pm, 7 days a week]; without it we were only on 996." — the tool added workload instead of cutting it: when the system crashes, someone has to firefight; when its memory gets wiped, someone has to re-feed it; when a process jams, someone has to unblock it by hand.⁴

None of this feedback is a complaint about "the project failing" — the technical capability was never the problem.

What's really stuck is structural: the time saved never converts into the ROI ledger, and the extra work created never gets reassigned to anyone.

The project was built right, and the people using it are no better off for it — that's the actual problem.

III. What Training Can't Fix, Incentives Can

Unpack the third failure mode into a usable diagnostic tool. For frontline users, whether they use a system comes down to three questions — nobody asks them out loud; users run the math silently, in their own heads:

First: does using this system change how I'm evaluated? If performance metrics stay the same old ones, every minute spent learning the new tool is unpaid overtime.

Second: who gets the time I save? If the entire benefit of the efficiency gain goes to the company while I bear the cost — learning the new tool, absorbing its new mistakes — nobody's going to sign up for that deal.

Third: whose fault is it when the system errs? If mistakes made by the new system count against me while mistakes in the old process are treated as "just normal," then the rational choice is to stick with the old process.

Get any one of these three answers wrong, and no amount of polished training will help — training solves "can I," incentives decide "will I." The practitioner quoted earlier offered a positive counterexample: when a sales team adopted a new tool, its scorecard was rebuilt from 100% results-based to 80% results plus 20% process — process data generated by the new system converted directly into performance points, and only then did adoption of the tool actually stick.

There's an even more thorough positive example of incentive design. A housing-rental platform has a "property manager" role that handles everything a tenant needs, big and small — a barking dog next door, a leaking air conditioner, all the small, emotionally charged stuff. When the AI team came in, they didn't build "auto-reply." They redrew the division of labor first: the machine took over all the routine responses, and the humans moved to the warm, high-touch care work — paired with an agent that surfaces sales opportunities, prompting the manager that "this tenant has a cat and is traveling this week — worth pitching a pet-sitting add-on."

Over a year, output per person went from one manager per five hundred tenants to one per twelve hundred, with a target of two thousand the following year. The key detail: nobody in that department was laid off.² When efficiency gains aren't tied to headcount cuts, employees don't treat the system as an enemy — "no layoffs" here isn't a moral gesture. It's the incentive design itself.

IV. Employee Hostility: Fear Curdles into Non-Cooperation

Over the past couple of years, "teach the AI and you've just made yourself redundant" has become the office worker's unspoken dark joke. "Distillation" started out as a model-training term, and "distilling a coworker" is now catching on too — shorthand for feeding a veteran employee's experience into an AI, and then that employee getting "optimized" out of a job.

Behind the joke is a real backdrop: a steady drumbeat of AI-related layoff news has turned "is my experience even worth anything" into an alarm that can go off in any frontline employee's head at any moment.

Self-preservation is instinct, and once that instinct fires, almost nobody says no to your face. What's far more common is quietly folding that wariness into everyday cooperation: they'll teach it, but they'll hold something back; they'll cooperate, but they'll stall wherever they can and nitpick wherever they can.

Incentive design solves "is this worth it" — but however clean the math, it can't stop an employee from distrusting the system at a gut level. That distrust is harder to deal with than "not worth it," because it usually goes unspoken.

At a company that delivers enterprise agents and pairs a frontline veteran with an "AI apprentice," the veteran will say: "you're distilling my experience — once you've learned everything I know, I've got nothing left to be worth to this company."² That line names precisely the other half of what the earlier sections never quite spelled out: everything before this was about "is the math worth it"; this is about "even if the math checks out, I still don't want to use you."

That company's response has two layers. The first: reciprocity comes before extraction — "before you learn from him, you have to give him something first." Their AI apprentice doesn't start by studying under the veteran; it starts by working — offering suggestions when the veteran builds a shift schedule, offering input when the veteran forecasts sales. Only once the veteran genuinely thinks "this apprentice is useful" does real teaching begin. The second layer: redefine the value — "a strong frontline employee whose experience is worth distilling is actually one of the company's biggest assets — you shouldn't be trying to get rid of him," because the business context is shifting every day, and AI can help think through a lot of things, but it can't replace frontline judgment and decision-making.

Push further, and this employee's value hasn't shrunk — it's grown. A top salesperson used to be impressive by selling two or three times as much personally, or, with more skill, by building a team that sold two or three times as much. Now, the judgment and methodology they've built up can be replicated across a thousand, ten thousand salespeople nationwide — their value to the company can only get bigger, and the incentive attached to it has to rise with it, not stay flat. The veteran's new identity in the system is trainer and authority, not the thing being replaced.

The same fear shows up in a client one enterprise AI adoption consultant worked with: "It's all fully automatic now — why does it still need me to click a button? What reason is there for me to even still exist?"⁵ This isn't melodrama, it's genuine existential anxiety: if a person's entire responsibility in a workflow has been compressed down to "click to confirm," that role was already hollowed out to begin with. Adoption design has to answer head-on: what is this person's new role in the workflow? Even if the new role is nothing more than judgment and accountability, it has to be stated explicitly and written into the new job description — leave it unsaid, and the employee is left to guess in a fog of anxiety, and the guess almost always lands on the worst-case scenario.

Fear doesn't always get said out loud — more often it turns quietly into behavior instead of open opposition. Four patterns show up most:

Stalling — sitting on issues that should be flagged, and letting the system run straight into them; Hedging — cooperating on the surface while quietly keeping the old process running as a fallback, so that when something goes wrong, there's proof "I said this wouldn't work"; Nitpicking — hunting for flaws, piling on edge-case requests and "this doesn't work well" complaints to slow acceptance down and make the system look less finished than it is; Bad-mouthing — describing the experience to coworkers in the most negative terms possible, pulling the undecided into opposition before they've even formed their own view.

What all four have in common is their killing power: they wear the costume of "cooperation," which makes them harder to spot and harder to dismantle than open opposition.

In practice, three moves reliably defuse this kind of non-cooperation: don't let the system present itself as a replacement for people (AI handles the repetitive work, people handle the judgment calls); go after the user's most annoying repetitive task first, so they get an early taste of the payoff; and let the people who benefit speak for you — one testimonial from a user who's actually gained something does more work than a hundred explanations from you.⁶

The "no layoffs in this department" promise from the property-manager case, and the gradual shift in the weekly-report example from "writing the report" to "just leaving your work trail behind" — both are, at bottom, about catching this fear first and talking incentives second. Leave the fear unresolved, and no matter how clean the math is, nobody will dare use the system — some people may even quietly root for it to fail. And the real cure for this fear usually isn't in the project team's hands: what employees are watching for isn't what some project owner says, it's how the very top of the organization positions itself. Who opens that door, and how, is unpacked in full in the next chapter.

V. Gradual Change: Don't Go All the Way at Once

Beyond incentives, the second front in adoption is how the system enters the workflow.

There's a rule that keeps proving itself here: embedding into an old habit beats starting from a blank slate.

One investment firm's weekly-report automation went through a textbook three stages: stage one, a daily-report bot built into their collaboration platform, still filled in by hand; stage two, switched to voice — a few sentences on the way home about "what kept you busy this week, what's stuck," and the system turns that into a report; stage three, not even voice is needed anymore — the system is authorized to read the trail people leave behind at work directly — chat logs, documents, calendars — and auto-compiles the summary. People went from "writing the weekly report" to "just leaving their work behind properly."⁴ Notice the direction of this path: it's not throwing the person out of the process all at once, it's having each stage ask a little less of them while leaving them a little more confirmation authority.

The counter-lesson cuts deeper. In one widely circulated case, a group of veteran workers who had run an eleven-step process for years were handed an agent that did the whole thing "all at once" — and they simply stopped using it. Adoption only came back once the design was changed to keep the original steps, have the agent complete each one incrementally, and let the workers see the intermediate output.⁷ The logic isn't mysterious: intermediate output is a person's confirmation point, and a confirmation point is what trust rides on. Hide every intermediate step inside a black box, and you're effectively asking the user to put their authority on the line to vouch for that black box — nobody's willing to do that.

So when designing for adoption, start with a plain question: is what I'm building meant to remake how this person works, or is it something they'd be glad to pick up and use as-is?

This question gets pushed to its extreme in "fully automated" scenarios. One enterprise AI adoption consultant relayed a client's judgment on fully automated quality: "what comes out of full automation usually only rates a sixty or seventy."⁵ The reason is plain: fully automated output is exactly as good as the model, and the model is shared by everyone — when the model improves, everyone's output improves together, which is the same as nobody having improved relative to anyone else. The mediocrity of full automation is therefore the ceiling on adoption: users quickly notice that the system's output doesn't match their own professional reputation, and abandonment is just a matter of time. Flip it around, and the twenty points of judgment a person contributes on top is exactly the gap between the system's passing grade and an excellent one — which is a deeper reason for keeping "intermediate output" and "confirmation points" in gradual embedding: it isn't reluctance to change the process, it's that those twenty points can't happen without a person.

People should be the answer to the problem, not an obstacle in its way.

VI. Running the Organization as Adoption Infrastructure

Incentives and embedding solve "will it be caught" and "how it gets caught"; dealing with employee hostility solves "can it be trusted." Stretch the timeline out over the whole project, and adoption has one more organizational layer — not defending against fear, but cultivating allies. Two types of people are worth naming individually (see Figure 15-1).¹

Figure 15-1: Adoption happens in user behavior — it needs workflow, incentives, support, and measurement all turning together.

Sponsors: people inside the customer's organization who genuinely believe in this and are willing to stake their own credibility to clear the way for you. Cultivating a sponsor has three parts — give them material they can actually take and present, turn their foresight into their own track record, and stand in front of them when something fails. One well-tended sponsor is worth ten product pitch meetings.

Influencers: the uncrowned kings of any organization — the veteran on the shop floor, the person in a department everyone says "just ask them." They don't hold formal power, but they hold trust; one "this thing actually works" outweighs three all-hands emails from management. Letting them try it first, taking every complaint from them seriously, and making their input visible ("this field was added because Master Wang suggested it") is the shortest path around the "I didn't build it, so I won't use it" reflex.

Last is pace. Iteration during the deployment window has to run on "days," not "versions": a business user says a field is missing from the output in the morning, and the field is added by the afternoon; a shop-floor supervisor says the button's too small to hit accurately with gloves on today, and the button is doubled in size tomorrow. This response speed matters far more than the feature itself — users form their judgment within the first month: is this team actually here for real, or just another one that delivers and disappears. The prioritization rule flips too, relative to product-cycle norms: don't rank by feature importance, rank by "adoption-blocking severity" — whatever is standing in the way of tomorrow's use is today's top priority.

The same goes for training: training isn't a lecture, it's running alongside someone — a week spent shadowing real tickets does more than a single class.

VII. Adoption Needs Measurement, and the Definitions Come First

Improving adoption needs a dashboard, and two metrics are enough.

Activation rate: what share of target users genuinely use the system each week — with three definitional elements to pin down: the denominator (who counts as a target user, using the headcount set in the Chapter 8 acceptance agreement), the window (weekly or monthly), and the criterion (does a login count, or does it require a real completed task).

Diversion rate: of a given category of task, how much of it has moved from the old path onto the new system — it's more honest than activation rate, because it measures not "was it opened" but "did the work actually get taken over."¹

The discipline around definitions is the same as in Chapter 8: a pretty number under a vague definition is worth less than an ugly number under a clear one. "80% of users have used the system at some point" versus "60% of target users complete at least one real task in the system every week" — the second number is smaller, but it's the only one that can guide improvement.

This chapter has gone from causes of failure to incentives to gradual embedding, but it's really been saying the same thing the whole way through: a system entering an organization is a contest of interests and inertia.

And there's exactly one person who can change the rules of that contest: the executive sponsor. Which is why the next chapter is about executive sponsorship.

---

Footnotes

1. Fan Bing, Forward Deployed Engineer (FDE) (XDash open-source book) ↩ ↩² ↩³

2. Crossroads × Rolling AI, "A Conversation on FDE" (podcast) ↩ ↩² ↩³

3. "AI Job Sense: Stop the Agent Rat Race" ↩

4. Yilu Tongxing (一路瞳行), Episode 134: "From AI Assistant to Digital Employee" ↩ ↩²

5. Turning Point (破局点), Episode 31: "FDE, Chinese Style" ↩ ↩²

6. "100 Questions About FDE" (open-source ebook) ↩

7. "FDE Engineer 101: Bridging the Gap Between AI and Business" (Chinese-language compilation video) ↩