The best designs start from a sharp understanding of where the business is heading and what must change. This chapter helps you translate strategy into concrete organizational implications, define design objectives and success criteria, and build a fact-based, compelling case for change. It also shows you how to align the top team around a shared problem statement before you start debating options.
4.1 Translating Strategy into Organizational Implications
Before you move a single box on the org chart, you need a shared understanding of what the strategy actually demands of the organization. Most companies have a strategy document; far fewer have translated it into concrete implications for structure, roles, and ways of working. This translation is the bridge between “strategy work” and “org design work.”
Start with the real strategy, not the slideware. That means getting beyond broad statements like “customer centricity” or “digital transformation” and identifying the specific bets and trade-offs the organization has chosen. For example: which segments will you over-resource, which products will you deprioritize, what cost position are you targeting, what risks are you prepared to accept or reduce, and over what time horizon.
A practical approach is to work through three lenses.
First, look at the value agenda. List the major value drivers over the next three to five years: revenue growth by segment, margin improvement, cost reduction, capital efficiency, risk reduction. For each driver, ask: where in the business is this value created, and who needs to be in a position to influence it directly? This points to which units should hold P&L responsibility, which roles must be strengthened, and which capabilities must be concentrated rather than dispersed.
Second, examine critical capabilities and value streams. For each strategic priority, identify the capabilities that must be distinctive: solution selling, end-to-end supply chain orchestration, advanced analytics, regulatory navigation, and so on. Then look at the value streams through which these capabilities are deployed: customer acquisition, product development, service delivery, post-sales support, collections. The question is: where should each capability live structurally, and who owns each value stream end-to-end? If no single unit or leader clearly owns a critical value stream today, that is a direct organizational implication.
Third, consider risk, constraints, and external expectations. Regulatory regimes, capital constraints, and stakeholder expectations often narrow the viable design space. For example, a bank’s strategy to grow in higher-risk segments must sit within risk-appetite and control frameworks that regulators will scrutinize closely; that has structural implications for how independent risk functions are organized and how they interact with front-line units. Similarly, an ESG commitment may require explicit governance bodies or roles that did not previously exist.
A simple question set can help you translate strategy into organizational implications:
- What must we do differently (or much better) in the next 3–5 years than we did in the past?
- Which customers, products, or geographies are strategically critical, and who should be accountable for them?
- Which capabilities must be distinctive, and where should they sit to have real impact?
- Which value streams must have clear end-to-end ownership?
- What risks and constraints must be explicitly reflected in structure and governance?
Capturing the answers in a short, plain-language document—no more than two pages—gives you a practical “strategy-to-org brief.” This brief becomes the reference point for all subsequent design discussions. If a proposed structure does not support the brief, you either have the wrong design or you are not being honest about the strategy.
4.2 Defining Design Objectives and Success Criteria
Once you understand the strategic implications, you need to define what you want the redesign to achieve. This sounds obvious, but many redesigns proceed with vague goals like “increase agility” or “reduce complexity.” Those phrases may be directionally right, but they are not specific enough to guide trade-offs or to test design options.
Design objectives should answer two questions: what problem are we solving, and how will we know the new design is working. A useful way to structure them is across five dimensions: performance, customers, cost, organizational health, and risk.
On performance, be explicit about the outcomes you expect the design to support: faster time-to-market, higher win rates, fewer project overruns, better on-time delivery. Even if you cannot attribute future performance improvements solely to structure, you should specify the performance context in which the new design must operate. For example, “support a doubling of revenue in segment X without a proportional increase in overhead,” or “enable us to run Y% more projects with the same leadership capacity.”
On customers, define what should change from their perspective: fewer handoffs, single points of contact, consistent pricing, simpler contracting, better service levels. If customers currently experience your internal fragmentation, the design objectives should describe a different experience: “each strategic client has one accountable relationship owner” or “customer issues are resolved within 48 hours without escalation across more than two units.”
On cost, be realistic and explicit. Some designs are primarily performance-driven and may temporarily increase cost; others are explicitly aimed at structural cost reduction. Specify whether you are targeting headcount reduction, delayering, consolidation of support activities, or simply preventing cost from rising with growth. Quantify the target at least directionally: “reduce SG&A by X% over Y years, of which Z% comes from structural changes.”
Organizational health and ways of working also deserve explicit objectives. You might aim to improve clarity of accountability, reduce decision latency, increase empowerment at lower levels, or make roles more sustainable by reducing span extremes. Use language that managers and employees recognize, such as “reduce the number of committees required to approve a standard product launch from five to two” or “ensure front-line managers have 7–10 direct reports instead of 3–4.”
Finally, consider risk and control. For some organizations, the primary objective is to clarify first- and second-line responsibilities, strengthen independence of control functions, or simplify governance. Define these goals up front: for example, “clarify ownership for all top-10 enterprise risks” or “reduce overlapping risk and compliance forums by half while preserving regulatory coverage.”
A practical template for design objectives can fit on a single page:
- Context: Brief description of the strategic triggers and current pain points.
- Primary objective: One or two sentences on what the redesign must achieve above all.
- Secondary objectives: 4–6 bullets across performance, customers, cost, health, and risk.
- Constraints and non-negotiables: What must not be compromised (e.g., regulatory independence, minimum presence in key markets).
- Time horizon: Over what period you expect to see most of the benefits.
You do not need perfect numbers or exhaustive detail. The purpose is to give the design team a clear target to optimize for, and a way to evaluate options: “Does option A move us closer to these objectives than option B, given the constraints we have agreed?”
A common failure mode is to let the design objectives become a wish list: faster, cheaper, simpler, more innovative, more controlled, more decentralized—all at once. When everything is an objective, nothing is. The top team must be willing to prioritize: for example, “we are prepared to accept some duplication of capabilities in order to increase customer focus,” or “we will centralize more decisions than ideal to reduce risk and cost.” Being explicit about these trade-offs is at the heart of good design.
4.3 Building the Case for Change (Fact Base and Narrative)
Even if the strategic logic is clear and the design objectives are well defined, you still need a convincing case for change. Without it, the organization will experience the redesign as arbitrary disruption or as the personal project of a few leaders. A strong case for change rests on two pillars: a solid fact base and a simple, compelling narrative.
The fact base should quantify and qualify the problems with the current organization and the opportunity from changing it. It does not need to be a months-long research exercise, but it must be credible and concrete. Typical components include:
- Performance evidence: Trends in revenue, margins, productivity, time-to-market, service levels, error rates, or risk incidents that indicate the current structure is not delivering.
- Organizational diagnostics: Survey results, interview themes, organization-health scores, or external benchmarks that show issues with clarity, accountability, collaboration, or leadership load.
- Structural analysis: Data on spans and layers, number and type of units, committee and governance structures, and duplication of activities.
- Customer and stakeholder feedback: What customers, partners, regulators, or investors are saying about fragmentation, responsiveness, or risk management.
- Financial implications: High-level view of the structural cost base and potential impact of different design directions.
The goal is not to prove that the current organization is “bad,” but to show that it is misaligned with where the company needs to go and that this misalignment has tangible consequences.
The narrative then weaves these facts into a story that people at all levels can understand. A simple structure works best:
- Where we are today: Acknowledgment of achievements and strengths, plus honest articulation of current challenges and limitations.
- Where we need to go: A clear, succinct description of the future strategy and value agenda.
- Why the current organization cannot get us there: Link specific structural features to specific problems and missed opportunities.
- What will change at a high level: Not the detailed org chart, but the main design shifts (for example, “from regional to segment-based go-to-market,” or “from dispersed to platform-based technology and data”).
- What this means for our people: The kinds of roles that will be created, expanded, or simplified; how careers and collaboration may change; how leaders and employees will be supported through the transition.
You will need different versions of this narrative for different audiences. The board wants clarity on strategic logic, risks, and financial impact. Senior leaders want to understand how their mandates and decision rights will shift. Middle managers and employees want to know how their day-to-day work might change and whether their jobs are at risk. You can keep the core storyline the same but adjust the emphasis and level of detail.
When building the case for change, a few disciplines help:
- Quantify where you can, illustrate where you cannot. Use hard numbers for performance and structural data; use quotes or examples to bring qualitative issues to life.
- Acknowledge trade-offs and uncertainty. Pretending the new design will solve everything undermines credibility. Be explicit about what the redesign is expected to fix and what it will not.
- Connect to purpose and values. People are more likely to support change if they see how it helps the organization better serve its customers, employees, and broader stakeholders, not just its cost targets.
The case for change is not a one-time presentation; it is the backbone of your communications throughout the design and implementation. As you refine the design, you may update details, but the core logic should remain stable. If it keeps shifting, you may not yet have a firm enough grasp of the problem you are trying to solve.
4.4 Aligning the Top Team Around the Problem to Solve
No organizational design succeeds without real alignment in the top team. Alignment here does not mean unanimity on every detail; it means a shared understanding of the problem, the objectives, the constraints, and the process by which decisions will be made. Achieving that alignment is work. It rarely happens in a single meeting, and it is often the most important part of the entire effort.
The first step is to build explicit agreement on the problem statement. A good problem statement is specific, framed in organizational terms, and connected to strategy. For example: “Our current regional structure fragments accountability for global key accounts, leading to inconsistent pricing and slow solutioning,” or “We have accumulated layers and coordination roles that slow decisions and increase cost without improving control.” The problem statement should avoid prescribing the solution. It describes what is not working, not what you plan to do about it.
Use working sessions—not just presentations—to stress-test and refine the problem statement and design objectives. Ask each executive to articulate, in their own words, what they see as the core issues and where they believe structure is a constraint. Synthesize these perspectives into a draft, then iterate it together. The test of success is simple: if you ask each top-team member separately what problem the redesign is solving, their answers should be recognizably similar.
Next, surface and agree constraints and non-negotiables. These may include regulatory requirements, commitments to key customers, decisions already made by the board, or explicit cost or timing limits. It is better to put constraints on the table early than to have them emerge late as vetoes. At the same time, challenge “fake constraints” that are really preferences or legacy arrangements. The top team must be willing to distinguish between what truly cannot be changed and what is simply uncomfortable.
Equally important is agreeing on the design process and decision rights. Who will lead the design work day-to-day? What role will the CEO play versus the CHRO, CFO, or business heads? Which decisions will be taken collectively by the top team and which can be delegated to design sub-teams? When do proposals become decisions, and how will dissent be handled? If these questions are fuzzy, you can expect repeated relitigation of choices and side deals.
In practice, you will encounter differences of interest and perspective. Some executives may fear loss of power or relevance; others may push for structures that favor their units. It is naïve to pretend these dynamics do not exist. The way to handle them is to keep returning to the agreed strategy, objectives, and problem statement. When a proposal seems to favor one leader disproportionately, ask: “How does this option perform against our objectives? Which problems does it solve better or worse than the alternatives?” This keeps the conversation anchored in enterprise value rather than personal preference.
Three practical techniques help secure and maintain alignment:
- Visible artifacts. Put the problem statement, design objectives, constraints, and high-level process on a single page and use it to open every top-team design discussion. Update it as needed, but do not let it drift informally.
- Decision logs. For each major choice (e.g., basis of grouping, P&L allocation, location of shared functions), capture the options considered, the decision taken, the rationale, and any assumptions. Circulate these logs promptly. This reduces the tendency to revisit decisions based on partial memories.
- Red-team reviews. Periodically ask one or two top-team members to challenge the emerging design against the agreed criteria: “If we were external advisors, would we believe this structure will solve the stated problems?” This helps avoid groupthink and can surface issues early.
Finally, alignment is not only cognitive; it is also behavioral. Once key decisions have been made, the top team must visibly support them. That means speaking about the case for change consistently, avoiding side comments that undermine the effort, and being willing to make personal trade-offs when necessary. It may mean accepting changes to their own spans of control, mandate, or location of their teams. If executives are seen as exempting themselves from the logic of the redesign, credibility collapses.
Clarifying strategic intent and building a robust case for change are not “pre-work” that you rush through to get to the “real” design. They are the foundation on which all subsequent design choices rest. If that foundation is weak, even the most elegantly engineered structure will struggle to deliver.
