Power Law of Engineers and How to Run an Engineering Organization
Power Law of Engineers and How to Run an Engineering Organization
Last night I was at dinner with a team that I angel invested in (and have become close friends). We were talking about how to run startup engineering teams, and they asked me a few key questions, so I thought I’d put my thoughts on paper.
Trigger Warning: this post is a little savage. It’s definitely not nice to the average engineer, but it’s the truth. Business is business.
The Power Law of Engineers
There’s really only one way to measure engineers: impact. This is where you hear a lot about 10x engineers, but the reality is actually quite a bit more extreme, it’s a power law:
The bottom 25% - will typically have a negative effect
Middle 25-75% - Typical effect, call them a 1x
Top 75-95% - 2x impact
95-99% - 5-10x impact
Top 1% - 10-20x impact
Top 0.1% - Sometimes 100x+ impact
The thing that is non-trivial about the top 1%+, is that they will do things that the middle 50% of engineers couldn’t do if you had 1000 of them. It’s based on how they think about delivering impact. That you can’t replicate.
How to Run an Engineering Org
Startups
The average startup should have one, maybe two engineers in that top 5%+ bucket. These engineers should be capable of building the entire app, quickly. If your CTO can’t do this alone basically - fire them.
>What if we are getting so many feature requests from customers that we can’t do them all?
Just fucking work harder.
I get nervous when teams hire a bunch of outside help early on, especially if that bar seems questionable. Essentially the more $$ you spend on R&D, the higher odds you have of dying. I’d much rather see startups spend this on GTM. Have lived this mistake one too many times.
Scaling Startup Teams
Eventually (but later than you think), you’ll have to hire outside talent. Three notes on this:
Keep the bar high (top 5% of senior / staff level people) - all must actively be writing code all day
Fire quickly based on impact - ok to judge this based on vibes too, your gut is essentially the best indicator - you’ll never regret firing too early and always regret firing too late
Keep the org flat - no managers
Running Startup Teams
Varun at Farcaster has some good tips on this that I highly recommend reading.
Scale-Ups and Large Companies
This doesn’t apply to every large company, but from what I’ve seen it’s about the average case. Late last year I looked at a few opportunities at Series B+ companies for VP of Engineering roles. If I were put in charge this is what I would do.
The goal is to increase the velocity of the engineering organization 2-3x . Most of these engineering organizations are way too hierarchical and overhired with middle 50% people. They need to be flattened and weeded out.
Playbook I’d run to fix this:
Start with process
Measuring velocity
Strong engineering values - talk about this consistently
I would personally dive in: both by reading / writing code and having 1:1s with essentially every report
Run a good perf process
Triage major issues (incident handling, processes etc)
Depending on how overhired the org is, a first 90 day priority would be to thoughtfully lay off and reorg anywhere from 25-60% of the org (with another expected attrition of 10-15%). The scorched earth strategy.
Get rid of most (if not all) of the middle / bottom engineers
Flatten the management structure dramatically, get rid of a lot of middle managers
Make sure to get everyone back on a makers schedule
Note: this will make anyone who does this the bad guy, and that’s ok. Early career folks will be traumatized, but that’s just part of being an adult professionally
Product should report directly to the CEO and be lean (for most orgs) - would also work on making this change
I’d also have managers stack rank all of their reports every quarter, and make them justify keeping the bottom 10% . Psychologically this can be tough on reports (if they know)- but realistically it only matters if you’re underperforming. We did this at Coinbase.
Ultimately the end result of this strategy is that the top 5% engineers will be a lot happier, and the organization will move faster.
Conclusion
Some people will hate this, but I’m definitely in the bucket that this is a team, not a family. If you don’t make the roster you can get cut, and really we’re only looking for champions. Don’t compromise for not having the best. Life is too short for that. Just don’t tolerate incompetence or just average. Hire and work with the best in all cases.