Everyone reports to the founder: when and how to redesign the structure

A founder described his structure to me as flat and deliberate: twenty-two people, no middle layer, everyone able to reach him. He was proud of it, and it had worked for years. Then he listed his week — two leave approvals, a price exception, a hiring decision, a customer escalation, an argument between two team leads, and a question about whether someone could take Friday off.

The structure had not changed. What had changed is that twenty-two people generate more decisions than one person can hold, and the ones that waited were not the unimportant ones. They were whichever arrived while he was on a customer call.

There is no headcount at which a flat structure stops working. A single-site team of eighty can stay flat longer than a thirty-person business across two locations and two shifts. What matters is how many decisions need you and what happens to them when you are not there.

• Work stops when you travel. Two days away produces an evening of approvals, and people have learnt to batch requests around your calendar.
• You are both the first point and the escalation point. There is no step between an employee's question and you, so everything arrives as an escalation.
• Managers ask you about their own team members. Whether someone can take Friday off is a question their manager should settle.
• Two people are quietly doing overlapping work while a third activity fails every few months because it was never anybody's job.
• You promoted someone and changed nothing else. They still carry their old work, and the team they nominally lead is still managed by you.

Three or four of those together is the point at which structure has become the constraint rather than a preference.

Founders hear structure and imagine a reorganisation — new titles, a new chart, an announcement, and the disruption that follows. In practice the useful version is much smaller and almost entirely about writing down what already exists.

1. 1

   List the decisions, not the people

   Spend an hour listing every decision that reached you last month. Leave approvals, purchases, exceptions, hiring, pricing, escalations. This list is the design brief, and it is more honest than any org chart.

2. 2

   Sort them into three piles

   Decisions that genuinely need the owner. Decisions that reached you only because no route existed. Decisions that should not need anyone senior at all. The second pile is almost always the largest and is where the work is.

3. 3

   Name who else could decide each one

   By role, not by name, so the answer survives the person. For most items in the second pile, somebody obvious already exists.

4. 4

   Put a limit on it

   Approve leave up to a length; approve spend up to an amount; commit to a joining date but not a salary. Limits are what make delegation safe enough to actually do.

5. 5

   Write the reporting lines that follow

   Only now does the chart matter, and by this point it mostly draws itself — because you have already worked out who decides what.

6. 6

   Say it out loud

   A structure people have not been told about is a document. Brief the managers first, because they are the ones who will be asked.

DECISION                 REACHED ME   SHOULD SIT WITH   LIMIT
------------------------------------------------------------------
Leave up to 3 days       12 times     Reporting manager  -
Leave beyond 3 days       3 times     Function head      -
Salary advance            5 times     Function head      up to ___
Purchase                  9 times     Function head      up to ___
Offer to a candidate      4 times     Founder            keep
Price exception           6 times     Sales head         up to ___%
Customer escalation       7 times     Function head      escalate if ___
Hiring approval           3 times     Founder            keep

Anything reaching you more than twice a month that is not in
the 'keep' column is a route that has not been written down.

The right-hand column is the whole output. Most founders find that two-thirds of the list moves, and that the third which stays is genuinely theirs — which is a far better use of the evening than leave approvals.

The commonest structural failure in a growing business is not the absence of a layer. It is a layer that exists on paper and not in practice: the best salesperson made sales head, still carrying their own accounts, with nobody actually managing the team.

That is not fixed by another promotion. It is fixed by deciding what the role now owns and what it stops doing, and by accepting that the individual output the person was promoted for will fall. Businesses that do not accept that trade end up with a manager who is neither managing nor producing at their old rate. Settling what the role owns is role design and job descriptions work, and it usually has to happen alongside the structure rather than after it.

The most expensive sequence is to hire three people into an undefined structure and then design around whoever arrived. Their scope gets shaped by what they turned out to be good at, and two years later the business has roles that exist because of a person rather than a need.

Designing first — even roughly — means you hire against a defined role. That is also what makes the job description worth writing, because it describes something decided rather than something observed. This whole sequence, from decision inventory to reporting lines to approval limits, is what organisation design work does, and its output is usually a page of limits rather than a new chart.

Two things, one comfortable and one not. Approvals start moving without you, which is the point. And a handful of decisions come back wrong, because a limit was set without enough thought.

Handle the second by reviewing the first month's decisions together, not by withdrawing the limits. Most corrections are a sentence added to a rule. Founders who abandon delegation usually do it in week three after one bad approval, and then spend another two years in the queue.

Expect people to test the new route once, too. Somebody will bring you a decision their manager has already made. What you do the first time that happens is what settles whether the structure holds — and sending it back, visibly, is worth more than any amount of briefing. Where the same decisions keep escaping the route, it is usually a sign the limits are too tight rather than that people are ignoring them, which is the kind of thing an HR process audit surfaces quickly.

The redesign conversation focuses on what moves away, and produces a predictable anxiety about what is left. Being explicit about what a founder should retain makes the rest easier to let go of.

Three things are usually worth keeping regardless of size. Anything that changes the shape of the business — new sites, new lines, significant structural change. Senior hires, at least the final conversation, because the cost of a wrong one at that level is carried for years. And the pay framework, meaning the structure and the principles rather than each individual decision.

Everything else is delegable, and the test is whether a reasonable, informed person could make the decision and be wrong without lasting damage. Most operational people decisions meet that test, which is why they are the first to move.

What founders most often keep and should not is the exception. Retaining the right to override any decision, on any matter, is functionally the same as retaining every decision, because everyone routes around the manager to the person who can say yes. Keeping three named categories and genuinely releasing the rest works. Keeping a general veto does not, and it is the most common reason a redesign that looked complete on paper changes nothing in practice.

None of this is a one-off exercise. Structure drifts as the business grows — a new site, a departure, a function that quietly absorbed another's work — and the decision inventory is worth repeating once a year. It takes an hour and it is the cheapest diagnostic a founder has. Where it shows the same decisions returning to your desk twelve months on, the limits were written but never held, and that is a different conversation from the one organisation design work starts with.