How to Design an Org Chart That Doesn't Route Through You
Every startup org chart is founder-shaped, and it is not an accident — it is a design that was correct for the first two years and never revisited. You kept the decisions you were best at, left boundaries undefined because you could resolve them personally, appointed two strong leaders and became their tie-breaker. Each choice was efficient in isolation. The aggregate is a company whose throughput is capped by your calendar, which is the most common and most expensive structural error in a growing company. This page is the chart-level fix, as distinct from delegating better.
What’s inside
Every startup chart is founder-shaped by design
The four kinds of dependency a chart creates
How to map yours
The four structural fixes
The two-week test
What should still route through you
Where Blomma fits
Every startup chart is founder-shaped by design
At eight people, routing everything through the founder is optimal. You hold the most context, the highest standard, and the fastest decision loop, and the coordination cost of one decision point is negligible.
The structure is never redesigned because nothing ever forces it. Instead it accumulates: an undefined boundary here because you could resolve it, a decision retained there because you cared most about it, a second strong hire whose scope overlaps the first because you can arbitrate. None of those is a mistake at the moment it happens.
What makes this hard to see is that the resulting problem does not present as a structural one. It presents as other people’s shortcomings — a team that is slow, an executive who does not take initiative, a decision that stalled. Founders in this position typically respond by hiring more senior people, which fails predictably: a senior hire dropped into a chart that routes decisions through the founder becomes an expensive person waiting on the founder, and leaves within eighteen months.
The fix is not more delegation, in the sense of handing over more work. It is changing the chart so that the decisions do not arrive at your desk in the first place.
The four kinds of dependency a chart creates
A chart can make you necessary in four distinct ways. They look the same from inside a busy week and have different fixes.
Authority dependency.Decisions wait for you because nobody else holds the right to make them. Symptom: initiatives described as “waiting on you,” and your calendar as the critical path on unrelated projects.
Integration dependency.You are the only node connected to every function, so anything cross-functional routes to you. Symptom: your week is spent resolving things between other people’s teams, and two leaders who disagree both come to you rather than to each other. This is the one produced most directly by the chart itself.
Information dependency.You hold context nobody else has — customer history, reasoning behind past decisions, what the board actually wants. Symptom: work gets redone after you see it because a constraint surfaces that nobody knew about.
Relationship dependency.You personally hold key customers, partners, or candidates. Symptom: important external relationships have no second point of contact. Often the most business-critical and the least discussed.
Most founders are two or three of these at once. Authority and information dependencies are usually upstream — fixing them frequently dissolves the integration one.
How to map yours
Three exercises, in increasing usefulness. The third is the one that actually produces a fix list.
Audit four weeks of your calendar.For each meaningful item, mark whether you were the decision-maker, the approver, the information source, or the referee between two other parties. The distribution names your dominant dependency type, and it usually surprises founders — most expect authority and find integration or information.
Build the escalation map.This is the highest-value exercise on the page and almost nobody does it. List the fifteen or twenty conflicts most likely to arise in your company — product versus sales on a custom build, engineering versus product on sequencing, two teams wanting the same headcount, a pricing exception, a customer escalation. For each, name where it resolves today. Any conflict that resolves only at your desk is a designed dependency, and the list of them is your redesign specification.
Ask your leads what they are blocked on.In writing, unsoftened, specifically what they are waiting on from you. People minimise this in conversation and are accurate in writing.
The four structural fixes
Matched to the dependency types. Applying the wrong one is why founders report that delegation did not work.
For authority dependency: write down decision rights.A short list of the decisions that matter and, for each, who decides, who is consulted, and what threshold escalates. Then hold to it when you disagree with an outcome — that is the actual test, and overriding once costs you the whole document.
For integration dependency: build the executive team’s capacity to resolve among themselves.Concretely: when two leaders bring you a conflict, send them back to resolve it and report the outcome. Establish a standing forum where cross-functional trade-offs get made without you in the room. And make sure each leader’s scope is defined well enough that the seams are visible rather than ambiguous. This takes about a year and it is the only fix for a company that needs to grow past your bandwidth.
For information dependency: write things down.The reasoning behind decisions, the real constraints, what the board cares about, the history with major customers. The least glamorous and highest-return work available. A few hours of writing removes weeks of downstream rework.
For relationship dependency: add a second owner to every key relationship now.Not a handover — a second point of contact immediately, on every relationship that matters. This one carries genuine business risk, so it should not wait behind the others.
One structural principle underneath all four: draw team boundaries where the traffic is lightest. If two functions need to talk constantly, either put them under one leader or give them an explicit interface. Leaving a high-traffic seam undefined is what makes you the router.
The two-week test
The highest-fidelity diagnostic available, and the only one that produces an unarguable result.
Go genuinely unreachable for two weeks. Not a working holiday — no messages, no exceptions, someone else named for emergencies.
What stalls is your dependency structure, mapped precisely. What people decide in your absence tells you which authority you had been informally withholding. What gets redone when you return tells you where the information dependency is. And the specific things that broke are your fix list, in priority order, with no analysis required.
Most founders find two or three items and are surprised by at least one. A number find that considerably less broke than expected, which is its own useful finding — it usually means the dependency was a habit rather than a structural fact.
Run this before a redesign, not after. A chart drawn from the audit is a guess; a chart drawn from what actually broke is evidence-based.
What should still route through you
The literal version of this advice produces a founder who has designed themselves out of their own company, which is a different failure.
Keep the decisions that are genuinely irreversible or existential: entering a market, a platform commitment with a long tail, senior hires and departures, fundraising, anything that would be very hard to undo.
Keep the standard. What quality is acceptable, what behaviour is not, who you are willing to hire. Nobody else can hold this line, and a chart that distributes it produces a company with several cultures.
Keep direct contact with customers and enough depth somewhere to smell when something is wrong. Not review authority — contact. This is where founders retain the judgment that makes them better than a hired operator.
And keep the ability to override, used rarely and explained. That is a real advantage over a purely professional CEO, provided it does not become how you operate by default. Used often, it teaches everyone that the chart is decorative.
Where Blomma fits
The structural work above is not intellectually difficult. What makes it hard is that each fix is a specific conversation and a specific act of restraint — telling two leaders to resolve something themselves and not adjudicating when they come back, handing a decision over and holding to it three weeks later when the outcome is worse than yours would have been.
Blomma is an always-on AI career coach with no stake in how you run your company. Use it to build the escalation map honestly, including the paths you would rather believe do not end at your desk. Use it to work out which dependency type you actually have, which is the diagnosis founders most often get wrong. Use it to draft the decision-rights list specifically enough that it holds under disagreement. And use it in the moment that decides whether any of this takes — the fortnight after a handover, when something goes visibly wrong and every instinct says step in. Where the situation warrants a human who has redesigned around themselves at your stage, bring one in..
An org chart is a set of decisions about where decisions live. If most of the hard ones live with you, that is not a fact about your company’s maturity — it is a design from three years ago that nobody has revisited.