An example I made up. The numbers and dates in it are illustrative.
Rizwan Ahmed runs order processing for a regional distributor of building materials. Head office is in Singapore. His team of 14 sits in Kuala Lumpur, and today they take orders by email and track them in spreadsheets. Rizwan has decided to move them to a new order system, and he's given the project ten weeks to go live.
He asks WoodcreeperAI to draft the rollout plan. It comes back tidy and sure of itself: "Announce the change one week before go-live and train the team in the week after it. Based on the project timeline and the training team's calendar. I am 80 percent sure." Under risks, the plan puts "staff resistance" at the top.
The plan suits the schedule. Rizwan isn't sure it suits the people. Before he approves it, he asks the HR partner and two of the longest-serving members of the team what people will need, and when.
They tell him two things he hadn't seen. The system supplier's team will be on site before any announcement, so people will hear about the change from them first. And people want to learn the new system before it goes live, not in the week after, when real orders are already waiting.
So Rizwan decides differently. Before he speaks to the team, he tells his own manager (the regional chief operating officer) and the HR partner what he's decided and why. Eight weeks before go-live, he tells the whole team in person. He gives them the reason for the change. He tells each role what changes for them and what stays the same. He says what he doesn't yet know, and the date by which he will. Training moves to before go-live, and go-live moves two weeks later than the ten weeks he first set. He names one person, a team lead, to answer questions.
Three months later, nobody on the team had first heard about the change from the supplier's team. The first week on the new system was still slow, and Rizwan said so. Two people asked to move to the team that answers suppliers' questions, and they did.
WoodcreeperAI wasn't wrong about the calendar. It timed the telling for the least disruption to the schedule. It put "staff resistance" at the top of the risks, when what people needed was to hear it first and to learn before go-live. Rizwan still had to decide what his people were owed, and when they needed it.
Why this question matters to me
At twenty-nine, I delivered 241 per cent growth at Electrolux, and I was dismissed within the year. That's my own account of it, and it's why I think hard about what a leader owes people who must carry out a change.
What a leader owes, and when
When you decide a change, you decide it for other people as well as for yourself. Here's what I think they're owed. Notice that every one of these is owed before go-live, and most of them weeks before.
They're owed the reason, and they should hear it from you first. They shouldn't hear it first from the supplier's team or from an email. People can carry out a change they don't agree with. It's far harder to carry out a change nobody has explained to them.
They're owed a plain account of what changes for each of them, and what doesn't. A team hears "new system" and each person imagines the worst for themselves. Go role by role. Say what stays the same as clearly as what's new, because people may most need to hear that part.
They're owed what you don't yet know, with the date by which you will. It's tempting to hold the announcement until every answer is ready. By then, people may have heard about it somewhere else. Say which part you can't answer yet, give the date you'll answer it by, and keep to that date.
They're owed time to learn before the change, not after it. Training in the week after go-live means people learn while real work is waiting for them. That's a costly time for mistakes, and people have little patience for them. If the schedule can't make room for learning first, it's the schedule that should move.
They're owed one named person to ask, from the day you tell them. "Ask the project team" doesn't help when nobody knows who the project team is. One name, with the time set aside to answer, means questions get asked instead of guessed at.
They're owed a hearing before the plan is fixed. Ask the people who'll carry out the change what they'll need, and ask while you can still act on what they tell you. In Rizwan's case, what two long-serving colleagues and an HR partner told him moved the announcement, the training and the go-live date. If you ask after the plan is approved, you can only listen. If you ask before, you can still change the plan.
What I won't claim
None of this is a method. Your organisation will have its own sequence for these things and its own words for them.
I still get this wrong, even knowing all of it.
And nobody can promise people that a change will be easy. Rizwan's team still had a slow first week. What a leader can promise is that people will hear it from them, in time to prepare.
I give keynotes, briefings and workshops on this.