Treat resistance as information before treating it as a problem. Ask what is making the work harder and what employees are concerned they may lose. Then separate practical flaws from concerns about control, expertise, responsibility, or job security. Explain what will change, what will stay the same, and what employees can still influence.
Do not promise to act on every objection. Investigate each one, make a decision, and explain the outcome.
Find out what is behind the objection
Employees often see operational details that are difficult to spot from a management position. A new system or process may create duplicate work, omit an important step, make responsibility unclear, or fail when an unusual case appears.
Other objections may concern a possible loss of control, competence, status, certainty, or job security.
For example, an employee may manage customer requests in a personal spreadsheet. They might understand why the company needs a shared system but still worry about closer oversight or losing an area in which colleagues see them as the expert.
These concerns can overlap. A complaint about a fixed approval sequence may reveal a real problem with urgent orders. It may also reflect concern about reduced autonomy. Both points affect how the process will work in practice.
Before describing someone as resistant, ask what useful information their objection contains.
| What you hear | What may be behind it | What to ask next |
|---|---|---|
| “The old way works fine.” | The new process may miss an exception, or the employee may trust a familiar workaround. | “Which situations can the current method handle that the new one cannot?” |
| “This will create more work.” | The change may add duplicate entry, approvals, or reporting. | “Which task will take more effort, and where is that effort added?” |
| “Nobody asked us.” | Operational knowledge may have been overlooked, or employees may feel they have lost control. | “Which decisions need input from your role?” |
| “Customers will not accept this.” | There may be a customer requirement, an unusual case, or uncertainty about new questions. | “Which customer situation are you concerned about?” |
| “The system will replace my job.” | The employee may be uncertain about future tasks, responsibilities, or job security. | “Which part of your role do you expect to change or disappear?” |
Two questions are useful in most discussions:
What makes your work harder?
What are you concerned you may lose?
The first question uncovers operational obstacles. The second helps you discuss control, expertise, responsibilities, and security.
Explain the effect on each role
Telling employees that a process will be simpler is not enough. Management and employees may mean different things by “simpler.”
You may see fewer handovers, more consistent data, and clearer reporting. An employee may see more required fields, less freedom to handle exceptions, or greater visibility of every decision.
Consider an automated approval process. Management sees one shared queue instead of requests scattered across email. An employee who previously chose whom to contact and when may see a fixed sequence that delays urgent cases. The process may be simpler for the company while making one role more restrictive.
Replace general promises with clear answers:
Which tasks will stop, start, or change?
Who will make each decision?
What information will be visible, and to whom?
How will urgent cases and valid exceptions be handled?
What should employees do if the process fails during rollout?
Which parts are fixed, and which parts can employees influence?
Clear answers will not remove every concern. They will help employees understand the effect on their work and raise issues that you can investigate.
Involve employees before rollout
Start with the work itself, not with a request to approve a finished proposal. People who use a process every day often know about dependencies, exceptions, and informal workarounds that do not appear in its official description.
Use a focused process before rollout:
State the reason for the change. Name the operational problem, such as repeated data entry, unclear order status, or delays caused by email approvals.
Define the boundaries. Explain what has already been decided and what remains open. Do not invite input on a decision that is closed.
Walk through real cases. Follow an order, invoice, request, or customer case from beginning to end. Note where employees leave the official process and ask why.
Find the exceptions. Ask about urgent work, missing information, unusual customers, temporary substitutions, and decisions that depend on one person’s knowledge.
Test with different roles. Include people who enter information, approve work, correct mistakes, and deal with customers when something goes wrong.
Involvement does not mean that everyone decides everything. It means that decision-makers have access to the operational knowledge they need.
Ask for feedback about real situations
After rollout, do not ask only, “Do you like the new process?” The answer gives you an opinion but little evidence you can act on.
Ask about recent tasks instead:
Which task now takes more effort?
Where do you still work around the process?
What information was missing when you needed to make a decision?
Which case could not be completed without help?
Where was responsibility unclear?
What mistake is easier to make now?
Compare what employees expected with what actually happened. “Approvals are slow” is difficult to investigate. “Urgent replacement orders wait because only one manager can approve them” identifies the situation, the constraint, and a possible owner.
Separate temporary learning difficulties from persistent obstacles. A task may take longer at first because the sequence is unfamiliar. Better instructions or training may solve that. Training will not fix duplicate entry, missing information, or a valid case that the process cannot handle.
Classify feedback before deciding what to change
Place each feedback item into one of four groups:
Error or obstacle: The process blocks valid work, creates duplication, or increases the risk of an important mistake.
Missing information or training: The process can work, but employees lack the instructions or information they need.
Valid exception: The standard process works, but a legitimate situation needs an alternative route.
Personal preference: Someone prefers a different order, layout, or method, but the current choice still allows the work to be completed safely and correctly.
For each item, record an owner, the next action, and how employees will hear the outcome. Use a simple cycle: listen, classify, respond, and review.
You do not need to redesign the process around every preference. You do need to explain what will change, what will not, and why. If employees provide feedback but never hear what happened to it, future requests for their input will look like a formality.
Frequently asked questions
What if employees simply prefer the old process?
Ask whether the preference affects accuracy, workload, customers, safety, or the ability to complete the task. If it has no significant effect, acknowledge the preference and explain why the chosen process will remain.
Should employees be involved if the main decision has already been made?
Yes, but be precise about what they can influence. Employees can identify exceptions, test instructions, improve the rollout, and clarify how individual roles will work. Do not present this as shared decision-making if the central decision is closed.
How should managers discuss fear of job loss?
Explain what is known about changes to tasks, responsibilities, and decision authority. Be equally clear about what remains undecided. Avoid vague reassurance. If roles may change, employees need accurate information and a clear way to find out what happens next.
How long should focused rollout feedback continue?
For a frequently used process, two to four weeks can be a practical starting point. The appropriate period depends on how often the process is used and how serious an untested error could be. Keep the feedback route open longer when tasks happen less often, important exceptions remain untested, or mistakes could have serious consequences. After the initial period, include feedback in regular process reviews.