How to structure a 30–90 engineer organization

Most engineering reorganizations between thirty and ninety people are solving the wrong problem. The team thinks it has a structure problem. What it actually has is a leadership-bandwidth problem, or an alignment problem, or a hiring problem dressed up as a structure problem.

I have lived through, designed, and audited enough of these to have a strong opinion: at this size, the right answer is rarely a clever new shape. It is almost always one of three boring shapes, plus an unflinching honest answer to the question what is the actual problem we are solving?

This essay walks through the three shapes that work, the patterns that almost always fail, and the three questions to answer in writing before you announce anything.

Why thirty to ninety is its own regime #

Engineering orgs change shape twice as they grow. The first transition is around fifteen to twenty engineers: the founder can no longer keep the whole system in their head, and you need engineering managers. The second is the one most leadership teams under-prepare for — somewhere between forty and sixty, the org becomes too large for any single human (including the CTO) to know all the work in flight.

Below thirty, you can mostly run an org through informal alignment. The CTO walks the floor, weekly all-hands carries enough context, hiring is a manageable side-quest. Above ninety, you are running a different kind of organization — multi-layer management, formal planning rituals, an engineering operations function. The work changes character. The org chart starts to actually mean something.

The thirty-to-ninety range is the unstable middle. The mechanisms that worked at fifteen no longer scale, and the mechanisms that work at two hundred are overkill and breed resentment. Most of the bad reorgs I have seen come from leaders who reach for a two-hundred-person playbook because the thirty-person playbook stopped working.

The three shapes I see working #

1. Product-aligned teams plus a small platform team #

This is the default. Six to twelve product-aligned squads of four to eight engineers, each owning a clear customer-facing surface, plus a platform team of three to six engineers owning the shared substrate that none of the product teams should rebuild.

It works when:

Your product surface area is wide — multiple distinct user journeys or product lines.
Platform debt is manageable. The platform team’s main job is to enable product teams, not to firefight infrastructure.
The leadership team is comfortable saying out loud who the platform team’s customers are. (If the answer is “everyone,” the platform team will quietly become unaccountable.)

This is the shape that scales most gracefully — it stretches from forty engineers up to a hundred and fifty without much structural change, just more squads and a thicker platform layer.

2. Vertical pods around customer segments #

When the business model is genuinely segmented — SMB vs. enterprise, B2C vs. B2B inside the same company, regulated vs. self-serve — duplicating the whole stack inside each segment can be the right answer, even though it feels wasteful.

It works when:

The segments have materially different release cadences, risk profiles, or compliance constraints.
The product roadmaps for the segments have diverged to the point that a unified team can no longer prioritize across them without weekly fights.
You are willing to fund a small “shared” team to hold the things that genuinely should not be duplicated (auth, billing, design system).

It fails when leaders pick it because it feels modern, then under-fund the shared layer and watch the segments slowly diverge into incompatible products.

3. Platform-first org with thin product teams #

The inverse shape: a deep platform team (sometimes the majority of engineering) and small, light-weight product teams sitting on top.

It works when:

The product is genuinely a thin shell over a deep platform — developer tools, infrastructure products, data platforms, B2B APIs.
The platform itself is the differentiation, and product velocity is gated by how good the substrate is, not by how many UI engineers you have.
You are honest with yourself that this is a high-leverage but high-risk shape — when the platform stalls, everything stalls.

This is the shape that most often gets misapplied. Many companies adopt it because they like the idea of platform thinking — and end up with a heavy infrastructure org subsidizing a starved product surface.

What rarely works at this size #

A handful of shapes look attractive on a whiteboard and almost never survive contact with a real org between thirty and ninety people:

A separate “innovation” or “0-to-1” team. It draws senior talent away from the core, demoralizes the engineers who keep the lights on, and ships things the rest of the org cannot or will not absorb. At ten thousand engineers you can afford an innovation lab. At sixty, you cannot.
A matrix where engineers report to both a discipline lead and a product lead. Every performance review becomes a negotiation. Every hard decision has two owners, which means none. Matrix is sometimes correct at five hundred people. It is almost never correct at sixty.
A platform team that owns “everything infra” without an explicit customer list. Without a list of named teams whose problems they exist to solve, the platform team will optimize for its own internal interests within twelve months. Not because they are bad — because that is what a team does when no one is asking them for anything specific.
A “tech leadership” group that sits outside the line org. Principal engineers without managers, staff engineers floating above teams, a tech council that meets weekly. At this size you do not have enough load for these structures to do real work; they become a status tier instead of a contribution tier.

The three questions to answer in writing before any reorg #

If a reorg is on the table, the cheapest thing you can do — and the thing most leadership teams skip — is write down honest answers to three questions before you change anything.

1. What outcome will the new structure make easier?

Be specific. Easier to ship X kind of feature. Easier to hire Y kind of engineer. Easier to absorb Z kind of incident. If the answer is general — better velocity, clearer ownership — the reorg is solving a vibe, not a problem.

2. What outcome will it make harder?

Every structure makes something easier and something else harder. If your draft answer is nothing, you have not thought about it long enough. A useful follow-up: which person on the leadership team will feel this trade-off most, and have they agreed to it?

3. What problem are we actually solving, and is structure the cheapest way to solve it?

This is the question that kills most reorgs in their crib, in the best possible way. Many “structure problems” at this size are actually:

A leadership bandwidth problem — one VP has eleven directs and is not the bottleneck so much as the entire dam.
A hiring problem — the team you have cannot do the work the structure assumes; no shape change fixes that.
An alignment problem — different leaders have different unspoken theories of the business; the reorg becomes a proxy fight.
A founder-handover problem — the CTO is still operating like an IC and the org cannot grow until they stop.

A reorg cannot fix any of those. It can only obscure them for a quarter or two, after which they resurface, worse, with the added cost of disoriented teams and lost trust.

A pattern I have come to trust #

The leadership teams that handle this size well share a pattern: they reorg less often than they feel they should, and when they do, they do it small. They move one team, redraw one boundary, hire one director, retire one shared service — and let the change settle for two quarters before deciding what to do next.

The teams that struggle most do the opposite: big-bang reorgs every nine months, each announced with a deck about “the next phase of scale,” each leaving the org slightly more tired and slightly less sure of who owns what.

Structure is a real tool. It is just not the first tool, and at thirty to ninety people it is almost never the only tool.

If you are weighing a reorg right now and the questions above feel uncomfortable, that probably means they are useful. Tell me what you are looking at and we can spend thirty minutes pressure-testing it — including the case for not reorging at all.