Most reorgs are drawn on a whiteboard in an afternoon. You have 45 engineers, five managers and a new strategy, so you draw five boxes, give each a name that sounds like a product area, and fill them with people. It looks clean. Six months later every meaningful feature needs three of those teams, the "platform" box has become where unloved work goes, and someone suggests another reorg. This post gives you a way to test a proposed structure against the work your organization actually does before anyone hears about it.
Start from the work, not the org chart
The core idea is old. In his 1968 paper "How Do Committees Invent?", Melvin Conway argued that organizations designing systems are constrained to produce designs that copy their own communication structures. If two teams must talk to change something, the system will grow a seam there, and if a seam exists that no team owns, it will rot.
In 2010 Jonny LeRoy and Matt Simons of Thoughtworks named the practical consequence the inverse Conway maneuver: decide the architecture and flow of work you want, then shape teams to match. Matthew Skelton and Manuel Pais built Team Topologies around the same principle, with one added constraint: cognitive load. A team can only own as much as it can understand well enough to change safely.
So the order of work matters:
- What changes does the business need to make, often and quickly?
- Where are the natural seams in the systems and the domain?
- How much can one team carry?
- Only then: which people go where, and who leads them.
Most reorgs run this list backwards. They start with the managers you have and the headcount each should get, and the boundaries fall out of that.
Step 1: Trace the last quarter's changes
Before drawing anything, look at what actually shipped. Take 20 to 30 meaningful changes from the last quarter or two: features, significant fixes, migrations. For each, note which teams had to touch code, review, deploy or approve something.
A hypothetical extract for a 45-person organization:
| Change | Teams involved | Waited on another team? |
|---|---|---|
| New invoice layout | Web, Billing API, Data | Yes, 2 weeks for Data |
| Self-serve plan upgrade | Web, Billing API, Identity | Yes, 3 weeks for Identity |
| Usage alerts for customers | Data, Web, Notifications | Yes, 1 week for Notifications |
| SSO for enterprise | Identity | No |
| Tax rules for a new country | Billing API, Data | Yes, 2 weeks for Data |
Patterns jump out quickly. Here, almost everything customers notice about billing crosses three teams organized by technical layer, and Data is in the critical path of most of it. That's your diagnosis, and it should drive the design. If your proposed structure doesn't change the "teams involved" column for the most common kinds of change, it's a rename, not a reorg.
Step 2: Find the seams
Team Topologies calls the places where a system can be split cleanly fracture planes. The primary one is the business domain: an area of the business with its own language and rules, such as billing, identity or search. The authors also list others worth considering, including regulatory compliance, change cadence, risk, performance isolation, technology, user personas and team location.
Some practical ways to use them:
- Business domain first. If customers or product managers describe something as one thing ("billing", "onboarding"), a team that owns it end to end is usually the right starting point.
- Compliance. If one part of the system holds card data or health records, isolating it limits how much of the organization carries the audit burden.
- Change cadence. A part that changes weekly and a part that changes yearly rarely belong in the same team's head.
- Risk. High-risk areas, such as payments or authentication, may justify a team with tighter practices, provided it doesn't sit in everyone's path.
In the example, the seam is plainly "billing as customers experience it", not "web", "API" and "data". A stream-aligned billing team owning the invoice, upgrade and tax flows end to end would remove most of the waiting in the table above.
Step 3: Check each team's load
Once you have candidate teams, check whether each can carry what you've given it. Skelton and Pais offer rules of thumb rather than hard limits. They suggest classifying each domain a team would own:
| Domain type | What it looks like | Load heuristic |
|---|---|---|
| Simple | Most work has a clear path | A team of seven to nine can handle two or three |
| Complicated | Changes need analysis and a few iterations | Avoid one team owning two of these |
| Complex | Solutions need experimentation and discovery | A team with one complex domain should own nothing else |
A quick test to run with each prospective tech lead: "Could your team be on call for everything in this box, at 3 a.m., without paging another team?" If the honest answer is no, the box is too big, or something in it should be provided as a service by a platform or specialist team.
Load is also a reason to say no to the most common shortcut in reorgs: giving the strongest team everything nobody else wants. That team will slow down on its main work, and you'll have converted a structural problem into a performance conversation.
Step 4: Name how each team relates to the others
Every boundary creates an interface between teams. Draw a line between each pair that must work together and label it with one of the three Team Topologies interaction modes: collaboration, X-as-a-Service or facilitating. The earlier post on cross-team dependencies covers what to agree for each mode.
Two warning signs on that diagram:
- Collaboration lines everywhere. Collaboration is expensive and meant to be temporary. If a team needs ongoing close collaboration with three others, the boundaries are in the wrong place.
- A platform team with no "as a service" lines. A platform team that other teams must file tickets with and wait on is a bottleneck with a new name. If you can't describe what it offers as self-service, it isn't ready to be a platform team yet.
Step 5: Run the draft through a test sheet
Before you put names in boxes, score the draft. This worksheet is the artifact to bring to your leadership team:
| Test | Question | Pass looks like |
|---|---|---|
| Flow | For the five most common kinds of change, how many teams does each touch? | One team for most; two at most for the rest |
| Ownership | Is there any system, service or domain with no owning team, or with two? | Every one has exactly one owner |
| Load | Does any team own a complex domain plus something else, or two complicated ones? | No |
| On call | Can each team support what it owns without routinely paging another team? | Yes |
| Interfaces | How many permanent collaboration lines does each team have? | Zero or one, each time-boxed |
| Strategy | Does the structure make the bets in your strategy easier? | The top strategic initiative has a clear owning team |
| Size | Is each team between roughly five and nine people? | Yes, or there's a stated plan to get there |
Then rerun Step 1: take the same 20 to 30 historical changes and replay them against the new structure. If "waited on another team" doesn't drop substantially, keep redrawing. This replay is also the most persuasive thing you can show your executives, because it explains the reorg in terms of delivery rather than boxes. If you've written a one-page technical strategy, the "Strategy" row is where the two documents should visibly connect.
Common mistakes
- Designing around the managers you have. It's tempting to give each existing manager a team of similar size. Draw the teams first, then decide who leads them. A manager without an obvious team is a real conversation to have, not a reason to invent a box.
- Splitting by headcount. "Each team gets nine people" produces boundaries that follow arithmetic rather than seams.
- Reorganizing to fix a people problem. If one team is struggling because of its leadership, moving its boundaries won't fix that, and it will disrupt everyone else.
- Changing everything at once. If only two boundaries are causing most of the waiting, move those two. Smaller reorgs are cheaper and teach you whether your diagnosis was right.
- Skipping the ending. William Bridges distinguishes change, the new structure, from transition, the process people go through to let go of the old one. Teams that lose a codebase they built or a manager they trusted need that acknowledged, not just a new chart and a start date.
Before you announce anything
Run the trace in Step 1 this week. It takes an afternoon with your managers and a list of recent work, and it often shows that the reorg you were planning would solve a different problem from the one you have.
Then ask yourself one question about your draft: for the change your customers want most next year, how many teams will it need to cross? If the answer is more than one, you haven't finished drawing.
Org design and restructuring sit in the organizational transformation area of the PTME study guide, alongside the change models that help you roll a new structure out once you've got it right.