Organisational structure that scales: a practical design guide
Most restructures move boxes and leave the decisions where they were. A structure only scales when ownership, decision rights and interfaces are designed together.
An organisational structure that scales is four decisions taken together: what the company has to be good at, who owns each outcome, which decisions each role can take alone, and how work crosses the boundary between teams. The org chart is only the picture of those four. Move the boxes without moving the decisions and, six months later, the same escalations arrive at the same desks.
Every growing company eventually redraws its chart, and most of those redraws fail in exactly that way. The reporting lines change, the announcement is well received, and nothing about how the company decides is different. The chart changed. The organisation did not.
An organisational structure starts 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.
Org charts by company size: three structures
The three sketches below are generic and deliberately plain. They are not a target to copy; they are a way of seeing what changes as a company grows, which is mostly the fourth column. Structure looks similar at every size. What differs is which decisions have been let go of.
Around 20 people
| Function or team | Reports to | People per leader | Decisions it holds |
|---|---|---|---|
| Founder or managing director | The board, or nobody | Four direct reports | Pricing, senior hiring, anything that changes the plan |
| Delivery or operations | Founder | Six to eight | How the work is scheduled and staffed, week to week |
| Product or engineering | Founder | Four to six | Technical choices and sequencing inside an agreed quarter |
| Commercial | Founder | Three to four | Discount inside an agreed floor, which opportunities to pursue |
| Finance and administration | Founder | One to two, often part-time or outsourced | Payment runs inside budget, supplier choice under a threshold |
At this size the structure is honest: the founder is the integration layer, and that is efficient. The failure mode is not the shape, it is leaving it in place at fifty.
Around 60 people
| Function or team | Reports to | People per leader | Decisions it holds |
|---|---|---|---|
| Chief executive | The board | Five direct reports | Plan, structure, senior hires, pricing policy |
| Head of delivery | Chief executive | Two team leads, about twenty people in total | Capacity, delivery standards, escalation of a client issue |
| Team lead, delivery | Head of delivery | Eight to ten | Allocation, day-to-day quality, first line of escalation |
| Head of engineering | Chief executive | Twelve to fifteen across two squads | Architecture, release, on-call rota |
| Head of commercial | Chief executive | Eight to ten | Pipeline, discount inside policy, partner choice |
| Head of finance and people | Chief executive | Three to four | Payroll cycle, budget tracking, the hiring process itself |
The second layer appears here, and with it the first real test: a team lead who cannot decide allocation is a coordinator with a manager title. This is also the point at which the founder has to stop being consulted on everything in column four, which is a harder change than drawing the box.
Around 150 people
| Function or team | Reports to | People per leader | Decisions it holds |
|---|---|---|---|
| Chief executive | The board | Six direct reports | Portfolio, structure, senior hires, capital allocation |
| Operations director | Chief executive | Three managers, about sixty people | Operating standards, escalation policy, capacity by region |
| Manager, delivery unit | Operations director | Fifteen to twenty, through two team leads | Staffing, unit budget, promotion proposals |
| Head of product | Chief executive | Ten to twelve | Roadmap inside agreed priorities, build or buy under a threshold |
| Head of engineering | Chief executive | Thirty to thirty-five across four squads | Architecture, platform investment, release policy |
| Head of commercial | Chief executive | Twenty to twenty-five, through two managers | Territory, pricing inside policy, partner agreements |
| Head of finance | Chief executive | Five to six | Budget process, approval thresholds, reporting cadence |
| Head of people | Chief executive | Three to four | Pay bands, hiring standards, the performance cycle |
Three layers, and no more than three, is usually enough at this size. If you are drawing a fourth, check whether it exists because the work needs it or because someone needed a title, and read the middle column before you decide.
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. If you want an outside reading of which of the two you are actually looking at, that is what a People Diagnostic produces.
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