The People Who Plan the Change Are Not the Ones Who Absorb It

The people who have to live with it often get an email.

That difference costs more than most leaders realize.

Picture this constructed example. A company replaces its old scheduling system. The leadership team sees a demo, asks questions, and agrees it will save time. They have weeks to discuss how it will work.

The night crew learns about it shortly before the switch. Their lead has to keep the work moving, learn the new screen, explain it to everyone else, and answer customers who still expect the old process to work.

The new system might be better. Nobody has shown the night crew how to survive the first week.

When the new screen slows the work, somebody calls it resistance.

It may be poor planning.

THE CHANGE WAS GOOD ON PAPER

A business has every right to improve the way it operates. It needs to. Old methods get expensive. Customers expect better service. Technology changes. Work that used to make sense stops making sense.

But a business decision does not become a workable plan just because somebody approved it.

The people who built the plan know where the answers are. They saw the demonstration. They met the supplier. They debated the risks. They had time to imagine the new work.

The people who receive the plan have none of that history. They get the instruction and all the work that comes with it.

Think about a school changing how parents schedule conferences. The office staff now handles questions from families who cannot log in. Teachers work around double bookings. Parents try to figure out which messages matter.

Or a small shop changing how customers place orders. The owner likes the new website. The person answering the phone has to explain why an order disappeared between the website and the counter.

A shop owner might ask: What will this do to Tuesday morning?

Different workplaces. Same mistake. A plan can be good for the business and still be poorly introduced to the people doing the work.

The question is not whether change is necessary.

The question is who has to carry it, and whether you helped them.

WHAT THE RESEARCH CAN AND CANNOT TELL US

Edelman’s 2026 Trust at Work study surveyed 10,018 employees in ten countries between August 14 and August 31, 2026. The company reported that employees were experiencing frequent workplace changes and that their experience of those changes differed by job level.

Among employees who had experienced change, 49% of associates described their experience as less than positive, compared with 17% of executives. The report also found lower trust in managers among employees whose change experience was negative than among those whose experience was positive.

Employees report worse trust during a period of heavy workplace change. The survey does not prove what caused the decline.

Those are survey relationships. They do not prove that one badly handled rollout caused a particular employee to lose trust. They do not prove that every executive had an easy time or every worker suffered.

They are a reason to ask a better question: are the people planning the change and the people doing the changed work having the same experience?

The only useful answer comes from the people who will do it.

A leader who never asks them is guessing.

THE MISTAKE IS IN THE HANDOFF

We make a presentation about benefits and call it communication.

We send the instructions and call it training.

We pick a launch date and call it a plan.

Then the first shift starts, the phones ring, and the person closest to the work starts improvising.

Maybe the new screen needs an access code that the evening team does not have. Maybe the approved instruction tells people how to start an order but not what to do when the customer changes it. Maybe the new process saves time in one department by pushing extra work onto another.

These are not mysterious failures. They are questions nobody carried to the people who would have to answer them.

The planners may have missed the first-week burden because they had not walked the change with the shift lead.

A leader often sees a finished project when the system goes live. The person doing the work sees a project that just started.

That is the gap you have to close.

A CONSTRUCTED EXAMPLE: THE FIRST WEEK

Go back to the new scheduling system.

In the original plan, the change goes live Monday. Everyone receives instructions. A manager checks whether the system is working. If the screen opens, the project looks complete.

Now run the same change through the people who will carry it.

Before Monday, the owner of the change asks the night crew to walk through a real request. The person who handles the first call opens the new system and tries to finish the job without hints.

They discover that a common change of appointment has no clear instruction. They also learn that only the day crew knows who can correct a booking after hours.

That is useful information. Nobody failed the test. The plan did.

The owner gives the team a written route for the common change. The night crew practices it. The owner names a backup who can handle an after-hours exception and tells the team how to reach that person.

The team also agrees on what to do if the new system cannot process a request. Nobody invents a workaround, changes access, or bypasses a control. The owner decides whether to hold the request, use an approved fallback, or stop the transition until the problem is fixed.

On Monday, the team knows who answers the phone, who owns the exception, and how to tell a customer what happens next.

On Tuesday, the owner asks which step took longer than expected. A problem with the handoff gets corrected before the next shift repeats it.

By Friday, they can answer a better question than ‘Did we launch?’

They can answer ‘Can the people doing the work use it without somebody rescuing them?’

That is a different definition of finished.

