2026-10-08
October 8, 2026
The boxes take a week to draw. The sequencing of who hears what, and when, decides whether the reorg works.
Watch how most reorgs get designed. A small group of leaders spends weeks arguing about boundaries, reporting lines, and names. The result is a slide with new boxes. Then the communication plan is written the night before the announcement, usually as a Slack post and an all-hands slot. The design got ninety percent of the attention. The rollout got ten, and the rollout is where the damage happens.
David Kiger, VP of Engineering at Yelp, makes this point plainly in his LeadDev piece on planning team reorganizations: the staffing and communication plan determines whether the change succeeds, and the structure itself is only part of it. His advice reads less like org design and more like program management. Classify the change. Plan the people. Set an information schedule. Define a transition timeline. Estimate how long the cleanup tail will run. Every one of those is a TPM artifact.
That is the opening for senior TPMs and for tech leaders who want one in the room. A reorg is a cross-functional program with a hard external dependency, which is human trust. It has a critical path, a stakeholder map, a risk register, and a go-live date. The people who get hurt are the ones nobody mapped. If your org is reorganizing this quarter, ask who owns the rollout plan. If the answer is "HR" or "we'll figure it out," you have found your program.
Start with Kiger's first question, because it saves the most pain: can this change happen gradually, or does it need a shake-up? Splitting or merging two adjacent teams is an evolution. Combining several teams, or changing the tech stack and the structure at once, is a disruption. Disruptions frighten people more and take longer to settle. Kiger notes that a small change may settle in weeks while a large one can take a year or more. Be honest about which one you are running, because the rollout plan for each is different, and leaders habitually describe a disruption as an evolution to make it easier to approve.
Second, design boundaries from two directions and then reconcile them. Kiger groups features and user flows by product relevance, then groups data stores, services, APIs, and on-call duties by engineering relevance, then nudges the two toward each other. He is explicit that you will end up with some arbitrary compromises, and that you should accept them and commit rather than relitigate. This is Conway's law used on purpose. Melvin Conway observed in 1968 that systems end up copying the communication structure of the organizations that build them. If you draw the team boundary through the middle of a tightly coupled service, you have designed a permanent coordination tax. The TPM's contribution here is the dependency map. Before anyone proposes boxes, overlay current cross-team dependencies on the proposed boundaries and count the lines that now cross a team edge. A structure that turns ten cross-team dependencies into thirty is a structure that will need a TPM permanently, and probably the wrong one.
Third, plan the people with the same rigor as the architecture. Kiger recommends identifying who will be excited, skeptical, or opposed, and anticipating knock-on effects, since one move can trigger others. This is a force-field analysis on individuals: for each affected senior person, what do they gain, what do they lose, and who do they talk to? Get sign-off from the people with the most to lose before the announcement, and keep backup plans ready. Tailor the conversations. Some people accept an assignment without input. Others need a real say, and being denied one costs you more than the say would have.
Fourth, and this is the part that gets skipped: set an information schedule. Decide who hears what, in what order, and on what day. The rule is that nobody should learn something that affects them from a peer, a calendar invite, or a rumor. A workable sequence is: the leadership group that designed it, then the managers who must carry it, then the individuals whose roles change, then their teams, then adjacent teams and stakeholders, with each step compressed into hours, not days. The longer the gap between steps, the more informal channels fill the silence. Rumors are not a morale problem. They are a schedule failure.
Fifth, define the transition. Reorgs leave ownership ambiguity: who owns the on-call rotation for the service that straddles two teams, who owns the roadmap item that was half-delivered. Kiger suggests setting how long teams have to resolve unclear ownership. Treat each ambiguity as a ticket with an owner and a date. Then track the cleanup tail explicitly, because without a tail owner it drags on for quarters and the org quietly concludes the reorg did not work.
Finally, there is a managing-up angle. When a VP or CTO is considering a reorg, the most valuable thing a senior TPM or director can bring is not an opinion on the boxes. It is the question "what is the rollout plan, and what will we measure at 30, 60, and 90 days?" Leaders rarely object to this, because it makes their change more likely to land. You earn influence by making their decision survivable, which is a far more reliable lever than arguing about structure.
Try this week. Pick any reorg, team split, or ownership change currently in flight or rumored at your company. Write a one-page rollout plan with four rows: the affected-people list sorted by who has most to lose, the information schedule with exact days and order, the open-ownership tickets with owners and due dates, and the 30/60/90 checks. Hand it to the leader running the change before the next planning meeting.
What it is. A tool from Barry Johnson's book Polarity Management for tensions that have no permanent answer, such as centralize versus decentralize. You map both poles, the upsides and downsides of each, so a team stops treating one pole as the solution and the other as the problem.
When to use it. Whenever a debate keeps coming back every reorg cycle: central platform team versus embedded engineers, standardization versus team autonomy, speed versus predictability. If last year's fix is this year's complaint, you are managing a polarity.
How to run it:
When NOT to use it. Do not use it on a problem with a real answer, such as a security vulnerability or a missed deadline. Polarities are tensions to manage, not problems to solve.
For a reorg: map "stable teams" against "flexible allocation" before you redraw anything, and agree on the early-warning signs that will tell you it is time to adjust.
How to plan team reorganizations — David Kiger (Yelp) on classifying the change, reconciling product and engineering boundaries, and scheduling who hears what; the most program-shaped reorg guide I have found.
How to lead without authority — A LeadDev piece (unbylined) built on the premise that flattened orgs leave more people leading without formal power; its "decision by traffic light" and incentive-alignment tactics are a usable checklist for TPMs.
Engineering leadership in 2026 — Scott Carey's LDX3 London talk drawing on a survey of 600+ engineering leaders about how their roles are shifting; the findings sit behind a free LeadDev account, so read them before you quote them.
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
— Melvin Conway, "How Do Committees Invent?" (1968)
Don't miss what's next. Subscribe to Critical Path: