| name | peter-principle |
| description | Apply the Peter Principle when discussing promotions, career ladders, hiring for leadership roles, why managers sometimes struggle, or how to build healthy engineering organizations. Trigger on phrases like "we promoted our best engineer to manager", "they were great as an IC but struggling as a lead", "how should we think about promotions?", "our managers weren't trained for this", or any situation where promotion or career development decisions intersect with competence and role fit. |
Peter Principle
"People in a hierarchy tend to rise to a level of respective incompetence."
— Laurence J. Peter, 1969
The core idea
In most organizations, people are promoted based on performance in their current role. But the skills that make someone excellent in role N are often different from the skills required in role N+1. The result: people keep getting promoted until they reach a role they're not good at — and then they stay there. Everyone ends up at their level of incompetence.
Why this happens
Promotion criteria look backward, not forward.
We promote people for what they've done, not what they can do next. A brilliant individual contributor gets promoted to tech lead because they write great code — but tech lead requires communication, delegation, and conflict resolution, not just coding skill.
Different roles require genuinely different skills.
Engineering and management are different jobs. Coding and architecture are different jobs. Building a product and running a product organization are different jobs. The skills don't automatically transfer.
There's no graceful way back.
Once promoted, stepping down feels like failure — for the person and for the organization. So people stay in roles they're not suited for, often becoming unhappy and underperforming.
Organizations often have no alternative path.
If the only path to higher compensation is management, your best individual contributors will keep getting promoted into management — regardless of whether they want it or are suited to it.
What to do about it
Build dual career ladders.
Create a senior individual contributor path that provides compensation and status equivalent to management. "Staff Engineer," "Principal Engineer," "Distinguished Engineer" — titles that signal seniority without requiring management. This lets excellent ICs stay in roles where they excel.
Promote for the next role, not the current one.
Before promoting someone, assess whether they show the skills the new role requires — not just whether they're excellent in their current role. Have conversations about what the new role actually involves. Trial periods or acting roles help.
Make it OK to be an excellent non-manager.
Culturally, "becoming a manager" should not be seen as the only sign of success. Organizations that celebrate senior ICs as much as managers avoid Peter Principle pressure.
Provide leadership training before promotion, not after.
Don't promote someone into a leadership role and hope they figure it out. Provide the skills — communication, delegation, conflict resolution, performance management — before the promotion.
Create explicit off-ramps.
Make it organizationally acceptable for someone to realize management isn't for them and return to an IC role without stigma. This requires intentional culture-building.
In software specifically
The "brilliant engineer → bad manager" pipeline is one of the most documented failure modes in tech. Engineering excellence and management excellence share some traits (systems thinking, care about quality) but diverge sharply on others (people over code, delegation over doing, influence over control).
Key questions to surface
- Are we promoting this person because they'll be good at the next role, or because they're excellent at the current one?
- Do we have a senior IC career path that doesn't require going into management?
- Has this person expressed that they want to manage — not just that they're willing to?
- Are we providing leadership training proactively, before the promotion?
- If this promotion doesn't work out, is there an acceptable way for this person to return to an IC role?
