Organizational Design for Startups: A Founder's Guide
Almost no startup org chart is designed. It accumulates. Someone good needs a title, a team gets too big for one manager, a strong hire arrives and gets a group built around them, and eighteen months later you have a structure nobody chose and nobody can defend. The cost shows up as coordination overhead: more meetings, slower decisions, more things needing you, and a general sense that adding people is not adding output. This page is about treating structure as a design problem with explicit trade-offs — what the four real questions are, what each common structure optimises for, and how to test a chart before you inflict it on people.
What’s inside
Org design is decision design
The four questions that constitute org design
The structures, and what each optimises for
How to test a chart before you ship it
How to change a structure without wrecking morale
The founder-shaped mistake
When to redesign, and when to leave it alone
Where Blomma fits
Org design is decision design
The useful definition of org design is not boxes and reporting lines. It is: which decisions get made where, by whom, with what information.
Everything an org chart does follows from that. Reporting lines determine whose priorities win when two conflict. Team boundaries determine which decisions can be made inside one group and which require negotiation between groups. Layers determine how far a decision travels before someone can approve it. When founders complain about slow decisions, unclear ownership, or endless alignment meetings, they are describing a structural condition, not a cultural one.
This reframing has an immediate practical benefit. “How should we structure the company” is unanswerable in the abstract. “Which decisions are slowest and most contested, and what structure would put them inside one team” is answerable, and it produces a chart rather than a debate about philosophy.
The corollary is that every structure is a choice about what gets to be easy. There is no structure without trade-offs, and any proposal presented as having no downside has an unexamined one.
The four questions that constitute org design
Four questions cover the substance. Answer them in this order — most founders start at the fourth, which is why they end up with a chart built around people rather than work.
What decisions must this company make well and fast?List them concretely: pricing, roadmap prioritisation, hiring bar, architecture, customer escalations, spend. Then note where each currently gets decided and how long it takes. This list is the specification your structure has to satisfy.
Where should each decision live?For each, name the smallest group that holds enough information and enough authority to make it. Decisions that require three teams to agree are the ones your structure is getting wrong.
What interfaces does that create, and can they hold?Every boundary you draw creates a handoff. Structure is the choice of which handoffs you are willing to pay for. Draw the boundary where the traffic is lightest — put the highest-communication work inside one team, and accept the cost at the quieter seams.
Who has the capacity to hold each group?Only now do people enter. Check spans honestly, weighted by how much attention each report actually consumes, and check whether managers who are also senior contributors are being asked to do two jobs.
A chart that answers these four is defensible. A chart that starts from who deserves what is a compensation decision wearing a structure costume, and it will produce coordination problems that no amount of process fixes.
The structures, and what each optimises for
Four shapes account for most startup structures. None is correct in general; each is correct for a particular constraint.
Functional — engineering, product, sales, marketing as separate groups.Optimises for craft depth, consistent standards, and clear career paths. Costs you cross-functional speed: anything requiring three functions requires three managers to agree. Right for most companies under roughly fifty people, and for companies with one product where quality of craft is the differentiator.
Cross-functional pods or squads — mixed teams owning an outcome.Optimises for speed on a defined outcome, because the whole decision lives inside one team. Costs you consistency and depth: five pods will build five conventions and each discipline loses its centre of gravity. Right when you have several distinct customer problems that can be worked in parallel.
Divisional — self-contained units by product, segment, or geography.Optimises for autonomy and accountability at scale, and gives you clean numbers per unit. Costs duplication and makes shared platforms hard. Rarely right below a couple of hundred people; sometimes right earlier with genuinely unrelated business lines.
Matrix — dual reporting into function and outcome.Optimises for both craft depth and outcome focus, in theory. Costs an enormous amount of clarity, and works only with genuinely explicit decision rights, because otherwise every conflict escalates to the one person both lines report through — which is usually you. Most startup matrices are unresolved matrices, and unresolved matrices route everything to the founder.
The question is never which is best. It is which constraint you are currently paying most for, and which structure relieves it at a cost you can live with.
How to test a chart before you ship it
A new structure looks clean on a slide. Run these four tests before anyone hears about it.
Walk your real decisions through it.Take the six decisions from question one and trace each through the proposed chart. Name who decides, who is consulted, and how long it takes. Any decision that still requires three groups to agree has not been fixed — you have moved the boxes without moving the decision.
Count the escalation paths that end at you.For each likely conflict, ask where it resolves. If more than a couple resolve only at your desk, you have designed a structure that requires your continuous presence, which is the most common and most expensive startup org design error.
Weight the spans honestly.Count reports, then adjust for new hires, dissimilar work, tight interdependence, and managers carrying their own delivery load. A chart showing six reports can be a real span of eleven, and the first thing that breaks is development.
Name the trade-off out loud.Write one sentence: “this structure makes X faster and Y slower, and we are accepting that because Z.” If you cannot complete the sentence, you have not designed anything — and you will not be able to explain it to the company either, which is where most reorgs actually fail.
How to change a structure without wrecking morale
The design is the easy part. Implementation is where reorgs go wrong, and they go wrong in predictable ways.
Lead with the problem, not the chart. People accept structural change when they recognise the problem it solves. If the first thing they see is a new diagram, they will read it as politics and immediately calculate their own position.
Sequence the conversations. Anyone whose scope, manager, or title changes hears it individually and first. Finding out in a group announcement is the specific event that produces resignations, and it is entirely avoidable.
Be explicit about what is not changing. Uncertainty expands to fill available space. Naming the boundaries of the change reduces the amount of the company that treats it as personally relevant.
Name the losses. Every reorg costs someone something — scope, proximity, a manager they liked. Saying so plainly is what makes the rest of the message credible. Pretending it is upside for everyone is what makes people stop believing you.
Set a review date. “We will look at this in a quarter and adjust” is honest, and it lowers the stakes of getting details wrong. It also stops the next necessary change from feeling like an admission that this one failed.
And resist reorganising more than roughly annually. Structural change has a real cost in relationships, context, and trust. A company that reorganises every six months teaches everyone that structure is weather.
The founder-shaped mistake
There is one error nearly every founder makes, and it is worth naming directly: designing a structure that only works with you in the middle of it.
It happens without intent. You keep the decisions you are best at. You leave a boundary undefined because you can resolve it personally. You appoint two strong leaders and become their tie-breaker. Each individual choice is efficient. The aggregate is a company that cannot make progress on any hard question without you — which means your calendar becomes the company’s throughput limit, and no amount of hiring changes that.
The test is a fortnight’s absence. What stalls is your structure’s dependency on you, mapped precisely. Most founders find two or three items and are surprised by at least one.
The fix is not less involvement. It is naming the specific decisions that route through you, then either assigning them explicitly to someone else or building an explicit rule for them. Vague delegation does not work here, because everyone reverts to the founder under pressure unless the alternative is written down.
When to redesign, and when to leave it alone
Not every problem is structural, and reorganising is expensive. Some genuine signals:
Decisions consistently need three or more groups. Two teams both believe they own the same outcome, or neither does. Your best people are spending most of their time coordinating rather than working. The same conflict escalates to you monthly. Headcount is up materially with no corresponding rise in output. Or a span audit shows managers running far wider than the chart implies.
Signals that are usually not structural: one team underperforming (often a management or clarity problem), a single strained relationship between leaders, a bad quarter, or a specific person being unhappy with their scope. Restructuring to solve an individual problem is how companies acquire permanently strange org charts.
The honest version of this question is whether you are redesigning because the structure cannot support the decisions the company needs to make, or because a structural change is an easier thing to do than a conversation you have been avoiding. Both happen. Only one of them helps.
Where Blomma fits
Org design decisions are made in the least honest room in the company. Everyone with an opinion has a position — scope, title, headcount, proximity to you. Your executives cannot advise you neutrally on a chart that determines their own scope, and asking them to is unfair to them and unhelpful to you.
Blomma is an always-on AI career coach with no stake in your structure. Use it to run the four questions properly, to pressure-test whether a proposed chart actually relocates the decisions or just the boxes, to find the escalation paths that quietly end at your desk, and to prepare the sequence of individual conversations a reorg requires — including the one with the leader whose scope is about to shrink. Where the situation warrants someone who has designed at your stage, bring in a human coach..
There is a second reason this matters. Structure determines how much managerial attention each person receives, which determines how much development happens in your company. Designing spans without deciding where coaching comes from is how companies end up with a thin internal bench two years later and no obvious cause.
Good org design is not a chart. It is a set of decisions about where decisions live, made explicitly, with the trade-offs named. Do that, and structure stops being the thing you are always about to fix.