Notice what did not happen. Nobody abandoned the improvement. Nobody demanded that every person like it. Leadership kept the decision and accepted responsibility for making it workable.

THE COST YOU DON’T SEE IN THE PROJECT PLAN

The obvious cost is training time. The less obvious cost is the work that training pushes aside.

When a lead teaches the new process, somebody else has to cover the lead’s usual work. If the person learns while serving customers, customers carry part of the cost. If questions only get answered during the day, the night crew waits or guesses.

Time does not disappear because the budget did not name it.

There is also the cost of a broken promise.

Tell people that a new system will make their work easier, then leave them alone with a mess, and your next announcement has less weight. They remember what the last promise felt like, not what the slide said.

You do not repair that with a motivational speech.

You repair it by showing that you saw the burden, corrected what you could, and told the truth about what remained.

THE WHO-CARRIES-IT WALK

Before you approve the next change, find the people who will absorb its first week. Not only the manager who requested it. Include somebody who does the actual work, somebody who receives that work next, and somebody who handles it when the usual owner is gone.

Ask them to walk one real job from start to finish using the proposed process.

Do not begin by explaining why the change is good. You can explain that afterward.

Begin with questions they can answer from experience.

What will you do differently?
What information or access will you need?
Which part of your normal work stops while you learn this?
Who gets the work if you are busy?
What happens when the expected step fails?
Who owns the correction, and how will you reach them?
What would prove this works without making somebody else’s job worse?

Write the answers where the plan lives.

If the change is small, the record can be small. A page is enough. Name the owner, the people affected, the first test, the fallback, and the evidence that will tell you whether the change helped.

A long document with no owner does not solve this problem.

Neither does an enthusiastic meeting.

ONE PROBLEM, ONE OWNER

Say the test reveals three gaps. The afternoon staff understands the new screen, but the evening staff cannot reach the exception owner. The receiving team also needs a piece of information the first team does not capture.

Do not announce that ‘everyone should communicate better.’

Name the missing handoff. Decide who owns the information. Make sure the next team knows where to find it. Test the same request again.

If a fix needs authority the frontline worker does not have, the owner carries it to the person who does. You do not put the worker in the position of choosing between serving the customer and breaking a control.

Leadership is not doing every job for people.

It is making sure people can do the jobs they were given.

WHEN THE CHANGE CANNOT WAIT

Sometimes a change must happen now. A broken system, a customer need, or a serious risk does not wait for a perfect rollout.

Then be clear about what is known and what is not.

Name the temporary method, the person who owns it, the limit of that method, and when the team will review it. Explain which safeguards still apply. Give people one place to report what fails. If something falls outside their authority, give them a real route to the owner.

An urgent change is a reason to simplify the handoff, not skip it.

And sometimes the change will be unpopular because it makes someone’s work harder. That does not automatically make the decision wrong. It does mean leadership should stop pretending everybody wins immediately.

The people doing the work deserve the reason, the support, and an honest account of what the first days will look like.

WHAT EACH PERSON CAN DO

If you are an employee, ask what is expected to change in your work, who owns the missing instructions, and where you report a problem. Show the exact handoff that fails. Do not take an unauthorized shortcut to make the numbers look better.

If you lead a team, put one person who will perform the new work into the test before launch. Cover the time it takes to learn. Check the next shift, not just the first one.

If you own the business or lead the company, ask to see one completed real-world example, including the exception. Do not settle for a demo run by someone who already knows every screen. Ask whose regular work was covered during training and how the next team will know what to do.

The higher you sit, the less likely you are to see the handoff break on its own.

Go look.

DO THIS ON YOUR NEXT SHIFT

Pick one change that is live or about to go live.

Find one person who has to use it and one person who receives the work afterward. Ask them to show you one ordinary job and one thing that goes wrong.

Write down the first missing instruction, access step, owner, or handoff. Give it to the person with the authority to fix it. Agree on when both people will try the same job again.

Then return and see whether the work got easier or whether the burden simply moved.

A new process is not successful because the people who designed it can explain it.

It is successful when the people who have to use it can make it work.

Source: Edelman, 2026 Trust Barometer Special Report: Trust at Work, fieldwork August 14-31, 2026, 10,018 employees across ten countries. https://www.edelman.com/trust/2026/trust-barometer/special-report-work. The cited figures describe associations in a survey, not proof of cause. The scheduling-system case and other workplace examples above are constructed to teach the method; they are not personal experiences attributed to Marc.