Start with the work, not the tool
Introducing a scheduling system, an AI assistant or a shared project platform can look like a software change. For employees, it may also be a change in their job. A task that once required judgment might become a suggested action to review. A handoff between colleagues might disappear, while a new responsibility for checking errors takes its place. If a team discusses only features and training, it can miss these shifts.
Before deciding how jobs should change, ask employees to describe how work happens now. Where do requests arrive? Which steps require context that is not written down? What exceptions consume time? A simple map of tasks, decisions and handoffs gives everyone something concrete to examine. It also makes it easier to distinguish a genuine improvement from a tool that merely moves work to someone else.
Make participation part of the rollout
Employees need a way to influence the design before it is treated as settled. Invite people who perform the work, people who receive it and people who support the tool. Ask each group what should stay human-led, what could be simplified and where a proposed workflow might fail. Use paid work time for these conversations where possible, rather than relying on volunteers to identify problems after hours.
Participation should be specific enough to produce decisions. A team might review one common task and one difficult exception, then agree who enters information, who checks a result and who resolves a disagreement. Record the choices and the questions still open. Managers should explain which suggestions they can act on, which need further testing and which are constrained by requirements outside the team’s control. That feedback keeps consultation from becoming a box-ticking exercise.
Test the new job, not just the new workflow
Imagine a customer support team introducing a tool that drafts replies. A trial focused only on whether drafts are produced quickly would overlook much of the job. Employees may now spend more time checking tone, finding missing context and deciding when not to use a draft. They may also need clearer authority to edit or discard suggestions. The useful question is not simply, “Does the tool work?” It is, “Can people do good work with the responsibilities it creates?”
Try the redesigned process on a small range of realistic tasks, including unusual cases. Ask employees to note where they pause, repeat work or need help. Check whether the process remains usable for colleagues with different access needs, schedules or levels of familiarity with the tool. A pilot should leave room to change task assignments and guidance, not just fix technical faults.
Give people authority, support and a way to raise concerns
A job redesign should spell out decision rights. If a tool makes a recommendation, who can override it? If information is wrong, who corrects it? If a customer or colleague needs an explanation, who is responsible for giving one? Clear answers reduce the risk that employees are held accountable for outcomes they cannot control.
Training matters, but it cannot compensate for an unworkable process. Employees may need time to practise, examples of when the tool is unsuitable and a reliable route to report problems. Make that route safe to use: people should be able to flag errors, accessibility barriers or increased workload without having to prove that the whole project has failed. Review those reports alongside observations from managers and the people served by the team.
Keep redesign open after launch
The first version of a new job description is a working draft. As people use a tool, they discover tasks that were invisible during planning: checking inputs, maintaining shared information, helping colleagues and handling exceptions. Set a regular time to ask what has become easier, what has become harder and whether any work is falling between roles.
Close the loop by making small changes visible. Update guidance when a decision right changes, adjust workloads when checking tasks grow and tell employees what happened to the concerns they raised. Involving people does not mean every suggestion can be adopted. It means the people closest to the work have a meaningful part in shaping it, and that the organization remains willing to revise the job when experience shows the first design was incomplete.
