A System’s Best Feature Can Be Someone’s Worst Incentive
Before asking who benefits from a system, ask what its success will take away — and from whom.
A feature can be good for the organization and still threaten the people expected to use it. It may reduce someone’s discretion, remove a team’s gatekeeping role, redirect a budget, or make previously private performance visible. Resistance is therefore not always a failure to understand the technology. Sometimes it is an accurate reading of the future the technology creates. An adoption plan should map those losses as carefully as it maps the benefits.
The proposal is approved. The implementation is sound. The new process is easier to define and easier to measure than the old one. Yet the people closest to it ask for another month with the previous process, question data they accepted yesterday, and propose an approval step the project was designed to remove.
The convenient explanation is that people dislike change. Sometimes they do. But that answer ends the investigation exactly where it should begin.
People do not reject a system in the abstract. They reject the future it predicts for them.
A feature changes power, not only workflow
Imagine a dashboard that shows managers every delay in real time. The organizational benefit is obvious. But visibility is not neutral. Yesterday, a team leader could decide when to escalate a delay, explain the circumstances first, and choose when the number travelled upward. Today, the number arrives before the explanation.
The leader’s responsibilities have not changed on paper. Their discretion has. The organization calls that transparency; the person experiencing it may call it judgment without context.
The same pattern appears elsewhere. A self-service portal shortens customer waiting time while removing a department’s control over intake. Automated allocation improves utilization while reducing a manager’s ability to reward people with desirable work. Standard pricing protects margin while limiting a salesperson’s ability to rescue a difficult account.
Resistance often arrives as product criticism
Few people will say, “This makes my judgment less valuable” or “My team loses authority if everyone can do this themselves.” Those concerns are legitimate, but they sound self-interested in a project meeting. So they surface in safer language: security, edge cases, data quality, customer preference, or process integrity.
Some of those objections will be correct. Incentives do not change the evidence, but they do change how people weigh it. Project teams usually make one of two mistakes: they reshape the product around every objection, or they dismiss every objection as politics. The harder task is to fix the real flaw and then ask what the corrected feature still takes away.
This is also why the quiet technical voice in the room matters. A warning may contain both a genuine engineering risk and an unspoken change in status. You need to hear both without confusing them.
A stakeholder map is not a loss map
Most plans identify users, approvers, administrators, and beneficiaries. That is necessary but incomplete. The same person can benefit from the new system and lose something because of the transition.
A loss map asks different questions. Who controls information today? Who can make exceptions? Whose expertise becomes easy to copy? Which team owns the budget now, and which team owns it after launch? Who becomes measurable for the first time? Who inherits the work when automation reaches an edge case?
These questions do not prove the project should stop. They reveal when training will not be enough. They also prepare your champion for the internal decision meeting where adoption is really decided.
Do not hide a transfer of power inside the word “improvement.” People can negotiate an honest change. They can only defend themselves against a disguised one.
If someone is still rewarded for the old behavior, asking them to adopt the new one is asking them to lose twice.
When an expert transfers knowledge into a system, involve that expert in defining rules, handling exceptions, and improving the model.
Extra approvals and shadow spreadsheets are not random noise. They show where the organization is rebuilding discretion that the product removed.
When people resist something that appears useful, do not stop at “Why are they resisting?” Ask what becomes harder for them if it works.
The answer may be control, status, safety, earning power, or simply the right to explain yourself before being judged. You may still implement the feature. You will implement it more honestly.