# New system adoption: the line manager decides > Whether a team adopts a new system is decided by the line manager of the people who operate it. What Gallup and Prosci show, and how to design for it. - Author: Marlon Trettin - Published: 2026-10-23 ยท Updated: 2026-10-23 - Language: en - Canonical: https://yowpi.com/en/blog/line-manager-decides-system-adoption --- Whether your team adopts a new system is decided by the line manager of the people who operate it, not by the project sponsor or the innovation team. The manager defines what counts as finished work and what gets asked for in Monday's meeting. If their report still comes from the spreadsheet, the team keeps feeding the spreadsheet. ## TL;DR - [Gallup](https://www.gallup.com/workplace/713033/managers-and-team-productivity.aspx) attributes 70% of the variance in team engagement to managers. Engagement is not adoption, but it shows where influence sits. - In a [Gallup survey](https://gallup.com/workplace/694682/manager-support-drives-employee-adoption.aspx) of 19,043 US workers, only 28% of employees in organizations already implementing AI strongly agreed their manager actively supports their team's use of it. - In [Prosci](https://www.prosci.com/resources/articles/change-management-best-practices) research, 43% of participants name mid-level managers as the most resistant group, and 58% of employees prefer to hear about personal impact from their own supervisor. - The fix is a design decision: the new system has to give the manager the view they rely on today, and the weekly meeting has to run on it. ## Why does the line manager weigh more than the sponsor? Because the manager is there at the moment an operator chooses between the new system and the old route. The sponsor sets the priority once. The line manager confirms or undoes it every day, through the questions they ask, the report they request and the shortcut they tolerate. That does not make sponsorship irrelevant. In Prosci's benchmarking, projects with an extremely effective sponsor met their objectives 79% of the time, against 27% with an extremely ineffective one. But Prosci sells change management consulting and training, so read its numbers as research from a party with an interest in the topic. What it shows is that sponsorship opens the door. What happens after that is decided by the person who lives with the team. For you, as an innovation lead, this is uncomfortable. You usually have no line authority over the people who operate. You answer for the result of an adoption that depends on people who do not report to you. ## What does the data say about the manager's role? It says the line manager concentrates influence over the team, and that many managers are not prepared for that role when change arrives. The data has limits, so here they are first. Gallup states that managers account for 70% of the variance in team engagement. That figure comes from engagement research, not system adoption. Treat it as a sign of weight, not a forecast for your project. The closest data to our subject is a Gallup survey from May 2025 of 19,043 US working adults. Among employees in organizations that had started implementing AI, 28% strongly agreed that their manager actively supports their team's use of the technology. Those who agreed were 2.1 times as likely to use AI a few times a week or more, and 6.5 times as likely to find the tools useful for their work. Gallup does not claim causation, and the scope is AI in the US, not an internal system at a mid-sized company. Still, the pattern is easy to recognize: manager support shows up together with use. Then there is preparation. According to Gallup, 44% of managers worldwide have ever received management training. In Prosci's research, 43% of participants name mid-level managers as the group most resistant to change, and 58% of employees prefer to hear about the personal impact of a change from their own supervisor. Without preparation and without ownership of the change, a manager tends to protect the team's routine, and from their side that is reasonable. That is our reading, not a result of the studies. ## Where does adoption break when the manager does not own it? It breaks at three points that projects usually leave out of scope: the report the manager uses, the meeting they run and the old route they tolerate. The first is the report. If the system was designed for whoever enters the data and not for whoever demands the result, the manager keeps asking for their spreadsheet. The operator enters data in the system to satisfy the process and in the spreadsheet to satisfy the manager. The second task is the one done carefully. The second is the meeting. While Monday's agenda comes from another file, the new system is a parallel register, not the place where the operation is discussed. The third is the old route. If it keeps working, someone will use it under pressure. This pattern appears in [why your team isn't adopting the new system](/en/blog/why-your-team-isnt-adopting-the-new-system), and measuring real use, which shows which teams went back to the old way, is covered in [system adoption: why go-live is not the end](/en/blog/system-adoption-why-go-live-is-not-the-end). In all three, the defect is architectural. The system serves the operator's flow and ignores the manager's control flow. In the [Reatop case](/en/cases/reatop), for example, the native mobile app with offline use was designed for people who work in the field and connects to an integrated back office. Adoption depends on both sides being designed together. ## A practical example: the 8:30 spreadsheet The scenario below is hypothetical, and the numbers are illustrative assumptions, not measurements. A distributor with 80 people rolls out an order system. Dispatch has 12 operators and one supervisor. Before the system, the supervisor received a spreadsheet at 8:30 with the previous day's shipments and ran the meeting with the leadership team from it. The system goes live in March. Operators are trained and enter orders in it. The supervisor, however, keeps asking for the spreadsheet at 8:30, because the system screen does not show pending orders by route, which is what the meeting needs. In April, 3 of the 12 operators still keep the spreadsheet, just in case. The project reports adoption at 100% because the entries exist. The supervisor, who needs the 9:00 meeting ready, knows the real number is different. Now the same scenario with the supervisor as owner. Before go-live, the implementation team asks what the supervisor shows in the meeting and builds that view in the system, with pending orders by route. The meeting runs on the screen. The spreadsheet gets a shutdown date, agreed with the supervisor and not imposed on them. Operators no longer maintain two sources, because the person who asks for the data stopped using the old one. ## How do you give the line manager ownership of the change? In four moves, all before go-live. First, map the manager's control routine: which report they consult, at what time, for which meeting. That map defines part of the scope. It is not a training add-on. Second, deliver their view ready in the system. If they have to build alone what the spreadsheet gave them for free, the old route wins. Third, move the meeting agenda. The weekly discussion happens with the system open, and what is not in it does not make the agenda. That costs a conversation with the manager, not a project. Fourth, set the shutdown date of the old route together with them and track use per team, not only in total. Total use hides the team that went back to the spreadsheet. ## Frequently asked questions **My team does not accept change. How do I convince the manager it is worth the effort?** Show them what they gain: the view they rely on today, ready, without building a spreadsheet every Monday. A manager's resistance is usually protection of the team's routine, and it fades when the change hands them something they already use. Persuading by speech yields less than designing around use. **The implementation will take too much of my team's time. Doesn't involving the manager slow things down?** It slows things a little at the start and saves time later. The conversation to map the control routine takes hours, while running two routes for months consumes operator and manager time every day. The time you spend upfront is smaller than the cost of keeping the spreadsheet alive. **I worry the system will not remove the real bottlenecks. What does the manager change?** What gets seen. If the meeting runs on the system, pending items, delays and exceptions become visible to people who can act on them. A bottleneck that only shows up in the supervisor's spreadsheet reaches neither leadership nor the process, and the system becomes a register nobody consults. ## The next step If you want to understand where your line managers' control routine still depends on a route the new system does not cover, the Operational Architecture Diagnostic, a 30-minute conversation, is an invitation to start: [talk to Yowpi](/en/contact).