Introducing change: why most improvements die at the pilot

There's one kind of company meeting that repeats over and over. Someone brings an improvement — a new tool, a different way of handing off work, an automation that saves half a day a week. They demo it with an example, everyone nods along, leadership says "great, let's do it." Two months later you ask how it's going, and the answer is: "Well, right now it's just Petra using it." Six months later nobody's even asking anymore, and Petra's moved on to a different job in the meantime.

Nobody did anything obviously wrong. The idea was good, the tool works, the licenses got paid for, the training happened. And yet the company ended up right back where it started — just a bit more cynical, because next time people won't nod along quite as readily at the next improvement. Every failed attempt at change makes the next one more expensive.

Change happens in an organization not at the moment something gets rolled out, but at the moment enough people stop doing things the old way. That's the whole difference between the sentence "we rolled it out" and the sentence "people are using it" — and the vast majority of a company's energy, money, and attention gets spent on the first of those. This chapter is about the second: why improvements die between the pilot and becoming routine, and how to work with that without turning it into yet another project with a steering committee.

Anatomy of a failure: five ways an improvement dies

When you go through improvements that didn't pan out at companies, a surprisingly small number of stories keep repeating. They're not accidents — they're structural mistakes you can spot in advance.

The enthusiast leaves. The most common cause of death. The whole change rested on one person who thought it up, pushed it through, set it up, and kept it running. Nobody else knows why it's set up the way it is, where to fix it, or what to do when it breaks. That person leaves, changes roles, or just gets a different priority — and the improvement quietly freezes. Usually nobody announces it. Three months later it just turns out everyone's been working the old way for a while.

Leadership expects a miracle within a month. The change was approved with expectations incompatible with how learning actually works. A tool can be rolled out in a week, but a habit takes months to change. In the first weeks after rollout, productivity is typically lower than before — people are learning, making mistakes, hunting for where things are. If leadership judges at this point that "it's not working," they kill the change at exactly the moment it's starting to work. This dip is a normal part of every transition; the problem isn't the dip, it's that nobody planned for it or explained it to anyone in advance.

People fear for their jobs. This reason never shows up in meeting minutes, because nobody ever says it out loud. It shows up differently: endless comments on details, "I don't have time for this right now," discovering serious exceptions the new way "just doesn't cover." When someone believes a new way of working is optimizing them into unemployment, they'll passively slow it down — and that's rational behavior. With automation and AI, this fear is the default today, not the exception.

A tool with no process. The company bought software believing the tool was the solution. But a tool doesn't solve anything — it just enables doing something differently. When nobody agrees on who enters what into it, when, in what form, and what happens with it afterward, you get a third place to store information, alongside the two you already had. The result isn't simplification, it's another layer. The chapter Processes and automation covers this in more depth — its basic rule applies here too: automating a broken process just means making chaos faster.

Training with no follow-up support. A two-hour training session happened, everyone got a link to the documentation, and that's considered handled. But people don't ask questions during training, when they still don't know what to ask. They ask three weeks later, when they hit their own specific case — and at that point there's nobody to ask, the documentation doesn't cover it, and the old way is two minutes faster. That's exactly where the decision gets made.

Notice that not one of these five causes is technical. The tool usually works. What fails is the transition of people from one way of working to another — and that transition doesn't get planned for, because it doesn't look like work.

Change isn't a project, it's a transition of people

Companies know how to run projects. They have milestones, budgets, owners, and statuses for them. That's why every change naturally gets dressed up as a project: roll out tool X, a deadline, a budget, done. But a project ends at delivery. Change only begins at delivery.

It's useful to separate two things that routinely get merged into one. Rollout is a technical event with a date — the system goes live on Monday. Adoption is a process with no sharp date — people gradually move over, some fast, others slow, some never. You manage rollout with a plan; you manage adoption by watching and reacting. When both get tracked with one indicator ("rolled out: yes"), the company has no data on adoption at all and ends up steering it by gut feel.

Two well-known frameworks are worth attaching here. John Kotter's model of change management emphasizes things companies typically skip: a clear explanation of why this is even happening, a coalition of people across the organization instead of one accountable person, visible quick wins, and — probably the most important part — anchoring the change into everyday operations so it doesn't vanish once the initiator leaves. Not as a checklist to tick off, but as a reminder that communication and sustaining the change are their own work, not a side effect of rollout.

The second framework is the diffusion-of-innovation curve — the observation that in any group there are people who happily try new things on their own, then a larger group that waits to see it work for someone else, and a minority that resists until the very end. The practical consequence is simple, and companies chronically sin against it: put your energy into the people in the middle, not into the loudest resisters. Convincing the most skeptical colleague is the most expensive investment possible, and it usually doesn't bring anyone else along. But once the pragmatic middle starts working the new way, the resister eventually adapts on their own — or at least stops being the yardstick for whether it worked.

That leads to a practical pacing recommendation. Don't ask "when will everyone be using this," ask "which group should use it first, and how will I know it worked for them." The difference between "we rolled it out" and "people are using it" is a question someone has to keep asking out loud regularly — otherwise nobody asks it at all.

