Changes in the market, demand, technology or internal growth can force an organisation to adapt. Leaders need to make that change understandable and workable: explain the reason, describe the effects and give the team time and support to work differently.
The role of the manager
During change, the way in which leadership is given and the associated communication is crucial for the result. An important role has been laid here for management functions, which have a group of people to supervise. First everyone needs to understand the importance of the change before the new way of working is accepted and adopted. The manager’s role is to create a good working environment and get his team used to the new tasks. He then has to create clear guidelines and give direction to achieve the new goals.
The reactions of employees
Employees may react differently to changes. To a large extent this also depends on the company’s corporate and organizational culture. Some of the questions that determine the response of employees are: How much change will there be?’, ‘What will happen to my position?’ and ‘ Am I going forward or backward on this? It is important to answer these doubts and questions as well as possible, so that people know what is decided, what remains uncertain and where they can raise concerns.
Execution and coaching
A smart manager chooses a number of stakeholders who will execute the change within the team. Think carefully about who you are going to give these key roles to. The tailor-made plan to implement the change will be executed by these key people. The manager monitors the whole process and sets a good example. It is also the role of the manager to continuously coach everyone, especially the staff who have been given other work thanks to the change.
Make the change measurable
Translate the initiative into observable steps: what changes, for whom, by when and with what support. Create a channel for questions, name an owner for each decision and track a few useful signals such as adoption, errors and workload. Feedback must be able to change the plan.
Start with the work that will change
Explain the change through a task people recognise. If a team is moving to a shared customer system, show how an enquiry will arrive, who will assign it and where the reply will be recorded. A presentation about efficiency is less useful than seeing what happens on the first working day.
Write down what will stay the same as well. Staff need to distinguish a new process from a change in responsibility or authority. If a decision about roles is still pending, say who will make it and when an update is expected. Do not fill a gap with reassurance you cannot substantiate.
Give the team a way to influence implementation
Ask people who perform the work to identify likely failure points before the rollout. Include someone who handles exceptions, not only the easiest standard cases. Their experience can reveal a missing approval, a dependency on another department or a customer promise that the proposed process overlooks.
Separate decisions already made from choices that remain open. For example, the organisation may have selected the system but still need to decide the handover procedure. Be explicit about that boundary so consultation does not create a false expectation that every part of the project can be reversed.
Run a small pilot with a clear exit decision
Choose a limited set of real tasks and specify what would count as a workable result. Record the current error rate or turnaround time if it can be measured reliably. Then compare the pilot with that baseline, while noting differences in workload or case difficulty.
Give participants time to learn. If they must maintain the old process alongside the new one, account for the extra workload. Assign someone to resolve problems quickly and keep a short record of fixes that other teams will need when the change expands.
Support people after the announcement
Training should include practice and a route to help, not just a demonstration. Ask employees to complete a representative task and explain where they became stuck. Update the instructions when several people encounter the same problem rather than treating every request as an individual weakness.
Check in privately when a change affects someone’s confidence or duties. Listen for practical constraints before interpreting hesitation as resistance. A person may support the goal while lacking access, time or the information needed to carry it out.
Close the transition deliberately
Decide when the old procedure can stop and who approves that decision. Remove contradictory instructions and identify the owner of the new process. Otherwise the team may continue running two systems because nobody knows which one takes precedence.
Review the result after a useful working period. Ask whether the original problem has improved, which costs were overlooked and what still creates unnecessary work. Keep the lessons specific enough to reuse in the next change, including decisions that should have been made earlier.
