Key points
- A design principle is only useful if it helps you reject an option; most published lists are too generic to do that.
- Structure is one lever among several, and a new chart without matching changes to decisions, processes and rewards rarely changes performance.
- Design the organisation before placing people in it, or the structure will be built around individuals rather than the work.
- Spans and layers compound quickly, so small differences in average span change the number of managers and levels significantly.
Almost every organisation design document I read opens with a list of principles. Align with strategy. Clear roles. Customer focus. Agility. Nobody disagrees with any of them, and that is the problem. A principle everyone agrees with in the abstract rarely helps a leadership team choose between two real structures.
This article offers principles I have found hold up when the decisions get difficult: when two executives want the same function, when a new sector needs a home, or when the chart has more managers than the work justifies. For each one, I give the test that makes it useful, and I finish with a checklist you can apply to any design on your table.
If a principle cannot help you reject an option, it is a slogan, not a principle.
Structure is one lever, not the whole design
Before the principles, a warning. Many restructures fail because leaders treat the organisation chart as the design. Galbraith's Star Model is a useful reminder that structure is one of five connected elements: strategy, structure, processes (including how decisions are made), rewards, and people practices. Change one without the others and the old behaviour returns.
I see this regularly. An entity flattens its hierarchy, but approvals still go to the top because the delegation of authority matrix was never updated. A group creates regional business units, but bonuses remain tied to group results, so regional heads have no reason to act like owners. The chart changed. The organisation did not.
So treat the principles below as structural principles that sit inside a wider design. When you change structure, ask what must also change in decision rights, processes, measures and rewards for the new structure to work.
Eight principles and the tests that make them useful
1. Design from the strategy, and be specific about it
"Align with strategy" is meaningless until you name what the structure must be best at. Is it cost efficiency, speed of service, deep specialist expertise, local responsiveness or innovation? These pull in different directions. A structure optimised for efficiency centralises and standardises. One optimised for responsiveness pushes resources and decisions outwards.
The test: can the leadership team agree on the two or three capabilities the design must prioritise, in ranked order? If they cannot, stop drawing charts and resolve that first.
2. Group together the work that needs the most coordination
The biggest structural choice is the primary grouping: by function, product or service, customer segment or geography. Whatever you choose, the boundaries between units will be where coordination is hardest. So put inside the same unit the work that most needs to be coordinated, and accept that other connections will need processes, committees or shared roles to hold them together.
The test: for each option, list the three most important handoffs in the organisation. Does the design keep them within a unit, or does it put them across boundaries? For a deeper comparison of the main models, see choosing an organisation structure.
3. Design decision rights as well as boxes
A chart shows reporting lines. It does not show who decides. Yet most of the friction I see in organisations comes from unclear decision rights: who approves a hire, who sets the budget for a shared service, who can sign off a price change.
The test: take the ten decisions that matter most to your strategy and map them with a simple tool such as RACI. If more than one unit believes it is accountable for the same decision, or if every decision escalates to the CEO, the design is not finished.
4. Set spans and layers deliberately
Span of control and the number of layers are linked, and small differences compound. The right span depends on the work. Managers of similar, routine work can lead large teams. Managers of complex, specialist work need smaller ones. What does not work is letting spans drift narrow because new positions were created to reward individuals or to give someone a title.
Here is a worked example. Say an organisation has 2,000 people.
| Average span | Approximate number of managers | Approximate layers below the CEO |
|---|---|---|
| 4 | around 500 | 6 |
| 7 | around 285 | 4 |
The numbers are simplified, but the direction is real. Moving from an average span of four to seven removes about two layers and over 200 management positions. Each layer adds approval time and distance between leadership and the front line.
The test: calculate average spans and count layers by unit. Investigate any manager with only one or two direct reports, and any unit with more layers than its size explains.
5. Give every outcome one accountable owner
Duplication creeps in quietly. A strategy team at the centre and another in each sector. A central HR function and a shadow HR team in the largest business unit. A digital unit and an IT department with overlapping mandates. Each duplication creates rework, conflict and confusion about who is responsible.
The test: list the organisation's main outcomes and services. For each, can you name exactly one unit that is accountable? Where two can be named, decide which one owns it and redefine the other's role.
6. Design the organisation before placing people in it
This is the principle broken most often, and it is especially tempting in family groups and government entities where senior relationships run deep. Leaders start the design with names: this director needs a sector, that executive cannot report to that one. The result is a structure shaped around individuals that becomes unworkable as soon as they move on.
The test: can you present the structure without names and defend every unit on the basis of the work? Design the roles first, then assess people against them. Where a genuine exception is needed for a person, make it visible and temporary.
7. Keep the centre clear about what it does
In holding companies, multi-business groups and ministries with affiliated entities, the corporate centre is often the least designed part of the organisation. It grows by accumulation and ends up both controlling too much and adding too little.
The test: for each central function, is its role defined as one of setting policy, providing a shared service, or overseeing performance? Functions that try to do all three, for everyone, are the ones that slow the organisation down.
8. Build in the ability to change
No design lasts forever. Strategy shifts, entities grow, and new technology changes the work, including work that AI agents may take on. Design for the next three to five years, not for permanence, and create mechanisms that let the organisation adapt without a full restructure every time.
The test: does the design include a review point, clear criteria for creating or closing units, and flexible resources such as project teams or centres of expertise that can be redeployed as priorities change?
A checklist to test any design
Use this table in the room when leadership is comparing options. For each option, answer the question and look for the warning sign.
| Principle | Test question | Warning sign |
|---|---|---|
| Strategy | What must this design be best at, in ranked order? | Every capability ranked equally |
| Grouping | Are the critical handoffs inside units? | Key processes cross three or more units |
| Decisions | Who is accountable for the top ten decisions? | Two owners, or none |
| Spans and layers | What are average spans and layer counts by unit? | Many managers with one or two reports |
| Accountability | Does each outcome have one owner? | Parallel teams with similar mandates |
| People last | Can the design be defended without names? | Units that only make sense for one person |
| Centre | Is each central function's role defined? | Centre both controls and duplicates delivery |
| Adaptability | How will the design change over time? | No review point, no criteria for new units |
An option that fails several of these tests is not ready, however attractive its chart looks.
The mistakes I see most often
Some patterns recur across sectors and countries.
Restructuring to solve a people problem. If a unit underperforms because of its leader, moving boxes will not fix it. Deal with the performance issue directly.
Copying a benchmark. A structure that works for a peer reflects that peer's strategy, scale and history. Benchmarks are useful for spans, ratios and ideas. They are not a design.
Announcing the chart before the detail. When the top-level structure is announced before roles, decision rights and processes are designed, people spend months in uncertainty and the informal organisation fills the gap.
Designing only the top two levels. The design is not complete until the level where the work is done has been worked through. That is where most of the cost, and most of the service experience, sits.
Where to start
- Get the leadership team to agree, in ranked order, the two or three capabilities the organisation must be best at.
- Map the ten most important decisions and who currently owns each one.
- Calculate spans and layers across the organisation and flag outliers.
- List units or teams with overlapping mandates and decide on a single owner for each outcome.
- Test your current structure, or any option you are considering, against the checklist above before drawing anything new.
If you would like an independent view of your current design, or support building a new one that holds up in practice, Humanyx works with leadership teams across the GCC on exactly this.