The Reorg is the act of redesigning The Org Chart in order to solve a problem created by the previous reorg, thereby creating the conditions for the next reorg.
The Reorg is the corporate world’s perpetual motion machine. It requires no external energy — only the conviction that the current structure is the reason things aren’t working, and that a different arrangement of the same people, in the same building, doing the same work, will produce a different outcome. The Reorg is Einstein’s definition of insanity given a PowerPoint deck and a Q3 deadline.
The Reorg is not a transformation. It is not a strategy. It is a pendulum — and the pendulum has only two positions.
The Pendulum
Every reorg in history is a swing between two organizational models:
Functional — People are grouped by discipline. All backend developers sit together. All frontend developers sit together. All QA engineers sit together. All designers sit together. Each group develops deep expertise, consistent standards, and shared tooling. Each group also develops a six-week lead time to do anything useful, because delivering a feature requires coordinating across four groups who have different priorities, different backlogs, different sprint cadences, and different opinions about whether tabs or spaces are a moral issue.
The functional model optimizes for efficiency. Specialists are pooled. Knowledge is concentrated. Standards are enforced. And everything grinds to a halt, because a feature that touches three disciplines requires three teams to agree on timing, and three teams never agree on timing.
Cross-Functional — People are grouped by product area. Each team contains a backend developer, a frontend developer, a QA engineer, a designer, and a product owner. Each team can ship features end-to-end without coordinating with anyone. Each team also reinvents infrastructure, duplicates libraries, and develops its own conventions, because the backend developer has no backend peers to review their schema decisions, and the designer has no design peers to maintain the design system.
The cross-functional model optimizes for effectiveness. Teams ship independently. Features reach customers faster. And the monthly bill doubles, because seven teams have built seven authentication layers, seven logging frameworks, and seven slightly different interpretations of the REST API guidelines.
The reorg is the moment an executive notices the failure mode of the current model and prescribes the other model, which has a different failure mode that will become apparent in four to six months, at which point the pendulum swings back.
EFFICIENCY EFFECTIVENESS
(Functional) (Cross-Functional)
Standards ✓ Ship fast ✓
Expertise ✓ Autonomy ✓
Nothing ships ✗ Everything duplicated ✗
│ │
│ ┌──── THE REORG ────┐ │
└────────►│ Same people │◄─────────┘
│ Same building │
│ Different boxes │
└───────────────────┘
│
▼
(repeat every 4-6 months)
The Mechanism
The Reorg follows a predictable lifecycle:
-
The Pain — Something isn’t working. Features are slow (functional model) or infrastructure is chaos (cross-functional model). An executive identifies the structure as the cause. The executive is half right — the structure is a cause. The other causes — unclear strategy, underfunding, technical debt, and the fact that the previous reorg was never completed — are not discussed, because discussing them would not produce a satisfying slide deck.
-
The Room — A small group of senior leaders gathers in a room with frosted glass. They redesign the org chart. The people who will be reorganized are not in the room. The people who will be reorganized have never been in the room. The room is where the org chart is drawn, and the org chart is drawn by people who will not live inside it.
-
The Town Hall — The new structure is announced. The announcement contains the words “alignment,” “empowerment,” and “our people are our greatest asset.” The announcement does not contain the words “we tried this three reorgs ago and it didn’t work then either.” The employees nod. The employees have been through this before. The employees will duck when the pendulum passes.
-
The Migration — Desks are moved. Slack channels are created. JIRA projects are renamed, or more accurately, new JIRA projects are created alongside the old ones, which nobody deletes because someone might still have tickets in them. Reporting lines change. Dotted lines multiply. The shadow org chart — who people actually talk to — remains unchanged, because trust networks are not reorganizable.
-
The Honeymoon — For six to eight weeks, the new structure feels better. This is not because the new structure is better. It is because the act of reorganizing temporarily breaks the logjams of the old structure — frozen decisions are unfrozen by the chaos, and blocked work gets unblocked not by the new design but by the disruption itself. The executive credits the reorg. The improvement is credited to the structure. It is actually credited to the destruction.
-
The Settling — The new structure’s failure mode becomes apparent. If the swing was toward functional: features slow down. If the swing was toward cross-functional: duplication appears. The org chart, as always, produces the architecture that matches it. The shadow org chart, as always, produces the work that actually ships.
-
The Next Reorg — See step 1.
The Tele2 Proof
The most sustained observation of the Reorg in its natural habitat was conducted over seven years at a Scandinavian telecommunications company, where the pendulum swung with a regularity that would impress a Swiss clockmaker.
The company acquired. It grew. It shrank. It reorged. Every four to six months, the boxes were rearranged. One hundred agile coaches entered through the revolving door and exited through the same door, certifications intact, LinkedIn profiles updated. The coaches were not the cause of the reorgs and were not the solution to the reorgs. They were synchronized with the reorgs — arriving when the new structure needed explaining and departing when the next reorg made the explanation obsolete.
The pendulum swung:
- Functional — for efficiency. Backend together. Frontend together. Platform together. Everything consistent. Nothing shipped.
- Cross-functional — for effectiveness. Product teams. Squad autonomy. Everything shipped. Everything duplicated.
- Functional — for efficiency again. The duplication was unsustainable. Pool the specialists.
- Cross-functional — for effectiveness again. The pooling was too slow. Embed the specialists.
Each swing was half-hearted. Each design was done without the people being reorganized. Each time, the same engineers moved desks, changed Slack channels, got new managers, and continued writing the same code they were writing before.
“You’ve watched organizations layer Scrum on top of SAFe on top of existing dysfunction and call it ’transformation.’”
— riclib, Mythology Driven Development — Substack Draft
The dysfunction was not the structure. The dysfunction was the belief that the structure was the problem. The structure was a symptom. The pendulum treated the symptom. The disease — unclear strategy, absent prioritization, and a refusal to involve the people doing the work in the decisions about how the work is organized — remained untreated through every swing.
The People Not in the Room
The Reorg’s most consistent feature is the absence of the people being reorganized from the process of reorganizing.
The org chart is drawn by executives. The executives have a view of the organization that is shaped by the org chart they drew last time — a recursive loop in which the map-makers navigate by maps they made of maps they made. The people who live in the territory — who know which Slack channels actually work, which standup is actually useful, which cross-team dependency is actually the bottleneck — are informed of the new structure after it has been designed.
This is not malice. It is logistics. You cannot put four hundred people in a room and ask them to redesign their own structure. But the consequence is that every reorg is a theory about how work flows, designed by people who do not do the work, tested on people who were not consulted, and evaluated by the same people who designed it.
The evaluation always concludes that the reorg was necessary and partially successful, because the evaluators are the designers, and no architect has ever concluded that the building they designed should not have been built.
The Layoff Reorg
A subspecies of The Reorg is The Layoff Reorg — a restructuring whose primary purpose is cost reduction but whose announcement uses the language of strategic alignment.
The Layoff Reorg is announced with the same vocabulary as the strategic reorg: “alignment,” “focus,” “efficiency,” “streamlining.” The difference is that boxes are not rearranged — they are deleted. The org chart does not swing between functional and cross-functional. It shrinks. The pendulum is replaced by a guillotine.
The Layoff Reorg is followed, eighteen months later, by a hiring round to replace the institutional knowledge that was deleted. The new hires are organized into a structure that resembles the one before the layoff, because Conway’s Law does not negotiate, and the communication patterns of the surviving employees have not changed.
The org chart regenerates. Like a lizard’s tail.
The Consultant’s Role
The Consultant and The Reorg exist in symbiosis. The Consultant recommends reorgs. The Reorg creates the conditions that require consultants. Neither can survive without the other.
The Consultant arrives, interviews everyone who does the work (see: The People Not in the Room), produces a slide deck recommending a new structure, and departs before the new structure’s failure mode becomes apparent. The Consultant’s slide deck recommends either a functional structure (if the current structure is cross-functional) or a cross-functional structure (if the current structure is functional). The recommendation is always correct, because both structures solve the current problem. The recommendation is always temporary, because both structures create the next problem.
“Their best practices were Netflix’s best practices and Spotify’s best practices. Netflix has 200 million users. Spotify has 500 million. They have twelve hundred.”
— Interlude — The Blazer Years
The Squirrel’s Enthusiasm
The Caffeinated Squirrel loves reorgs. The Reorg is the Squirrel’s natural habitat — a period of creative destruction in which new boxes can be proposed, new frameworks can be introduced, new Centers of Excellence can be established, and new architecture can be designed to match the new org chart.
The Squirrel proposes a Platform Team during the cross-functional phase, an Enablement Team during the functional phase, and a Transformation Office during both. Each proposal adds boxes. Each box adds architecture. Each architecture adds complexity. Each complexity adds the conditions for the next reorg.
The Lizard does not reorg. The Lizard has one box. The Lizard’s architecture has one binary. The pendulum has nowhere to swing when there is only one position.
The Escape Velocity
The only documented escape from the pendulum is leaving.
After seven years of watching the pendulum swing — functional, cross-functional, functional, cross-functional, layoff, acquisition, growth, shrink — a consultant extracted himself to a solo business. One person. One box. No pendulum.
The architecture became one binary. The org chart became unnecessary. Conway’s Law, for once, produced exactly the system the developer wanted — because the developer was the entire organization, and the organization’s communication structure was an internal monologue that never held a meeting, never drew a dotted line, and never reorganized.
“THE BEST INTERFACE IS NO INTERFACE
THE BEST DATABASE IS ONE FILE
THE BEST DEPLOYMENT IS ONE BINARY”
— The Lifelog Manifesto, The Homecoming, or The Three Days a Palace Was Built From Markdown and SQLite
The best org chart is no org chart.
Measured Characteristics
Average reorg cadence (telecommunications): 4-6 months
Time to design new org chart: 2-3 weeks
Time for codebase to match new org chart: 18 months
Time before next reorg: 4-6 months
Net architectural progress per reorg: 0
Agile coaches observed entering and exiting: ~100
People being reorged who were consulted: 0
Pendulum positions: 2 (functional, cross-functional)
Problems solved by swinging to functional: 1 (duplication)
Problems created by swinging to functional: 1 (speed)
Problems solved by swinging to cross-functional: 1 (speed)
Problems created by swinging to cross-functional: 1 (duplication)
Net problems solved: 0
Escape velocity achieved by: leaving
