Design principles and guardrails are how you turn broad intent into practical criteria for choices. This chapter explains what good principles look like—directional, testable, linked to strategy—and how to co-create them with the leadership team. You’ll also learn how to translate principles into design tests for options, and how to define legal, financial, and labor guardrails that set boundaries without suffocating creativity.
7.1 What Good Design Principles Look Like
Many organizations say they have design principles. In practice, they often have a list of generic adjectives: agile, customer-centric, efficient, innovative. These words may sound right, but they do not help you choose between concrete options.
Good design principles have five characteristics:
- They are grounded in strategy.
Each principle should clearly link to the strategy and case for change you defined earlier. If you cannot answer “Which strategic priority does this principle support?”, it is likely decorative. - They are directional, not descriptive.
A principle should push you toward a particular choice or trade-off. “We will prioritize end-to-end customer ownership over internal efficiency where they conflict” is directional. “We are customer-focused” is not. - They acknowledge trade-offs.
Real design always involves trade-offs: cost vs. speed, standardization vs. local autonomy, control vs. empowerment. A good principle surfaces the trade-off and states which side you will favor in this redesign. That does not mean you ignore the other side, but it clarifies what wins when push comes to shove. - They are testable.
You should be able to sit in a room with two competing design options and ask, “Which one fits this principle better?” If the principle cannot be used to differentiate options, it is not yet specific enough. - They are few and memorable.
A list of 15–20 principles will not guide real decisions; people will cherry-pick. Aim for 5–8 well-crafted principles that your top team can remember and repeat.
Some examples of well-formed principles (wording will vary by company):
- “Each strategic customer segment has a clearly accountable P&L owner.”
- “We standardize where it matters for scale and risk; we localize where it matters for customer and market relevance.”
- “We concentrate scarce expert capabilities into shared platforms rather than duplicating them in each unit.”
- “We reduce management layers wherever they do not add control or coaching.”
- “We design roles that are realistic and sustainable, avoiding spans that are too narrow or too wide for the work.”
Notice that each example points toward specific structural choices and can be used later as a test.
A simple check when drafting principles: if you can imagine both design Option A and Option B claiming to comply with the principle without changing anything, it is too vague. Push it until it would rule out at least some plausible options.
7.2 Co-Creating Principles with the Leadership Team
Design principles only work if the top team believes in them and is willing to live with the trade-offs they imply. That means you should co-create principles with the leadership team; do not write them in a back room and present them as a finished product.
A practical, time-efficient approach is to run one or two focused working sessions.
Step 1: Start from strategy and diagnosis
Begin the session by briefly revisiting:
- The strategic priorities and value agenda.
- The case for change and major organizational issues.
- Any early design hypotheses.
This anchors the conversation in facts and objectives rather than preferences or politics.
Step 2: Elicit design “instincts” from leaders
Ask each leader individually (you can do this as pre-work or live):
- “When you imagine the organization we need in 3–5 years, what are the top 3–5 characteristics it must have?”
- “Which structural features of today’s organization must we absolutely protect?”
- “Which features must we absolutely change?”
Capture answers on a board or shared document. You will see patterns: some leaders will emphasize customer focus, others scalability, others risk management, others speed.
Step 3: Cluster and translate into principle candidates
As a group, cluster similar ideas. For each cluster, try to formulate a principle in the “directional, trade-off-aware, testable” format:
- From “more customer-focused” to “We will organize customer-facing teams so each priority segment has a single accountable owner.”
- From “simpler” to “We will eliminate management layers that do not materially improve control, coaching, or customer outcomes.”
At this stage, do not worry about perfect wording. Aim for rough but substantive statements.
Step 4: Stress-test with real dilemmas
Select a couple of likely design dilemmas you know are coming (e.g., “global vs regional P&Ls,” “embedded vs centralized analytics,” “how many layers in operations”). Ask: “If these were our principles, what would they suggest in this choice?” If a principle gives no guidance or feels obviously wrong when applied, refine it or drop it.
Step 5: Prioritize and finalize
If you have more than 8–10 principles, force-rank them. Ask each leader to pick the top five they are willing to defend in front of their teams. Use the overlap to identify the core set and rewrite them for clarity and consistency.
You will finish with a short list of agreed principles that:
- Reflect the strategy and case for change.
- Express real choices and trade-offs.
- Feel uncomfortable but right to the top team.
That last point matters. If every principle feels easy and cost-free, you have probably stayed at the level of platitudes.
7.3 Translating Principles into Practical Design Tests
Principles only add value if they are actually used during design. The way to ensure that is to translate each principle into a small set of design tests—concrete questions you apply to every option.
Think of each principle as heading a mini “test card”:
- The principle (short statement).
- 2–4 practical tests (questions).
- Any measurable implications or thresholds, if known.
For example, suppose you have the principle:
“We will give each priority customer segment a clearly accountable owner.”
The corresponding design tests might be:
- For each priority segment, can we name one leader who is accountable for segment performance end-to-end?
- Does that leader control enough of the levers (pricing, solutioning, service levels) to be genuinely accountable?
- Do customers in that segment see a single point of contact, or are they still split across units?
Another principle:
“We standardize where it matters for scale and risk; we localize where it matters for customers.”
Design tests:
- For each major activity, have we explicitly decided whether it is standardized or localized?
- Where we localize, is the value to customers or markets clear and material (not just preference)?
- Where we standardize, do we have clear owners and governance to maintain standards?
You can then use these test cards in a very operational way:
- When the design team develops a new macro-structure or micro-structure option, they walk through each test card and mark where the option clearly passes, clearly fails, or is unclear.
- Before steering-committee decisions, the design authority summarizes: “Option A fits principles 1, 2, and 4 well, but conflicts with principle 3 on risk control. Option B is weaker on principle 2 but stronger on principle 3.”
- The top team discusses trade-offs with reference to the principles rather than personal preferences (“I like regional autonomy”) or vague notions (“this feels simpler”).
This is where the testability of principles becomes visible. If a principle cannot be turned into 2–4 simple yes/no or “to what extent” questions, it is too abstract.
A few practical tips:
- Be concrete, not binary perfect. It is rare that an option perfectly satisfies every test. The goal is to compare options and make conscious trade-offs, not to achieve a theoretical optimum.
- Write tests in plain business language. Avoid jargon like “optimizes synergies”; say “reduces the number of customer hand-offs” or “avoids duplicating analytics teams.”
- Use tests consistently. Do not invent new tests in each meeting. Use the same set to evaluate all major options, so people see the logic is consistent.
If you embed these test cards into your design templates and decision decks, principles stop being a poster on the wall and become an active tool.
7.4 Guardrails: Non-Negotiables and Constraints (Regulatory, Financial, Labor)
Design principles describe where you want to go. Guardrails describe where you are not allowed to go, even if an option looks attractive on paper.
Guardrails fall into several categories:
- Regulatory and risk guardrails
These include legal requirements, regulatory expectations, and risk-appetite boundaries. Examples:- Independence requirements (e.g., risk, compliance, internal audit must report outside of certain business lines).
- Segregation of duties (e.g., front-office vs back-office in financial transactions).
- Requirements for local accountable officers in regulated markets.
- Ignoring these leads to designs that will be blocked by regulators or expose the firm to unacceptable risk. Guardrails here should be specific, ideally validated by legal and risk functions.
- Financial guardrails
These set the economic boundaries of the redesign. Examples:- The maximum one-time restructuring budget (severance, relocation, systems changes).
- Minimum cost-savings targets or payback periods, if the redesign is partly cost-driven.
- Limits on adding management layers or overhead roles.
- Financial guardrails should be realistic and consistent with the business case you intend to build. If you set them too tightly, you constrain design creativity; if you set none, you risk designing something unaffordable.
- Labor and employment guardrails
These include collective bargaining agreements, local labor laws, consultation requirements, and internal commitments on how you treat people. Examples:- Notice periods and consultation obligations with works councils or unions.
- Constraints on role relocation across countries or legal entities.
- Internal commitments such as “no forced redundancies in market X” or “we will prioritize redeployment over exit where feasible.”
- These guardrails affect the path of implementation as much as the end-state design. For example, you may decide that a certain end-state structure is right, but you must reach it in phases to respect consultation requirements.
- Brand and stakeholder guardrails
Less formal but still important are commitments to customers, partners, and communities. For example:- Maintaining a physical presence in certain regions.
- Preserving particular customer-facing roles or service levels during transition.
- Avoiding structural moves that could be perceived as abandoning key markets or stakeholder groups suddenly.
- These guardrails are often articulated by the CEO or board. They may constrain how radically you can centralize, outsource, or exit certain activities.
How to define and use guardrails
Defining guardrails is a joint effort between the sponsor, legal, HR, finance, and risk. A practical approach:
- Collect candidate guardrails from each function: “What are the boundaries we must not cross in this redesign?”
- Distinguish hard vs. soft guardrails.
- Hard guardrails: non-negotiable, typically legal, regulatory, or board-level commitments.
- Soft guardrails: strong preferences or norms that can be revisited if the value case is very compelling, but only with explicit top-team discussion.
- Document them clearly. Aim for a one-page “design guardrails” document with two columns: hard and soft. Each guardrail should be specific (“Risk must report at least one level outside of business-unit leadership”) rather than general (“Don’t upset regulators”).
- Use them early in option development.
- When drafting initial macro-structure options, check that none violate hard guardrails. If they do, either change the option or formally escalate to the sponsor to reconsider the guardrail.
- Use soft guardrails as design considerations, not absolute vetoes. If an option breaks a soft guardrail but solves major strategic problems, bring it forward with a clear explanation.
A common mistake is to discover guardrails late—after teams have invested time in designing an option that is then declared impossible. That is demoralizing and slows the program. Put in the effort upfront to surface constraints and get them signed off by the top team.
Balancing ambition and constraints
Guardrails should not become an excuse for incrementalism. Two questions help keep the balance right:
- “Is this guardrail truly non-negotiable, or is it a legacy decision we have never revisited?”
- “If we keep this guardrail, what opportunities are we consciously giving up? Are we comfortable with that trade-off?”
Sometimes the org design effort is exactly the moment to challenge old constraints. You may find that what everyone assumed was a regulatory requirement is actually just a legacy policy, or that a past commitment can be thoughtfully updated. The key is to be explicit and to involve the right stakeholders in any change to guardrails.
