Good organizational design is boring, political, constrained, and iterative. That is why it works when theater does not.

This post assumes you have already read the diagnostic series. You know how to map decision rights, information flow, handoffs, incentives, and informal power. You have your baseline measurements. You have a named behavioral change in mind.

What the diagnostic posts do not cover is what happens when the diagnosis surfaces too many problems to fix at once, when political resistance makes the ideal sequence impossible, when the human transition costs are unacknowledged, and how to know when the redesign is done.

That is this post.

The Prioritization Problem: When Everything Is Broken

A thorough diagnostic often surfaces far more design problems than you can address simultaneously. Decision rights are unclear. Information flows are broken. Incentives distort behavior. Informal power overrides formal authority. Handoff count is too high. The manager layer is uneven. Planning cadence is theater.

This is not unusual. It is the normal output of honest diagnosis.

The mistake is trying to fix everything or treating it as a sequencing problem when it is actually a prioritization problem. Not all design problems are equally expensive to leave unfixed. Some create compounding damage. Some are tolerable in the short term. Some are symptoms of a deeper problem that fixing the symptom just relocates.

Prioritize by:

  • Compounding cost. A decision rights problem compounds every day — every decisionlatency event, every passive resistance episode, every rework loop. An information flow problem compounds when bad data produces bad decisions that take longer to reverse. Start with problems that generate ongoing damage, not just point-in-time friction.
  • Leverage. Some fixes unlock other fixes. Clarifying decision rights for pricing exceptions may not matter much on its own. Clarifying decision rights for roadmap tradeoffs and platform capacity removes two of the most common escalation triggers. Fix the high-leverage decision rights first.
  • Political feasibility. Some fixes require less political capital than others. If you have limited organizational trust, start with a visible win that produces measurable improvement within 60 days — even if it is not the most important problem. Accumulate credibility before spending it on hard fights.
  • Second-order effects. A change that looks like one thing often produces unanticipated consequences elsewhere. Before committing to a redesign of the sales-to-implementation handoff, ask: what happens to customer success? What happens to product's roadmap visibility? What happens to finance's revenue recognition? Map the ripples before you launch.

When to stop adding redesign scope: If your redesign has more than three simultaneous structural changes, you are running an uncontrolled experiment. Structure, decision rights, incentives, and operating cadence are already four changes if they all move together. Add a new planning process and you have five. Two or three is the realistic load for one migration wave.

Managing the Human Transition

This is the part that rarely appears in redesign methodologies. It should.

Organizational redesign is a loss event for some people. Not a change event — a loss. Status, scope, influence, team relationships, career trajectory, and professional identity can all be materially affected by a structural change. People who have been doing important work for years suddenly have a different role, a different manager, or a different mandate.

Ignoring this does not make it go away. It makes the resistance less legitimate and more emotional.

Acknowledge grief explicitly. When a team boundary changes, people who built relationships across that boundary experience a real loss. When a leader loses direct reports, the professional identity attached to building and leading that team is affected. When a function is merged or split, people who defined themselves by that function's mission are disoriented. Naming this — without apologizing for the change — reduces the energy spent on denial and displacement.

Do not confuse resistance with bad faith. Some resistance is political self-interest and should be managed as such. Some resistance is legitimate operational concern that the redesign has not addressed. Some resistance is grief. Treating all resistance as political self-interest produces a redesign that misses real risks. Treating all resistance as grief produces a redesign that never ships. Distinguish between them.

Be explicit about what is changing and what is not. Ambiguity about scope, timeline, role definitions, and success criteria is the condition in which rumor thrives. The most useful thing a leader can do in the first week after a redesign announcement is answer the uncomfortable questions directly: who owns what, who decides what, who loses what, who gains what, and what happens to the people in between.

Track morale during the migration. Productivity drops during structural transitions are normal. What is not normal is sustained morale decline past the point where the productivity drop stops being temporary and starts becoming a retention problem. Monitor regretted attrition, pulse survey scores on clarity and fairness, and escalation volume in the 90 days after launch. If these are trending wrong, the redesign has a human problem that structural fixes will not resolve.

A Concrete Example: Spotify's Squad Model

Spotify's organizational model — autonomous squads owning end-to-end features, tribes organizing squads by domain, chapters and guilds providing functional community and career development — was widely studied as an alternative to hierarchical design. What is less discussed is how Spotify managed the transition and eventual contraction of the model. As the company scaled from hundreds to thousands of engineers, the squad autonomy model created coordination problems that the tribe structure alone could not solve: duplicated platform work across squads, inconsistent customer experience across features owned by different squads, and alignment problems when squads had conflicting roadmap priorities. Spotify's subsequent organizational changes were less celebrated because they involved reintroducing coordination mechanisms — program managers, cross-squad rituals, shared platform investment — that the original model had explicitly minimized. The lesson is not that the original design was wrong. It is that the right design depends on scale, and that scale changes. A redesign that works at one size may need to be redesigned at another. Knowing when to stop is partly knowing when the current context no longer fits the design you just built.