How to Design an Organisation That Can Scale
Most restructures move boxes and leave the decisions where they were. A structure only scales when ownership, decision rights and interfaces are designed together.
Every growing company eventually redraws its org chart. Most of those redraws fail in the same way: the boxes move, the reporting lines change, and six months later the same decisions are being escalated to the same people. The chart changed. The organisation did not.
That happens because a structure is not a diagram. It is four decisions made together — what the organisation must be good at, who owns which outcome, which decisions each role can take alone, and how work crosses the boundaries between teams. Change one without the others and you have moved names around.
Start with principles, not with the chart
Before anyone opens a diagramming tool, the leadership team should agree what the structure has to deliver. Principles are useful precisely because they are contestable: if everyone agrees with your principle, it is not doing any work.
A usable set is short and specific to your business. Examples of the shape they take:
- Speed where the customer feels it. Decisions that affect delivery time sit with the team doing the work.
- Consistency where the cost of variation is high. Pricing, security and hiring standards are set centrally, even at the cost of local speed.
- One owner per outcome. If two teams contribute, one of them is accountable and the other is a contributor.
- Design for the company we expect in eighteen months, and stage the transition rather than implementing it all at once.
Principles are what make structural trade-offs discussable. Without them, a debate about whether Support reports to Product or to Revenue is a debate about personalities.
Assign single-owner accountability
List the ten to fifteen outcomes the business actually depends on this year. Revenue retention. Time to onboard a new customer. Platform reliability. Cost per unit delivered. Hiring the roles in the plan. Now write one name next to each.
This is uncomfortable, which is the point. The outcomes where the exercise stalls are exactly where your organisation is currently paying a coordination tax. Two common patterns emerge:
- Shared ownership. Two leaders both believe they own it. In practice neither can act without the other, so the outcome moves at the speed of their calendars.
- Orphaned ownership. Everyone assumes it belongs to someone else, usually because it sits between functions. These are the outcomes that degrade quietly for a year.
A contributor is not an owner. RACI-style tables fail when they are used to spread responsibility rather than to concentrate it. One accountable name, then as many contributors as the work needs.
Place the decisions, not just the people
Structure determines who reports to whom. Decision rights determine what actually happens. A team can report into the right place and still escalate everything, because nobody wrote down what they are allowed to decide.
For each recurring decision, write four lines: what the decision is, who decides, who must be consulted before it is made, and who is informed afterwards. The third and fourth lines are usually the missing ones, and they are the source of most escalations — a manager escalates not because they lack authority, but because they are unsure who will be upset if they use it.
Size spans and layers deliberately
Spans and layers are the two dials that determine management load. There is no universal correct setting, but there are recognisable failure modes.
| Pattern | What it usually signals | What it costs |
|---|---|---|
| Spans of two or three | A layer created to give someone a title or to solve a retention problem | A management layer that adds review without adding capacity |
| Spans above ten in a coaching-heavy function | A manager promoted with no reduction in individual work | One-to-ones cancelled first, performance issues discovered late |
| Five layers under 150 people | Progression handled through titles rather than through a level framework | Slow decisions, diluted accountability, inflated expectations |
The useful question is not "what is the right number" but "what does this manager have to do?" A manager running a stable operational team can hold a wider span than one developing eight people through a difficult transition. Set spans against the work, and revisit them when the work changes.
Design the interfaces
In companies past about fifty people, most delay is not inside teams. It is between them. Yet interfaces are almost never designed: they are inherited from whatever the first two people worked out between themselves.
Pick the three handoffs that carry the most volume — sales to delivery, product to engineering, delivery to support. For each, write down what is handed over, what "ready" means, who accepts it, and what happens when it is not ready. This is unglamorous work with a disproportionate effect on throughput.
Sequence the transition
A new structure is not live when it is announced. It is live when decisions are being made in the new place. Between those two moments, the organisation runs on the old model regardless of what was communicated.
- Agree principles and the target structure with the leadership team.
- Hold role conversations with every affected manager: what changed in your scope, your decisions and your accountability.
- Publish the ownership map and the decision rights, not only the chart.
- Update the management routines so the new decisions have somewhere to happen.
- Set a review point, and check whether the escalations have moved.
The structure is real when the escalation paths change. Until then, you have published a drawing.
What to do first
If you are looking at a structure that no longer fits, resist the urge to start with the chart. Spend a week on the ownership list and the top ten recurring decisions. In our experience, a meaningful share of what looks like a structure problem turns out to be an undefined decision right, and that is a considerably cheaper thing to fix.
Where the structure genuinely does need to change, that work is part of what we do — and it is worth doing alongside role clarity rather than after it.
Co-founder — Organisation & Operations
Francisco Campos
Built growing companies from the inside: first employee to COO at Onport through its acquisition by Farfetch.
More from Francisco