The most important factor to consider when expanding a team is that the usefulness of incremental hires is not linear. Here are the hiring breakpoints that matter.
140–160 is an interesting one. We recently crossed the 150 mark, but have felt the coordination pain since well before that.
My hunch is that the exact Dunbar number depends a lot on context, such as employee growth and turnover rate, how distributed the org is, how many are acquired vs. hired, etc.
The main distinction that I've seen is that the Dunbar number matters for every sub-grouping you can imagine:
* The number of people at your company
* The total number of R&D (eng, pm, design, data) employees
* The total number of engineers
* The number of R&D employees in your primary office
* The number of engineers in your primary office... etc
It recurs all over the place at micro levels.
Acquisition is another good point; acquiring a company of <150 people can actually be an extremely stabilizing force in a larger company because you reintroduce some of that family oriented DNA.
The 1-2 section matches what I saw in my CTO years: two people owning the same top-level call usually means nobody really owns it. What I'd add for the 0-1 hires is that they're also the hardest to interview for, because there's usually nobody in-house who has done the job and can tell a great designer or data person from a confident one. That's where a short, structured process with criteria agreed upfront, and ideally someone experienced in that function in the room, pays off most. How do you advise founders to assess that first specialist when they can't judge the craft themselves?
I think that this is where good advisors can come in, or where there's an advantage to just having experience – like I know many tech people who aren't salespeople by trade, but have worked with like 200 sales reps and can just tell when they see a true bozo.
The ideal solution is probably just assessing for drive/IQ and managing people out quickly if they're not working.
140–160 is an interesting one. We recently crossed the 150 mark, but have felt the coordination pain since well before that.
My hunch is that the exact Dunbar number depends a lot on context, such as employee growth and turnover rate, how distributed the org is, how many are acquired vs. hired, etc.
The main distinction that I've seen is that the Dunbar number matters for every sub-grouping you can imagine:
* The number of people at your company
* The total number of R&D (eng, pm, design, data) employees
* The total number of engineers
* The number of R&D employees in your primary office
* The number of engineers in your primary office... etc
It recurs all over the place at micro levels.
Acquisition is another good point; acquiring a company of <150 people can actually be an extremely stabilizing force in a larger company because you reintroduce some of that family oriented DNA.
The 1-2 section matches what I saw in my CTO years: two people owning the same top-level call usually means nobody really owns it. What I'd add for the 0-1 hires is that they're also the hardest to interview for, because there's usually nobody in-house who has done the job and can tell a great designer or data person from a confident one. That's where a short, structured process with criteria agreed upfront, and ideally someone experienced in that function in the room, pays off most. How do you advise founders to assess that first specialist when they can't judge the craft themselves?
Yes, the 0-1s are super hard as a result.
I think that this is where good advisors can come in, or where there's an advantage to just having experience – like I know many tech people who aren't salespeople by trade, but have worked with like 200 sales reps and can just tell when they see a true bozo.
The ideal solution is probably just assessing for drive/IQ and managing people out quickly if they're not working.