When to right-size your engineering team (and when not to).

By the time a founder says the words out loud, "I think we over-hired", the room has usually known for 2 quarters. The lagging indicators are visible. Burn is up, delivery is not, and the engineering all-hands has a specific quality of tired politeness. Those aren't the signals worth watching. They're the receipt.

What I look for earlier:

The meeting graph got busier without the roadmap getting longer

Bigger teams need coordination. Fine. The question is whether the coordination cost is buying you anything. When a team of 30 has 3 times the meeting count of the team of 12 that preceded it, but the roadmap fits on the same page, the extra 18 people are paying for their own overhead and not much else.

Ownership went from names to teams

Small teams say "Anna owns billing." Larger teams say "the Payments team owns billing." That transition is normal. What's not normal is when nobody can name a decision the Payments team made this quarter. If ownership diffused into an org chart but never re-crystallised into decisions, you have a team that costs money and produces committees.

Senior engineers stopped disagreeing

In a healthy team, your senior engineers argue with each other and with you. When they stop, when RFCs get approved without pushback and design docs read like consensus already, they haven't got aligned. They've quietly decided the fight isn't worth it. Right after that, they start interviewing.

The org grew faster than the ICP

Every scaling story is a bet that the customer profile widens. Sometimes it does. Often it doesn't, and you find out 18 months later that you built a platform team for a product 2 customers wanted. Compare the shape of your engineering org to the shape of your paying customer base. If the org is more diversified than the revenue, you have your answer.

When not to right-size

Cutting is a tool. Not the tool.

• You're pre-revenue and slow. Slow isn't oversized. Slow is usually unclear priorities, an under-invested platform, or a founder still doing product management by whim. Cutting people won't fix any of those; it'll make them worse.
• You're between two rounds. If you're 90 days from a raise and you cut, you're telling the market you couldn't manage the last round. Sometimes that's the truth and you should say it out loud. Usually it isn't, and you're just running scared.
• The board is asking, but the CEO isn't sure. A cut made because the board asked never takes out the right people. The CEO ends up cutting who is cheapest to lose, not who should leave. Do the work first, decide who should leave, then have the board conversation.

The uncomfortable part

Right-sizing done well is not a spreadsheet exercise. It's a rebuild. You end up with fewer people, but also with clearer scopes, a shorter roadmap, and 1 or 2 managers who no longer have anyone reporting to them. Handle that badly and you save some money and lose your best engineers. Handle it well and the org comes out lighter, faster, and, this is the part founders don't expect, happier.

If you're reading this because you're pretty sure you need to do it, the odds are you do. The odds are also that you're already 6 months late. That's fine. 6 months late is still 10 times better than a year late.

The execution is a separate problem from the decision, and it is where most plans slip. In Belgium the Renault procedure sets the sequence. In the Netherlands WMCO and UWV set the clock. Read whichever applies before you build the plan, not after.

Written from patterns I've seen across engagements. If any of it sounds too specific to be general, that's why.

This is the work I take on. See right-sizing on the homepage.