Open the org chart of almost any service business under 100 people and you'll see the same thing.
A box at the top with the owner's name. Boxes underneath with the names of senior team members. More boxes underneath them with the next layer's names. Lines connecting the boxes. The whole document is, structurally, a staff directory with a hierarchy drawn on top. It tells you who reports to whom. It is, in the most literal sense, an organisation chart, a chart of the current organisation.
It's also broken in a specific way that almost nobody notices until somebody leaves. When Sarah, who is "Senior Estimator" in the box, departs, the org chart now has a problem. Do you replace the box with a new name? You can, but the replacement is going to be a slightly different shape than Sarah was, because the box was implicitly designed around what Sarah did, which was some custom blend of estimating, mentoring, vendor liaison, and a half-dozen unwritten things Sarah picked up in her years there. The new person fills the box, but the box has now subtly changed to fit them. The whole structure drifts, one departure at a time, until the org chart is documenting a business that no longer exists.
The fix is to invert the design. The org chart should describe roles, not people. People sit in roles. When a person leaves, the role stays. The next person fills the role, not the previous person's bespoke job. The business is being designed, not just staffed.
Why person-to-person org charts fail
Three failure modes, in roughly the order they show up.
1. The job description writes itself around the person. When you hire to replace Sarah, the job description ends up being "do what Sarah used to do." The shape of the role is implicitly inherited from the person, not the business. Over years, this means every role in the company has been gently shaped by the personality of whoever last held it, instead of designed for what the business actually needs.
2. Promotions and succession become brittle. When the COO retires and you look for an internal replacement, you're looking for someone who can do what the COO did, which is a custom-shaped role nobody else has. The successor "doesn't quite fit," not because they're not qualified, but because nobody is going to fit a role that's been customised to one specific person over twelve years.
3. The business can't be evaluated independently of the team. A buyer in diligence asks "what does the operations function actually need to look like?" and the only available answer is "ask the current ops lead, they'll explain." That's an answer that says the business is the team, not a designed thing. Sophisticated buyers (and sophisticated lenders, partners, board members) discount businesses that can't be evaluated outside their current staffing.
What role-based looks like
A role-based org chart looks superficially similar to a person-based one. Boxes, lines, hierarchy. The change is in what's in the boxes.
The box says "Senior Estimator" before it says "Sarah Chen." If Sarah leaves, the box is still "Senior Estimator", the design hasn't changed, the chair is now empty. The role has a written charter (we'll cover that in the next article) that describes what the role exists to do, what authority it carries, what decisions it makes, what outputs it produces, and what it depends on from other roles. The charter outlives the person.
The visible cues:
- Roles are named before people are named. The chart can be read coherently with the names removed. If removing the names makes the chart unreadable, it was a person chart, not a role chart.
- One person can hold more than one role. In a small business, the same human might wear the "Operations Lead" hat and the "Quality Owner" hat. That's fine. As the business grows, the roles separate. The chart shows the separation in advance, even when the same person is currently in both.
- Roles can be vacant. The org chart can have boxes nobody is currently sitting in. This is uncomfortable for some founders to look at but it's honest. It says "we have a role here we haven't yet filled" or "we're growing into this role." Both are useful signals.
- The chart reflects how the business will run, not how it currently runs. A growing business has a chart that's slightly ahead of reality. As you fill the roles, the chart and reality converge.
Types of org structure (and where each fits)
Once you're designing roles instead of mapping people, you have to decide what overall structure they sit in. Four main patterns.
| Structure | What it is | Best for | Breaks down at |
|---|---|---|---|
| Functional hierarchy | Classic pyramid. Each role reports to one manager. Departments organised by function (Sales, Operations, Finance). | 10 to 250 employees, single line of business, stable services. | Multi-business-unit complexity; cross-functional dependencies overwhelm the lines. |
| Matrix | Roles report to two managers: a functional one and a project/client one. Dotted-line and solid-line accountability. | Project-heavy businesses, professional services with strong client teams, businesses with cross-functional resource pools. | When the two reporting lines conflict and there's no clear escalation. Most matrices fail on conflict-resolution. |
| Flat | Few or no managers. Most roles report directly to leadership. Heavy reliance on individual contributors with broad scope. | Very small teams (under 15) or specific innovation contexts (small product squads inside larger orgs). | Around 15-25 people. Leadership's span of attention becomes the bottleneck. |
| Holacracy / circular | No managers; roles organised in self-governing circles with rotating decision authority. | Specific tech and creative cultures with high autonomy norms. | Service businesses where customers want a clear point of contact and accountability runs cleanly to a named owner. We rarely recommend this for SMB services. |
For service businesses in the 10 to 100 employee range, which is most of who we work with, the right answer is almost always a functional hierarchy with explicit cross-functional working norms layered on top. It's not exciting. It's not on the cover of Harvard Business Review. It works.
The E-Myth connection
Michael Gerber's The E-Myth Revisited is, in 2027, still the single most useful book on small-business operating design. The argument is two pieces.
First piece: most small-business owners aren't entrepreneurs. They're technicians, people who were good at a craft and decided to start a business doing that craft. The technician's instinct is to keep doing the craft, and to hire people who can also do the craft, and to run the business as a slightly larger version of one person doing the craft. The business never escapes the technician's hands. It's a high-effort job, not a self-running asset.
Second piece: the way out is to design the business as if you're going to franchise it. Even if you never plan to franchise, the franchise mindset forces a specific discipline. Every role gets a defined shape. Every process gets documented. The business becomes a thing that could, in principle, be replicated. The act of designing it that way produces a business that runs better even if you never replicate it.
The role-based org chart is the structural backbone of the franchise-mindset design. You can't design a franchisable business around bespoke jobs shaped to specific people. You have to design it around roles that any reasonable hire could fill, given the right training and the right Playbook. The org chart is where that design lives.
If you've read Gerber and want a contemporary version of how to operationalise the franchise mindset without literally franchising, that's most of what we do at Expansive EDGE. The role-based org chart is Step 1.
Why the org chart is foundational
This is the part most owners don't expect. The org chart isn't a bureaucratic artefact. It's the structural design that informs at least two other major pieces of your operating system.
It informs your role charters.
A role charter is the working document for what a role does, decides, owns, and depends on. You can't write a coherent role charter without the surrounding org chart, because the charter has to describe what the role hands off to and receives from neighbouring roles. Try to write role charters before the org chart is settled and you'll write the same role three different ways depending on which neighbour you're describing it next to. The org chart locks the relationships; the role charters describe what each role does inside its locked relationships. We'll cover role charters in detail in the next article in this series.
It informs the structure of your knowledge hub.
A Playbook organised around people doesn't survive turnover. A Playbook organised around roles does. The "Senior Estimator's guide to scope review" section keeps existing whether Sarah or her successor is in the role. The org chart tells you what role-based sections your Playbook should have, and the navigation structure of your knowledge hub should follow it. A business where the org chart and the Playbook are aligned on the same role taxonomy is dramatically easier to operate and dramatically easier to scale.
If you skip the org-chart design step and try to build role charters or a knowledge hub directly, both will drift over time because they're being built on a foundation that's still moving. Get the org chart right and lock it before the other two pieces. Re-visit the org chart whenever the business structurally shifts (acquisition, new service line, major scale move) and then propagate the change downstream.
How to actually build one
A practical sequence that works.
- Start with the business model, not the current team. What does the business actually do? Which functions are essential? Sales, operations, delivery, finance, people, technology. Map the functions before you map roles.
- Identify the roles each function needs at your current scale and one scale point ahead. At 35 people, you probably need a Sales Lead, two Senior Estimators, and four Estimators. At 75 people, you'll probably also need a Director of Sales, a Pricing Lead, and a dedicated CRM Admin. Draw both layers so you can see what's coming.
- Name the roles in terms of outcomes, not job titles. "Owner of customer onboarding" is more useful than "Onboarding Manager." The outcome anchors the role. The title is decoration.
- Draw the chart with empty boxes first. Then place the current people. Some people will fill multiple boxes. Some boxes will be vacant. That's data.
- Compare to today. Find the gaps. The gaps between your designed chart and your current reality are the work to do. Sometimes the gap closes by training. Sometimes by hiring. Sometimes by recognising that a role doesn't exist yet but should.
- Get the leadership team to confirm the design before propagating. The org chart is a leadership decision, not a consultant deliverable. It needs to be owned at the top before role charters and Playbooks build on it.
Tooling for the chart itself is unimportant. Lucid, Miro, Whimsical, even PowerPoint with rectangles. What matters is that one canonical version exists, is owned by a named person (usually the COO or the founder), and gets updated when the structure changes. Multiple versions floating around in different tools is worse than no chart at all.
The bigger frame
The instinct to think of an org chart as "who reports to whom" is what keeps service businesses stuck at the size of their founder's bandwidth. The shift to thinking of an org chart as "what shape is the business when it's running properly" is what unlocks scale.
It also unlocks everything downstream. The role charters become writable. The Playbook becomes structurable. The knowledge hub becomes navigable. The succession conversation becomes possible. The diligence question "what does this business actually look like, independent of who's in it today" gets a real answer.
Start there. Before the role charters, before the Playbook, before the dashboard. The org chart is the foundation. Get it right and everything else stops fighting you.