Reorganization

Organizational structure isn't something you set once and leave. An arrangement that ran well at ten people becomes the bottleneck at forty.

That happened at Pagedeck. The company started split into engineering, design and product, and that arrangement fit a single product well. Grouping people by discipline made technical calls fast and meant hiring bars only had to be defined once. Then a second product appeared and the arrangement started costing money. Shipping one feature required aligning three teams' schedules, and the meetings to do that aligning ran five a week. Nobody was slacking, and a single feature still took six weeks to go out. The cost wasn't in any one team's work; it sat entirely in the seams between them.

What needs fixing here is the arrangement, not the people. But changing the arrangement lands on people. Who they report to changes, the scope they own shrinks or grows, the person next to them is different. That makes this the work most vulnerable to rumor. At Pagedeck the news leaked three weeks before the announcement, and for those three weeks people spent more attention on what would happen to their own seat than on the work in front of them.

That is why reorganization got codified as a procedure. The decision about structure can be made by a few people in a few days, but the order in which it gets told, and who hears it first, is what changed the outcome. Run the same structural change in the wrong order and the month after the announcement goes to damage control; run it in the right order and the new arrangement is working the following week.

Six steps.

1. Write down what's stuck, in one sentence. "A structure that matches our growth" isn't a criterion. "Shipping one feature requires coordinating three teams' schedules and takes six weeks on average" is, because it lets you check later whether the change worked.
2. Draw two or three alternatives. Grouping by discipline gives a functional organization; grouping by product or goal gives a product organization; overlaying both axes is the third common shape. For each one, write what gets easier and what gets harder. Split by product and releases speed up while technical standards inside a discipline scatter.
3. Put names into the new structure. This is where reporting lines — the relationships describing who reports to whom — get drawn person by person. Drawing them exposes the manager who would end up with twelve reports and the work that nobody would own. Both problems are invisible on a diagram of boxes and obvious the moment names go in.
4. Talk individually with the people most affected, first. Anyone whose manager changes, anyone whose scope shrinks, anyone becoming a manager. The purpose of this step is that nobody hears about their own situation for the first time in the company-wide announcement.
5. Announce it to everyone at once. Say what changes and why, when it takes effect, and what is not changing. Leave that last item out and the audience concludes that everything is now uncertain.
6. Spend four to eight weeks on settling. Rebuild the meeting structure, move goals onto the new team boundaries, and update the org chart — the diagram of teams and reporting relationships — along with system permissions. If the chart doesn't get updated, people keep routing questions through the old paths.

The design work belongs to the founder and the leadership team, with someone in HR handling process and documents and affected managers handling the detail inside their own areas. At 45 people it's better if no more than four or five people are involved in the design. Every additional person raises the chance of a leak before the announcement, and leaked information always spreads in an incomplete form.

The announcement gets pinned to a quarter boundary. Goals and budgets move quarterly, so having new teams receive new goals is cleaner. Keep it well away from the review cycle, on the other hand. Change someone's manager while evaluations are being written and the first thing to sort out is who is evaluating whom.

Frequency is the hidden cost. One reorganization costs the whole company roughly two months of speed while it settles — time spent rebuilding meetings, relearning decision paths, and forming a working relationship with a new manager. An organization that reorganizes twice a year meets the next change before those two months are up, and never experiences the settled state at all — which also means it never finds out whether the previous change worked.

"Tell me in one sentence what gets faster because of this change."

Checking that there is a reason behind the structural move, stated concretely enough to verify afterward.

"I spoke individually with everyone whose manager changes before the announcement."

Nobody heard their own situation for the first time in a company-wide message, which is the part of the sequence that most often gets skipped.

"Please also write down what isn't changing."

Announce only the changes and everything else looks uncertain too, including the parts that were never on the table.

Pagedeck decided to split teams by product. Grace drew three options, and the one that kept the functional split while naming product owners got dropped because the decision path would have stayed exactly as it was — the diagram would have changed and nothing else would have.

The evening before the announcement, Grace met one-on-one with the six people whose reporting line was changing. The next day the company-wide message opened with the fact that salaries and job levels were not changing, before describing the new structure. Over the following six weeks the weekly meeting layout got revised twice, and at week eight they measured feature lead time again: six weeks had become three.

The most common mistake is expecting the reorganization to solve the problem. Changing the structure looks like it should unblock what was blocked. But what a structure changes is only the arrangement of what's easy and what's hard. Split by product and releases get faster while technical standards inside each discipline drift apart — a problem that shows up three months later. A reorganization doesn't remove a problem; it trades it for a different one, and if nobody writes down what the trade was, the next reorganization returns to the structure just abandoned.

The other misreading is that reorganization means headcount reduction. The two do sometimes happen together, which is where the impression comes from. Redrawing a structure and reducing staff have different purposes and different procedures. Even so, the announcement has to address the assumption directly. If no one is leaving, that sentence goes first — leave it out and people spend the next several days thinking about nothing else.