Champions inside teams instead of a top-down directive

A top-down directive has one huge advantage: it's fast to issue. And one fatal downside: it can't answer the questions that arise the moment the change meets the reality of a specific role. The manager who announced the change has no idea that accounting has five types of documents that don't fit the new procedure. The people in accounting know it — and they stay quiet, because nobody told them their problem was part of the brief.

A champion is a person inside the team who takes ownership of the change and is available to others for it. Not a trainer, not an inspector. Someone you can ask over coffee, who doesn't treat that question as a bother. Their main value isn't knowing the tool best — it's that they speak the same language as their colleagues and know their exceptions.

There's a typical mistake in picking one: choosing the biggest tech enthusiast. But that person's experience is often untransferable to others ("it works for me, so why not for you"). A better choice is a respected practitioner — someone people already come to when they're unsure, even if they approach the new thing with mild skepticism. A skeptic who gets convinced is the strongest evidence you can have in an organization.

A champion needs three concrete things, or it's just a title. Time — explicitly set aside, not "on top of your own work," because that loses to deadlines. A mandate — the right to change the procedure when it turns out in practice the proposed way doesn't make sense; a champion with no right to change anything quickly becomes an advocate for something they don't even believe in themselves. And a direct line to whoever's sponsoring the change, so problems get solved within two days, not at next month's meeting.

And then there's a risk that brings the whole story back to the start: one champion is one point of failure. When that person gets sick, gets a different priority, or leaves, the change is back down to one leg. That's why champions make sense in the plural, and why their first job is to hand things off, not just help — every answer they give should end up somewhere the next person can find it too. The tip Onboarding a newcomer: a Project that answers on your behalf describes a practical way to turn that kind of knowledge into a form that answers even without its original author.

A pilot that actually accomplishes something

Pilots have a bad reputation at companies, because the word usually conceals postponed decision-making. "We'll try it small" often means something gets launched with no clear scope, no success metric, and no date for deciding. A pilot like that can't fail or succeed — it can only drift into oblivion.

A pilot worth running is an experiment with both possible conclusions written down in advance. Before it even starts, one page has to spell out: what specifically is changing, for whom, for how long, what we'll measure, and at what result we'll expand it or scrap it. That last part is the most important and most often missing — a success criterion written up after the pilot ends can always be bent to fit whatever happened.

Pilot length has an optimum. Too short measures only excitement about novelty; too long loses attention and fizzles out. For a change to a work procedure, it's sensible to think in weeks rather than days — long enough for people to get through the uncomfortable part of learning, short enough that a decision can still be made promptly.

Volunteering has one uncomfortable consequence you need to plan for: results from a volunteer pilot are systematically better than what full rollout will look like in reality. Volunteers are motivated, more tolerant of mistakes, and willing to put in extra time. When a pilot goes great, that doesn't mean the whole company will take to it the same way — it means it's not nonsense. That's still useful information, just don't overweight it.

Talk about concerns before the break room does

The most dangerous sentence when introducing change is "nothing's changing for you." It's almost always false — if nothing were changing, the change wouldn't have a point — and people can tell. The moment they realize something is changing, they stop trusting everything else they were told about it too.

The alternative that works is boring and uncomfortable: go through the roles one by one and, for each, say concretely what's changing for it. Not general benefits for the company, but what that person will see on Monday morning. Which steps go away. Which get added. What'll be slower at first. What's newly expected of them, and what's no longer their concern. This level of concreteness is the only one people actually understand — anything above it plays like corporate elevator music in the background.

Part of this includes the things that are hard to say. When an improvement means a certain kind of work goes away, say what happens to the freed-up time, and be as concrete as possible — whether it moves elsewhere, whether the company stops hiring, whether the role's scope changes. If you don't know the answer right now, say you don't know, and say when you will. That's still incomparably better than a reassurance that stops being true in three months. The one thing a company can't afford to lose is the credibility of whoever's explaining the change — without it, further improvements are dead before they're even presented.

For changes involving AI, two more topics come up that need to be addressed head-on. The first is the principle "AI proposes, the human approves": no output goes out or feeds into a decision without a specific person checking it and taking responsibility for it. It sounds like a formality, but for people it's essential information about what their role will be — and it's also a real safeguard, because language models can be confidently wrong. The second topic is data: what's okay to feed into tools and what isn't. Sensitive information — personal data, health information, trade secrets, materials under contractual confidentiality — belongs exclusively in a paid company account with contractually secured data protection, and even there only within the scope allowed by internal policy. The tip AI at the company: a complete guide to rollout walks through the full process, from the data foundation through tool selection to a company policy.

And one last thing communication needs: a place to say it's not working. When the only feedback that reaches leadership is enthusiastic, that usually means the criticism exists — just somewhere else. Usually in the break room, where nobody ever corrects it.

Measuring adoption vs. theater metrics

