How to reorganize without lying to anyone
Reorganizations fail in the announcement, not the org chart. What I do in the weeks before, what I say on the day, and the question every engineer is actually asking when the boxes move.
Every reorganization I have watched fail had a good org chart. The boxes made sense. The reporting lines were cleaner. And the day it was announced, the engineers in the room heard something completely different from what the slide said, because the slide answered a question nobody was asking.
The question everyone is asking during a reorganization is: what happens to me? Until that is answered, nothing else is heard.
Start with the problem, and be able to say it in one sentence
A reorganization is a solution. Before I propose one, I write down the problem in a sentence a skeptical engineer would accept. "Two teams own halves of the same service and every incident needs both on the call." "The platform team has twelve stakeholders and no way to say no." If I cannot write that sentence, the reorganization is about something else, usually someone's scope, and it should not happen.
That sentence is also the announcement. When people understand the problem, the new structure looks like an answer. When they do not, it looks like a shuffle.
The weeks before
The people whose jobs change the most hear it first, individually, before anything is announced. That is not a courtesy. It is the difference between a manager who learns in a meeting that half his team is moving, and one who was part of deciding how.
I talk to every manager affected, then every engineer whose reporting line or team changes, one at a time. Each conversation covers: what is changing for you specifically, why, what is not changing, and what you can influence. The last part is real. Several of my reorganizations changed shape because someone in those conversations pointed out a dependency the chart had missed.
By the day of the announcement, nobody who is directly affected should be surprised. The announcement is for everyone else.
The day
The group announcement is short and it does four things. It names the problem. It shows the new structure. It says, explicitly, what is not changing: the roadmap commitments, the on call rotations for the next month, compensation, titles. And it says when the details will be settled, and who to ask in the meantime.
Then I stop talking and take questions for as long as there are questions. The first few are about the chart. The real ones come after, and they are all versions of what happens to me. I answer every one of those directly, even when the answer is that I do not know yet and here is the date by which I will.
What not to say
I do not say the reorganization is not about cost, unless I am certain it is not, because people find out. I do not say nothing else will change, because something always does. I do not describe the new structure as final, because the first month always finds a seam the chart missed and the fix is easier if I have not declared victory.
And I do not let it be announced by email. A reorganization announced in writing, with no room, tells people that the person who made the decision did not want to face them.
The month after
The org chart is done on the day. The reorganization is done when the new teams have shipped something together and the old paths of who to ask have been replaced. That takes a month at minimum.
I hold a check in with every affected person at two weeks and at six. The two week one catches the things that were missed: an engineer whose work belongs to neither new team, a dependency that now crosses a boundary. The six week one asks whether the original problem is smaller. If it is not, the reorganization did not work, and I would rather know that than defend it.
The reorganization I did for AI
When the AI first operating model settled, one reorganization followed from it. Review had become the bottleneck, and the two people best at reviewing generated code were on different teams, both overloaded. I moved them together with a small remit: own the review tooling and the merge rules for everyone. The problem sentence was easy to write, both of them helped design the change, and the rest of the organization heard about it as a solution to something they had been complaining about for a month. That is what a reorganization looks like when the announcement is the last step instead of the first.