# Why your team isn't adopting the new internal system > Teams reject a system that was designed without the operation. Adoption is a result of architecture and involvement, not of training or pressure. - Author: Marlon Trettin - Published: 2026-07-09 · Updated: 2026-08-29 - Language: en - Canonical: https://yowpi.com/en/blog/why-your-team-isnt-adopting-the-new-system --- Teams fail to adopt a new system almost always for the same reason: it was designed without the operation. It is not resistance to change or a shortage of training. It is a system pushed down from above that does not fit the real work of the people meant to use it. Adoption is a result of architecture, not of persuasion. ## TL;DR - The success rate of large transformations has been stuck at 30% for years. When a company fails to involve line managers and frontline staff, only 3% of projects succeed, against 26% and 28% when those groups take part, according to [McKinsey](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations). - Involvement is not a presentation meeting. It means giving the people who run the process a real share of the decision. - Installing technology on top of a broken flow only automates the mess. Redesign comes before digitization, not after. - Resistance is information. It shows exactly where the system failed to fit. ## Why does the team reject the new system? In most cases it is not gratuitous resistance or discomfort with the tool. The rejection is a response to a system that arrives finished and does not speak to the way the work actually happens. Stopping at "the culture resists" is an incomplete diagnosis. Blaming culture becomes an excuse for more training and another memo, when the problem usually sits earlier than that. Nobody willingly adopts a tool that takes six clicks to do what the old spreadsheet solved in two. There is fear in the mix too, and it is worth naming rather than dismissing. When people suspect a system exists to measure them or to make their role redundant, no amount of training will produce enthusiasm. But fear is rarely the whole story, and treating it as the whole story lets a badly designed screen off the hook. ## Adoption is an architecture problem, not a persuasion problem When buy-in fails, the natural reaction is to invest in persuasion: training, internal comms, a memo from leadership. Rarely does anyone go back and ask whether the system was designed alongside the people who would use it. [McKinsey](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations) has been tracking that pattern for years. The success rate of large transformations sits at 30%. And the factor that most drags that number down has a name: when a company fails to involve line managers and frontline teams, only 3% of projects succeed, against 26% and 28% when those groups take part. Involvement is not a presentation meeting. It is giving whoever runs the process a real share of the decision. The other side of the same problem is redesign. Installing technology on top of a broken flow only automates the mess. Most companies digitize what already existed rather than redesigning the core process, and then wonder why the numbers did not move. Put the pieces together and the picture is clear. The system nobody uses is rarely a technology problem. It is an architecture problem: somebody designed the solution far from the operation and delivered it finished to people who were never consulted. You do not have an adoption problem. You have a problem with how the system was architected. ## What actually increases adoption? Treating adoption as part of the project, not as a campaign after delivery. Four decisions weigh more than any training: - Involve the people who operate it from the design stage. The person living the process knows the exceptions no flowchart captures. Bringing them to the table early prevents half the rejections at the end. - Redesign the flow before digitizing it. If the current process has steps that exist only out of habit, the system should not carry them. Automating waste is expensive, and nobody adopts it. - Have an owner on the line, not only in IT. A system with no owner in the operation becomes an orphan. The manager who sponsors the change day to day counts for more than a memo from leadership. - Start with a small, visible core. A pilot that solves a concrete pain proves the value without requiring faith. Everyone else's buy-in comes from the colleague at the next desk who already got time back, not from a slide. None of those decisions is about the tool. All of them are about architecture: who takes part, what gets redesigned, where you start and who sustains it. ## An example of how a company handles adoption Picture a mid-sized distributor, a hypothetical but common scenario. Leadership buys a new order system and, three months later, discovers that salespeople are still writing orders in a notebook and typing them up at night. The system exists. Adoption does not. The mistake was not the choice of tool. It was the design. Nobody sat with the salespeople before configuring the screens, so entering an order became eight mandatory fields for something a customer resolves in one sentence over chat. The tool ended up slower than the notebook, and the notebook won. The fix starts outside the software. Pick three salespeople to redesign the order screen based on how the conversation actually goes, cut the fields that change no decision, and run a pilot with one team before requiring the whole company to switch. When an order comes out faster in the system than on paper, adoption stops needing enforcement. The mechanism is the same in an operation of a thousand people: the scale changes, not the cause. That logic is what carried [Reatop's](/en/cases/reatop) app, used every day by collectors inside more than 15 hospitals. The app works offline, in basements with no signal, and was designed for field operations rather than for the boardroom. That is why paper left the collection points: the system fit the work. The same happened with [Nuleite](/en/cases/nuleite), adopted by farmers because the interface is simple enough to fit the routine of someone out in the field rather than in front of a computer. There is also the inverse case, where the system did everything it needed to and still got in the way. In the [control system for a public transport operation](/en/cases/stella-farias), the platform existed and worked, but the interface had stopped somewhere in the nineties, and a daily operation with traceability requirements cannot rest on a screen that slows down whoever uses it. The delivery was to redesign the experience and fix the accumulated defects while keeping the system. Interface is not finish: it decides whether the record happens on the spot or later, from memory. ## Frequently asked questions **My team doesn't accept change. How do I get around that?** Start by assuming part of the refusal is justified. Instead of persuading, ask where the new way gets in the way of the work and fix those points before requiring use. When the people who operate help design the change, resistance falls, because it stops being an imposition and becomes something they helped build. Involving the frontline is what separates the 3% of projects that fail from the ones that work, according to [McKinsey](https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/successful-transformations). **The implementation will take too much of the team's time. Is it worth it?** It takes time, and it pays for itself by saving time. The bigger risk is not the team stopping for a few hours to take part in the design. It is spending months on a system nobody uses. A small pilot, with one process, cuts that effort to a few weeks and shows the return before committing the whole operation. The cost of involving the team early is usually lower than the cost of redoing a rejected project. **I'm worried the system won't actually remove the bottlenecks. How do I reduce that risk?** The risk falls when you map the bottleneck before choosing the solution, not after. Installing technology over a broken process only accelerates the defect, which is why so many companies digitize without improving. Design the flow you want, validate it in a pilot, and only then scale. If the bottleneck persists after the pilot, it was a process bottleneck, and no software would have solved it alone. **I can't see how to measure the result. Where do I start?** Define the metric before the pilot, not after. Pick a number the operation already feels — cycle time per order, real usage rate of the system, rework per week — and compare the same indicator before and after the pilot. If the number does not move, the design is wrong, and you find that out in weeks rather than months. ## The next step If you already have the system but the team does not use it, the problem is probably not a shortage of training. It is the architecture of adoption. The [Operational Architecture Diagnostic](/en/contact) is a 30-minute conversation to understand why buy-in stalled and what to redesign so the system fits the real work.