A common conversation topic I'm in is "how to staff up an engineering team in the early stages of growth." How many hires, and what skills?

There are easy truisms like:

• It's better for a startup to have more work than too many people, and
• Hiring generalists over specialists maximizes utilization and flexibility.

Here's an example that demonstrates a less intuitive concept: let's say you get budget to make a new hire, and you run two teams -

Team A: 8 highly productive, overworked engineers
Team B: 5 less productive, but extremely overworked engineers

Many make the mistake of hiring for team B. After all:

• They're more overworked
• There are fewer people (something about subconscious biases towards balance?)

Of course, you should strongly prefer hiring for team A, since that's almost certainly a better return on investment. Maximizing productivity is not the same thing as relieving shortages. Usually it means doing more of what you're already doing really well - even if it means neglecting weaknesses. Sometimes leaders fall into the trap of filling niche roles too early, because of perceived gaps in an org -- even when those gaps are really not important yet, limiting how productive any specialist can be.

When does it make sense to hire for team B again? Only when it's the most productive thing.

• Maybe a bottleneck forms and a hire will unlock productivity for a downstream/upstream team.
• Maybe the leader debugs the people/process and increases team efficiency.
• Maybe the whole team is redirected towards a goal and a mission that has a higher return.

Doing the most productive thing, repeatedly, naturally leads to specialization, which seems to work well at almost any layer of abstraction -- individuals, firms, even entire countries. It'll probably work for your engineering team too.