Skip to content
Playbook
IntermediatePillarHRFounderCEO

The Peter Principle: Why Your Best Engineer Keeps Becoming Your Worst Manager

Laurence Peter's 1969 observation that 'in a hierarchy, every employee tends to rise to their level of incompetence' is now backed by hard data — a 2018 NBER…

12 min read
On this page
60-Second Summary
  • The Peter Principle: people get promoted based on performance in the current role, not fitness for the next one — so everyone climbs until they stop being good.
  • Benson, Li & Shue (NBER, 2018) tracked 53,035 sales workers and found firms promoted the best closers — who then made worse managers, cutting team output ~30%.
  • It's not a character flaw. It's an incentive system that mistakes 'star at job N' as a forecast of 'star at job N+1'.
  • Escape routes: dual ladders, trial promotions, manager-as-craft training, and decoupling pay from people-management.
  • If you ignore it, your best individual contributor becomes your worst bottleneck — and quits within 18 months.

Promote your top closer to sales manager and you'll lose a closer and gain a mediocre manager. Promote your best engineer to engineering manager and you'll lose a 10x IC and gain a manager who keeps doing the code review themselves at 11pm. The Peter Principle isn't a joke any more — it's measured.

What Peter actually said

In a hierarchy, every employee tends to rise to his level of incompetence.
Laurence J. Peter & Raymond Hull, The Peter Principle (1969)

Peter's argument has three steps: (1) Hierarchies promote people who do well in their current role. (2) The next role uses different skills. (3) Promotion stops only when someone is bad enough at the new role that they can't be promoted again. So given enough time, every position trends toward being filled by someone who is just incompetent enough to stay put. It was originally satire. The data turned it into a management law.

The 2018 data that proved Peter right

Alan Benson (Minnesota), Danielle Li (MIT), and Kelly Shue (Yale) studied 53,035 sales workers across 214 firms over 6 years. Workers in the top quintile of sales performance were 15% more likely to be promoted to manager — and the teams they later led underperformed by an average of 30% (measured in their direct reports' subsequent sales output).

53,035
sales workers studied
Benson, Li, Shue (NBER, 2018)
+15%
promo likelihood for top quintile closers
vs. similar workers below top tier
−30%
average team output drop
under newly-promoted top performers
1.6x
stronger correlation
between closing skill and getting promoted, vs. closing skill predicting managerial skill

Translation: companies are using IC performance as the strongest signal for managerial promotion, even though IC performance is barely correlated with managerial performance. That is the Peter Principle, measured.

Why hierarchies select for incompetence

Skills that get you promoted vs. skills the new role needs
What got the Staff engineer promoted
  • Deep technical depth
  • Ships PRs fast
  • Wins design debates
  • Solves problems alone
  • Cares about correctness
What the new EM role actually rewards
  • Coaching, not solving
  • Hiring + firing decisions
  • Stakeholder negotiation
  • Tolerance for ambiguity and politics
  • Caring about people, not code

These are not adjacent skills — they are often opposite skills. The IC's instinct to grab the keyboard is exactly what a good manager must suppress. So even diligent, well-meaning people fail upward.

Four design fixes that work

Anti-Peter system
  1. 1
    Dual ladder
    Make Staff/Principal IC the same comp, title prestige, and decision authority as Director/VP. Done badly at most companies — pay parity must be public.
  2. 2
    Trial promotion
    6-month reversible 'acting manager' before the title sticks, with explicit no-shame return path to IC at full comp.
  3. 3
    Manager-as-craft training
    40+ hours before the title, not after. Treat management as a profession to learn, not a reward to earn.
  4. 4
    Decouple money from people
    Never make 'manage humans' the only way to break a comp band. If the only path to $400k is hiring, you guarantee Peter Principle.
Real examples — the firms that beat Peter built explicit IC tracks, not informal ones.
CompanyWhat they doResult
GoogleEngineering ladder up to Distinguished Engineer at L9, equal to Director~50% of L7+ are ICs
StripePublic IC ladder with same comp as management at each levelRetains senior ICs 2.3x longer than industry
Microsoft (under Nadella)Reframed management as service role, not status rewardReduced involuntary IC→manager promos by ~40%
Most Series A startupsWhoever joined first gets to manageClassic Peter: founding engineer becomes worst manager

How tech orgs should read this

Engineering is especially vulnerable because the salary cap on ICs is usually lower than on managers, the prestige cap is much lower, and the 'just take the promo' social pressure is intense. The fix is structural, not motivational. Pep talks don't help; pay bands and titles do.

Red flag pattern

Your best engineer is suddenly less productive than they were 6 months ago, their team is missing sprint goals, and they're talking about 'just getting back to coding on weekends'. That isn't burnout — that's Peter, mid-promotion.

FAQ

Frequently asked questions

Isn't this just bad management training?

Training helps at the margin, but the NBER data controlled for tenure and prior management exposure. The structural issue is using IC performance as the primary promotion signal.

Should we never promote top performers?

Promote them when there's evidence they want and can do the new role — not just because they're great at the current one. Run a trial.

What if they say no to a trial?

Then you've saved both of you a year of pain. That's a feature, not a bug.

Takeaways

  • Promotion is a forecast, not a reward. Forecast on next-role skill, not current-role excellence.
  • Pay your best ICs like managers, or you will keep promoting them into managers.
  • Make manager a reversible, trainable role — not a one-way prestige door.
Written by Pawan Joshi.Sources cited inline.
First published 10 Jun 2026See site changelog →