Why Do Employees Resist a New Management System, and How Do You Address the Causes?

Is every objection resistance to change?

It is easy to label someone who is slow to use a new system as uncooperative, but the label does not explain the cause. The employee may be unable to complete the task because of missing permissions, may see a conflict between two procedures, or may not understand why the way of working changed. Ask what happens in the specific task before judging the person’s attitude to change.

Professional change management literature highlights the importance of context, involvement, communication and leadership in successful transformation. That does not mean every objection is right or that every employee can stop the project; the point is that management decisions improve when they distinguish a fixable problem from deliberate non-compliance with clear instructions. “Resistance” must not become a way to silence an important professional observation. ^[1]

Which questions reveal the real cause?

Ask the employee to carry out a common task in front of a member of the project team, in a suitable test environment. Ask where they got stuck, what information they were missing, and how they used to do the task. Watch for repeated steps, switching between systems and approval requests. An open interview reveals important concerns, while watching the task helps verify the operational part of them.

Then separate the causes: Is what is required unclear? Is a skill missing? Is there not enough time or equipment? Do management incentives still reward the old way of working? Does the employee fear that mistakes made while learning will be used against them? This is an editorial diagnostic list, not a psychological test or a fixed label for people. Keep the notes as work problems that can be solved, without collecting personal details the project does not need.

When is training the answer, and when is it not?

If the employee knows the goal but not the steps, they may need short training tied to their task, with a chance to practise and review. If they know the steps but the system rejects their permissions, adding a lecture will not change the result. Training development standards stress verifying that a gap can be closed by training, rather than treating training as the automatic response to every performance weakness. ^[2]

Design support by role. An approver needs to understand approval decisions and exceptions, while the person processing a transaction needs correct data entry and document checks. Do not put everyone through a long walkthrough of every screen when most of them are irrelevant to their work. After training, provide a short reference and on-the-job support, and update it whenever the interface or procedures change, so people do not learn from conflicting versions.

How do you handle fear of losing expertise or status?

An employee may have deep expertise in the old procedures and feel that the new system reduces their importance or exposes past mistakes. Do not answer that with a general statement about the need to move with the times. Recognise the value of their operational knowledge, and involve them in testing and documenting exceptional cases. Useful involvement gives them a defined role, while the project team keeps responsibility for design and decisions.

At the same time, do not promise staff job outcomes that management has not approved. If the transformation will change how roles are allocated, explain what has been decided, what is still under study and who answers questions. Uncertainty feeds guesswork and rumours. Honest communication helps build realistic expectations; over-reassuring people and then backtracking weakens trust in the project’s next messages. ^{[1, 3]}

What is the line manager’s role after launch?

In practice, the manager decides which way of working is rewarded. If they ask for the system to be used but keep accepting only the old reports, or routinely handle exceptions outside it, the team will see the change as cosmetic. The manager should use the new outputs in follow-up, set aside time for learning, and remove conflicts between daily production targets and temporary transition requirements.

That does not mean open-ended leniency. Set a reasonable transition date based on operational readiness, and explain the exception route and when it ends. When a mistake recurs, first check that the procedure is clear and that the skill and capacity to do it are there. If these conditions are met and non-compliance continues, it is handled under the approved performance policy. Separating diagnosis from accountability makes the decision fairer and easier to explain to both the employee and management.

How would this work in a hypothetical Gulf organisation?

A hypothetical service organisation moves from email requests to an approvals platform. Delayed transactions appear, and someone proposes retraining the staff. A review of a sample of transactions shows that some requests wait for an approver who is not assigned during leave, and that staff re-enter data that already exists in another system. This is a teaching case and does not represent the results of a real project or an assessment of any particular platform.

The team fixes approval delegation, reviews the required fields, then trains users on the corrected route. Follow-up is then measured by completed transactions, data quality and reasons for delay, not just the number of logins. If usage improves, success is not automatically credited to training; changes to permissions, procedure and support also contributed. Documenting these factors protects management from a simplistic conclusion that gets repeated on the next project.

How do you take the Gulf work environment into account?

Organisations with multilingual teams need to explain terms and instructions in a language users understand, while keeping the required official version. Shift work, branches, and the permissions of employees and contractors also need to be considered. Do not assume that one announcement reaches people who work away from the office or at different times; check that the message arrives and is understood for each group.

In government or regulated organisations, review the system’s effect on authorities, records, document retention and privacy. A mandatory step is not cut just to speed up use, and real data is not moved into a test environment without controls. It is good practice to make user experience part of acceptance testing, so that representatives of the key roles complete their real tasks before the system is rolled out to everyone.

How do you know the change has taken hold?

Define evidence tied to the work: transactions completed in the approved way, less unnecessary re-entry, a clear exception route, and staff able to resolve routine cases themselves. These are suggested indicators from which the team picks what suits it. Do not treat the disappearance of complaints alone as a sign of success; it may mean users have stopped reporting or gone back to channels outside the system.

How do you run an obstacle log without blaming individuals?

Describe the obstacle in terms of the task: a request could not be approved while the approver was absent, a field was unclear, or two instructions conflicted. Then record its impact, route and the person responsible for resolving it. Avoid phrases like “the employee doesn’t understand”; they do not help the process owner know what to change. Link each report to an example with unnecessary data removed, so the problem is clear without exposing customer information.

Classify the response as a technical change, a procedural clarification, training or a management decision. An obstacle may need more than one response, but having a coordinator prevents it getting lost between teams. Tell the person who reported it what was decided, and test the fix with them where appropriate. Getting a reply encourages people to report work problems instead of turning to unofficial channels.

In reviews, compare open and closed obstacles and the reasons they recur. More reports at the start may reflect better reporting, not a worse system. Do not set a target simply to close them quickly, or the team may close a problem on paper only to see it return. What matters is that users can complete the correct task and know where to get help. When a fix works, update the guide and the training so the correction does not remain knowledge held by a few people, then review similar cases that may face the same problem in other branches or roles.