How to Restructure Your Company Without Chaos
Most reorgs are designed adequately and executed badly. The chart is defensible, the reasoning is sound, and the rollout produces three months of confusion, a handful of resignations among people you could not afford to lose, and a quiet consensus that the change was politics. None of that is caused by the design. It is caused by sequence — decisions made in the wrong order, information reaching people in the wrong order, and a transition period nobody planned. This page is the execution.
What’s inside
Reorgs fail in execution, not design
The eight-week sequence
Day one, in order
What to freeze and what to keep moving
The six-week correction
The five execution mistakes
Where Blomma fits
Reorgs fail in execution, not design
A structural change asks every affected person to answer three questions immediately: what happens to me, who do I work for, and is my standing in this company better or worse than it was yesterday. Until those are answered, nobody is doing their job — they are calculating.
That is the whole problem. Every hour between a person hearing that a reorg is happening and hearing what it means for them specifically is an hour of lost work and accumulating anxiety, and the anxiety converts into a story about politics because a vacuum always fills with the worse explanation.
So the execution objective is narrow: minimise the time between when each person learns something is changing and when they learn what it means for them. Almost every mechanic below follows from that single principle.
The corollary is that a reorg leaked or announced before the details are settled is already going badly, regardless of how good the chart is. Settle first, announce once.
The eight-week sequence
A workable timeline for a company of fifty to three hundred. Compress at your own risk; the compressible parts are marked.
Weeks one to two — decide, privately, with two or three people.The chart, the reasoning, and the trade-off you are accepting. Keep the circle genuinely small. Every additional person in this phase raises leak risk substantially, and a leak forces you to announce before you are ready.
Week three — test the design.Walk your six slowest decisions through the proposed chart and check they actually get faster. Count the escalation paths that still end at your desk. Weight the spans honestly. Write the one-sentence trade-off. This week is not optional and it is the one founders skip.
Week four — socialise with the leaders whose scope changes.Individually, in confidence, as a genuine conversation rather than an announcement. Some of them will improve the design; all of them need to be able to defend it. A leader who learns their scope changed at the same time as their team cannot lead through it.
Week five — finalise, and write the personal messages.Every affected person’s specific answer: who they report to, what they own, what does not change. This is the artefact that determines how the rollout goes, and it takes longer than you expect.
Week six — announce.Day one below. Compressible only in the sense that the whole day should be compressed.
Weeks seven and eight — transition.Explicit dual-running where needed, new rituals starting, old ones ending on named dates.
Week fourteen — the correction.More below.
Day one, in order
The single most important few hours. Order matters more than wording.
Leaders whose scope changes — already done in week four.They should arrive on day one already aligned.
Anyone whose manager changes, individually, first.Before any group communication. This is the highest-risk group and the most likely to resign over process rather than substance. Each conversation is short: your new manager is X, here is what you own, here is what does not change, here is why.
Anyone whose scope narrows, individually.Name it plainly rather than dressing it up. People know what has happened and a euphemism costs you credibility at the exact moment you need it.
The affected teams, in their groups.Immediately after the individual conversations — same morning.
The whole company, live.Same day. Not a written note alone. Cover the problem being solved, the change, what is not changing, and the timeline. Take questions in the room even if they are uncomfortable.
Written summary to everyone, same day.Because people forget the meeting and re-read the document, and because those who were absent should not get it secondhand.
Compress all of this into one day. A reorg that dribbles out over a week generates a week of rumour, and the rumour version is always worse than the plan.
What to freeze and what to keep moving
A transition period needs explicit rules, or everything either stops or proceeds on stale assumptions.
Freeze:hiring into affected teams until reporting lines are settled; any promotion or levelling decisions in flight, with a stated date when they resume; and new cross-team commitments that assume the old structure.
Keep moving:customer-facing commitments, in-flight delivery, and anything with an external date. The most damaging version of a reorg is one where delivery stops for a month and the market notices.
Name explicitly:who owns each in-flight project during the transition. This is where things actually get dropped — not in the chart, but in the two weeks where a project’s owner has changed and neither the old nor the new one is acting.
And state the freeze publicly with an end date. Unstated freezes get interpreted as indefinite, and people stop asking for things they need.
The six-week correction
The step that separates reorgs that settle from reorgs that fester, and almost nobody plans it.
Six weeks after the announcement, deliberately review what is not working. Not the strategy — the mechanics. Which decisions still have no clear owner. Which seams are producing friction nobody anticipated. Which person is quietly doing two jobs. Which ritual you invented that is not earning its time.
Then fix those things, visibly, and say that you are fixing them because the review found them.
Two reasons this matters more than it sounds. First, every reorg has three or four wrong details, and fixing them at six weeks is cheap while fixing them at six months requires a second reorg. Second, and more important: announcing the review date in the original communication changes how people receive the whole change. “We will look at this in six weeks and adjust” lowers the stakes, makes dissent legitimate rather than disloyal, and means people surface problems instead of working around them.
Say the date on day one. Hold it.
The five execution mistakes
Announcing before the details are settled.Produces a week of people asking questions you cannot answer, which reads as a change that was not thought through.
Group announcement before individual conversations.The single most reliable cause of resignations in a reorg, and entirely avoidable.
Leading with the chart instead of the problem.People accept structural change when they recognise the problem it solves. Show them a diagram first and they will read it as politics and immediately locate themselves on it.
Pretending nobody loses anything.Every reorg costs someone scope, proximity, or a manager they liked. Naming the losses plainly is what makes the rest of the message believable.
No transition owner for in-flight work.Where things actually get dropped.
One more, less obvious: reorganising again too soon. Structural change costs real relationships, context, and trust. A company that restructures every six months teaches everyone that structure is weather, and stops investing in whatever the current arrangement is.
Where Blomma fits
A reorg asks you to run a complex sequence while being the person everyone is reading for signals, and the people best placed to advise you are the people whose scope is about to change.
Blomma is an always-on AI career coach with no stake in your structure. Use it to test the design in week three — including the escalation paths you would rather believe do not end at your desk. Use it to prepare the week-four conversations with leaders whose scope shrinks, which are the hardest and the ones that determine whether they stay and lead through it. Use it to draft the individual messages so that each one answers what happens to me, who do I work for, and what does not change. And use it in the days afterwards, when you will hear a version of the change you did not intend and have to decide whether to correct it. Where the situation warrants a human who has run one at your stage, bring one in..
A reorg is not a design exercise with a rollout attached. The design is a week’s work; the execution is where the company either absorbs the change in a fortnight or spends a quarter recovering from it.