Every failed migration I have watched started with a good document.
Someone senior, usually smart, usually right about the technical shape of the thing, went away for two weeks and came back with a plan. Diagrams. Phasing. A slide with a green arrow on it. Then they presented it to the people who would spend the next eighteen months living inside it, and those people nodded, and nothing happened.
Not open revolt. Nothing so useful as revolt. What you get instead is drag. Tickets stay open a day longer. Edge cases get discovered at a rate nobody has ever seen before. The old system keeps getting patched "for now". Eighteen months later somebody quietly writes a post-mortem blaming scope.
The scope was fine. You wrote the plan alone.
The plan was never the problem
I have been on both sides of this. I have been the engineer nodding at someone else's roadmap while doing sums in my head about which bits were fantasy. And I have been the leader standing at the front, mistaking silence for agreement.
The second one is worse, because it feels like success at the time. Nobody argued. Everyone had the deck. You even took questions at the end, and there were none, which you filed under "clear communication" rather than under "nobody in this room believes they own any of this".
Here is what I got wrong for years. I thought involvement was a morale exercise. A bit of listening to make people feel heard before we did the sensible thing anyway. Something you do if you have time.
Involvement is not a morale exercise. It is the mechanism by which a plan becomes real. Skip it and you have written fiction with a Gantt chart attached.
The experiment nobody in tech has read
In 1947 a pajama factory in Virginia had a problem your engineering org would recognize. Every time management changed how a job was done, output collapsed and stayed collapsed. People quit. The ones who stayed got hostile and slow.
Two researchers, Lester Coch and John French, ran a proper experiment on it. Same factory, same kind of change, four groups, one variable: how much say the workers had in designing the change.
The results are worth memorizing.
The group given the standard treatment, a clear announcement and a chance to ask questions, dropped about 20 percent in output and never got back to their previous level. Never. The group allowed to elect representatives into the planning took two weeks to recover. The groups involved in the whole discussion, all of it, ended up around 15 percent above where they started.
Same change. Same work. Same building. The only difference was who helped design it, and the gap between best and worst was permanent.
I keep coming back to the first group, because the first group is how most engineering change gets rolled out today. Clear announcement. Chance to ask questions. Extremely professional. Output never recovers and everyone agrees the technology was harder than expected.
Why "I asked for feedback" does not count
The usual defence at this point is: I did involve them. I sent the doc round. I asked for comments.
You asked people to react to a finished thing. Reacting is not building. By the time your doc has section numbers, the shape of it is settled, and everyone knows it. Comments on a finished plan are theatre for both sides.
Watch what people do with an early, ugly, obviously incomplete draft instead. They argue about it. They tell you the bit you got wrong about the payments service. They start using "we" without noticing.
Norton, Mochon and Ariely put a name to the underlying effect in 2011. They called it the IKEA effect. People who assembled their own flat-pack furniture were willing to pay 63 percent more for it than people handed the identical item pre-built. Same object. Different labor history.
The detail I like most is the failure case. When the researchers had people build something and then take it apart, or stopped them before they finished, the effect vanished. Effort with no completed result buys you nothing.
Which is a decent description of what a comment round does to your team. You let them put effort in, then you disassemble their contribution in front of them, and you wonder why ownership never appeared.
The research keeps saying the same thing in new clothes
Google's 2024 Accelerate State of DevOps report landed on findings with the same shape. Developers working with a user-centric mindset were more productive, more satisfied and less likely to burn out. Unstable, shifting priorities damaged productivity and drove burnout in a way strong leadership and good documentation did not fix.
The platform engineering finding is the sharpest one for anyone building an internal platform this year. Internal developer platforms helped productivity, and hurt throughput and stability when they were built without preserving developer independence. Build a platform for your engineers and it works. Build one at them and you have added a queue.
There is a pattern under all of this, and it is not about being nice.
The people doing the work hold information you do not have. Not opinions. Information. Which service has the undocumented retry loop. Which client will scream. Which two-day task is a two-month task. You either pull it into the plan while the plan is soft, or you find it out later at ten times the price, and by then it arrives as bad news from people with no reason to help you fix it.
What this looks like on Monday
None of this needs a framework. It needs you to give away the pen.
Bring people in while the plan is still embarrassing. If you are proud of the document, you have waited too long. Show the mess. The mess is what invites contribution.
Ask for the plan, not for feedback on yours. "How would you sequence this?" gets you a different answer than "any concerns?" One asks for their thinking. The other asks for their approval, and people learn quickly what happens to concerns.
Let their version win something. If every discussion ends with your original plan intact, you have taught the room a lesson about discussions. Something visible has to change, or the next session will be silent.
Name who owns each piece, out loud, in front of everyone. Ownership is a decision you make in public, not a feeling people develop on their own.
Say what is not up for grabs. Involvement is not a vote on everything. Budget, deadline, regulatory constraint, fine, fix them and say so. People will work happily inside honest constraints. Fake consultation on a decision already made is what poisons the well.
The uncomfortable bit
My research into bad bosses found 99.5 percent of respondents reported one or more types of bad boss during their working life. When I first saw the number I read it as a story about other people. It took me longer than I would like to admit to work out I was in the denominator, and not only as a victim.
The version of me who wrote plans alone was not a villain. He was efficient. Involving twelve people is slow and messy and full of opinions from someone who has been there eleven years and remembers why we do it the weird way. Writing it yourself takes an afternoon.
An afternoon, then eighteen months of drag.
So here is the question I would ask before your next big technical plan goes out. If the people who have to build this had written it themselves, how different would it look? If the honest answer is "a lot", you already know why the last one failed.
And if the honest answer is "I have no idea"... there is your answer.