There's a whole category of numbers that look like proof of success and aren't proof of anything. Number of licenses purchased. Number of people trained. Number of accounts that logged in at least once. Number of app downloads. These figures share one property: they look great on a slide and grow on their own, even when nothing's actually changed in how the real work gets done.

The difference between a theater metric and an adoption metric is in what they answer. Theater answers the question "did we do what we said we would." Adoption answers the question "is work happening differently than before." The second question is more uncomfortable, because the answer can be no.

A good adoption metric has three qualities. It relates to actual work (not to the tool), it can be determined without people having to manually report it, and it's resistant to gaming. That last point gets underrated: any indicator that becomes a target starts getting manufactured. When you measure the number of records in a new system, empty records start appearing. That's why it's sensible to pair a usage indicator with an outcome indicator — shorter turnaround time, fewer follow-up questions, fewer errors, less manually redoing the same thing.

Don't forget to measure the costs the change brought too. Time spent learning and tuning, the champions' time, extra work created along the side. An improvement that saves two hours and eats three isn't an improvement — but without counting the costs, you'll never find that out. The tip Reporting upward: turning data into a story for leadership shows how to assemble those numbers into a message leadership will actually read, and how to prepare in advance for the uncomfortable questions.

What happens the day after launch

The quietest moment of the whole rollout arrives the moment the change gets declared done. The project group disbands, the champion goes back to their own work, statuses stop getting written. And from that point on, nobody's holding onto the improvement anymore.

The first thing to establish is an owner. A specific name, not a department. The person accountable for the procedure still holding up and making sense: fixes it when something breaks, decides on exceptions, updates the documentation when circumstances change, and trains new people. Without an owner, every improvement's lifespan runs exactly until the next major change in circumstances — a new system at a supplier, different legislation, a key person leaving.

The second thing is a regular review. A quarterly rhythm works well: long enough that there's something to evaluate, short enough to still catch problems in time. The review doesn't need to be long — half an hour over three questions is enough. Is it still being used? Have exceptions or workarounds come up that deserve attention? Is there a reason to adjust or end the procedure? That last question is the one most often skipped, even though it's the most valuable — processes pile up at companies because nobody has the mandate to cancel them. Retrospectives, covered in the chapter Team productivity, and quarterly OKR cycles from the chapter Scrum, Kanban, and OKR address this systematically — if you already have one of those rhythms, attach the improvement review to it instead of creating another meeting.

The third thing is onboarding. A new person learns how things are done from the colleague sitting next to them — and if that colleague isn't working the new way, the new person learns the old procedure. This is the quiet channel through which changes creep back. That's why the new procedure has to be part of onboarding from day one, not an addendum for people who were around when it happened.

When to stop a change and admit it didn't pay off

Not every improvement is an improvement. Some were a good idea in theory and don't work in a specific company's reality — because the volume of work is smaller than expected, because there are more exceptions than rules, because the tool needs more upkeep than it saves, because the brief changed. That's not a failure, that's the result of an experiment. The failure is letting something like that keep running because you've already invested in it.

The strongest defense against sunk-cost thinking is a decision made in advance: a criterion and a date set at the beginning, before anyone's reputation is riding on it. Without that, you end up deciding in a situation where "stopping" means admitting that six months of work and paid licenses were wasted — and in that situation, people predictably decide badly.

You can stop with dignity, salvaging whatever has value in the process. Write up what you found: what specifically didn't work and why, what still holds true, which pieces proved useful and can be reused elsewhere. Thank the people who got involved — if the volunteers from the pilot learn their time was wasted, nobody will sign up next time, and that hurts even the changes that would have worked. And announce it out loud. An improvement that never got formally closed out keeps haunting the organization as a half-followed procedure someone occasionally attends to and nobody's accountable for.

One question is worth asking even about changes that did pan out: could we introduce this again today if it disappeared? If the answer is "no, only the person who left knew how," the change isn't actually established. It's just still working, for now.

Key takeaways

• Rollout and adoption are two different things. One has a date and a plan, the other can only be observed and supported. Companies measure the first and think they're measuring the second.
• Improvements most often die because of people, not technology — a single enthusiast leaving, leadership's impatience, an unspoken fear about one's own role, a tool with no agreed process, training with no follow-up support.
• A pilot with no predetermined criterion and decision date isn't an experiment, it's a postponement. A narrow scope, volunteers, a measured baseline, and recorded snags give you more than a blind company-wide rollout.
• Speak concretely, and about the uncomfortable stuff too. The sentence "nothing's changing for you" is almost always false, and it costs you credibility for every change that follows.
• Theater metrics grow on their own. Licenses and trained headcount prove nothing; the share of real work done the new way, in week four, does — and honestly counting the costs of the change belongs alongside it.
• After launch, a change needs a named owner, a quarterly review, and a place in onboarding. Without that, its lifespan runs out at the next major change in circumstances.
• Knowing how to stop an improvement is part of knowing how to introduce one. Stop by the criterion agreed in advance, write up what you learned, and say it out loud.