The Reorganization That Solved the Chart but Not the Work: How to Evaluate Structural Change Before You Commit to It
When leaders respond to persistent performance problems by redesigning the org chart, they often move accountability without addressing the underlying cause of the failure.

Reorganization is among the most consequential tools a senior leader can use, and among the most frequently misapplied. When a business unit underperforms, when coordination between functions breaks down, or when a strategy shifts direction, restructuring the organization feels like a decisive response. Lines move. Titles change. New reporting relationships signal that leadership has acted. What often does not change is the actual problem.
The difficulty is that organizational structure is visible and adjustable in ways that root causes rarely are. A reporting relationship can be redrawn in an afternoon. A capability deficit, a flawed incentive, a process that produces the wrong output, or a culture that does not support the stated priorities cannot be fixed on a slide. When those underlying conditions remain intact, the reorganization redistributes the symptoms rather than resolving them.
Diagnosing Before Designing
Before committing to a structural change, leaders benefit from answering one question with specificity: what, precisely, is the structure failing to do? The answer to that question must be concrete enough that a proposed new structure can be evaluated against it.
Consider a hypothetical in which two business units consistently produce conflicting customer commitments because their leaders have parallel authority and no shared escalation path. That is a structural problem. A reporting change that places both units under a single leader with clear tiebreaking authority directly addresses the failure mode. The diagnosis and the remedy connect.
Now consider a different hypothetical in which two units produce conflicting customer commitments because each team has been rewarded for closing deals independently regardless of downstream consequences. In that case, the authority structure may be fine. The incentive design is the failure. Reorganizing the chart without changing the incentives produces a new structure that generates the same behavior through a different set of boxes.
The test is whether the proposed structure mechanically prevents the identified failure, or whether it merely changes which people are present when the failure recurs.
The Three Conditions Worth Assessing
Most organizational performance problems trace back to one of three conditions, and each points to a different remedy.
The first is a coordination failure, where the right work is being done but not sequenced or integrated across the people responsible for it. Structure can address this directly. Bringing previously siloed functions under shared leadership, establishing formal integration roles, or creating cross-functional accountability mechanisms can reduce the friction that produces coordination failures. This is the category where reorganization is most likely to be the correct tool.
The second is a capability failure, where the people in the roles do not yet possess the skills, judgment, or experience the work requires. Structure cannot resolve this. Moving a team with a capability gap to a new part of the org chart does not add capability; it changes who manages the gap. When capability is the actual constraint, development, selective hiring, or role redesign is more likely to produce improvement than structural change.
The third is an incentive failure, where the formal or informal rewards in the system direct people toward behavior that conflicts with the stated objective. Leaders frequently underestimate how powerfully incentive design shapes behavior at every level. When people are doing what the system rewards, reorganization changes the environment without changing the reward. The behavior follows the incentive, not the chart.
A structural change may be warranted alongside capability or incentive work, but it should not be expected to substitute for it.
The Cost That Gets Omitted from the Case for Change
Reorganizations carry costs that rarely appear in the document proposing them. Productivity typically declines for a period following any restructuring, as individuals orient to new managers, new peers, and new expectations. Institutional knowledge moves or becomes inaccessible as team compositions change. Relationships that enabled informal coordination dissolve and must be rebuilt. For senior leaders who are close to the decision but further from day-to-day operations, these costs are easy to underestimate.
The more frequently an organization restructures, the more these transition costs compound. Teams that have experienced repeated reorganizations often develop a learned passivity around structural announcements. They wait to see which changes persist before investing in new working relationships. That patience, understandable from an individual standpoint, slows the integration the reorganization was meant to accelerate.
This does not argue against structural change when it is warranted. It argues for including realistic transition costs in the evaluation, and for being skeptical when the projected benefits are large and the projected disruption costs are small.
Testing a Proposed Structure Before Implementing It
One useful practice before finalizing a structural change is to walk the most common decision scenarios through the proposed structure explicitly. For each recurring type of decision the organization makes, identify where it would land under the new design, who would hold authority, what information that person would need, and whether the structure routes that information to them reliably.
If that exercise reveals that a common decision type still lacks a clear owner, or that the structure requires information to travel through multiple layers before reaching the person who must act, those are design problems worth resolving before implementation rather than after.
A second practice is to name what the new structure will make harder, not only what it will make easier. Every structural choice involves tradeoffs. A more centralized design may improve consistency but slow responsiveness. A more decentralized design may improve speed but increase the risk of misalignment. Leaders who can articulate those tradeoffs explicitly are in a better position to monitor whether the predicted costs materialize and to address them if they do.
The Question Worth Asking Last
Before approving a restructuring, one question tends to surface the clearest picture of whether the change is warranted: if this new structure had been in place for the past year, would the problem we are trying to solve have occurred? If the honest answer is yes, the structure is not the primary cause, and changing it is unlikely to be the primary remedy. If the answer is genuinely no, that is meaningful evidence that the structural change is addressing something real.
Organizational design is a legitimate and sometimes necessary lever. The leaders who use it most effectively are those who reach for it deliberately, after ruling out the alternatives, and who can describe precisely which failure mode the new structure is designed to prevent.