The Peter Principle states that in a hierarchy, every employee tends to rise to their level of incompetence — the position at which they are no longer good enough to be promoted further but not bad enough to be fired. There they remain, performing mediocrely, occupying a role they are not suited for, because the role they were suited for has been given to someone else who was also good at it and will also be promoted out of it.
The principle was articulated by Laurence J. Peter in 1969. It has been confirmed by every corporate Org Chart since.
The mechanism is simple and devastating: organisations promote based on performance in the current role, not predicted performance in the next role. The best developer becomes the Engineering Manager. The best engineer becomes the CTO. The best salesperson becomes the Sales VP. Each promotion rewards excellence by removing the person from the activity they excel at and placing them in an activity they have never done. The new activity requires entirely different skills — the developer needs people skills, the engineer needs strategy, the salesperson needs management — and the promoted person has none of them, because their entire career selected for the opposite.
The principle’s cruelest insight: the reward for being excellent at your job is a different job.
The Mechanism
The Peter Principle operates through a four-stage cycle:
Stage 1 — Excellence. The employee is good at their job. Measurably, visibly, undeniably good. The developer ships clean code. The designer ships beautiful interfaces. The salesperson closes deals. The excellence is noticed.
Stage 2 — Promotion. The organisation, having noticed the excellence, promotes the employee. The promotion is sincere — the organisation genuinely believes that excellence at Level N predicts excellence at Level N+1. This belief is intuitive, universal, and wrong. Writing excellent code does not predict the ability to manage people who write code. Closing deals does not predict the ability to manage people who close deals. The skills are different. The promotion assumes they are the same.
Stage 3 — Incompetence. The promoted employee discovers that the new role requires skills they do not have. The developer-turned-manager cannot have difficult conversations. The designer-turned-director cannot manage a budget. The salesperson-turned-VP cannot think strategically. The employee is not bad — they are misplaced. They are a fish promoted to a tree-climbing position based on their excellent swimming.
Stage 4 — Permanence. The incompetent employee is not fired, because they are not incompetent enough. They meet minimum expectations. They attend meetings. They produce deliverables. They are not a disaster — they are a plateau. And a plateau does not trigger action. A plateau triggers acceptance, a middling Performance Review, a Development Goal that will not be met, and decades of occupying a role that someone more suited would fill better.
The org chart fills, over time, with people who are permanent residents of their level of incompetence. The work gets done — but it gets done by the people at Stage 1, who have not yet been promoted, and who will be promoted the moment they are noticed, at which point the cycle restarts.
The Technology Version
The Peter Principle is particularly devastating in technology, because the skills gap between levels is wider than in almost any other field.
| Level | Skills Required | Skills That Got You Here |
|---|---|---|
| Senior Developer | Technical excellence, code quality, system design | Same |
| Tech Lead | Technical excellence + communication, mentoring, coordination | Technical excellence alone |
| Engineering Manager | People management, coaching, conflict resolution, hiring | Technical excellence (which is now irrelevant) |
| VP | Strategy, politics, board communication, budget management | People management (which is now insufficient) |
| CTO | Vision, vendor management, executive communication, org design | Some combination of the above (none of which prepared them) |
Each transition requires abandoning the skills that defined the person and acquiring skills they have never practised. The transition from Senior Developer to Engineering Manager is not a promotion. It is a career change performed without a job search, without an interview for the new role, and without the honest assessment that career changes usually require.
The CTO entry describes this as “the Peter Principle, except worse — promoted to their level of irrelevance, still competent, still sharp, still capable of solving the problem in an afternoon, but trapped in a calendar that has no afternoons.”
The IC Track Solution
The Peter Principle’s solution is obvious and rarely implemented: promote people within their skill set rather than out of it.
The IC (Individual Contributor) track — Staff Engineer, Principal Engineer, Distinguished Engineer — allows developers to advance in seniority, compensation, and influence without becoming managers. The developer who is excellent at architecture becomes a Staff Architect, not an Engineering Manager. The developer who is excellent at mentoring becomes a Principal Engineer who mentors, not a manager who manages. The skills are preserved. The person is not misplaced.
The IC track exists at many companies. The IC track is rarely equivalent to the management track. The salary bands are lower. The influence is less visible. The title is less impressive on LinkedIn. The IC track is the correct solution to the Peter Principle, offered at a discount, which is why the best ICs still take the management track — not because they want to manage, but because the compensation gap is a 25% argument against staying where they’re excellent.
The companies that make the IC track genuinely equivalent — same salary, same influence, same respect — are the companies that avoid the Peter Principle. These companies are rare. They are also, not coincidentally, the companies where the architecture is cleanest, because the people making architectural decisions are the people who are excellent at architecture, not the people who were promoted away from it.
The Solo Developer Exemption
riclib is immune to the Peter Principle because riclib has no hierarchy. riclib is a Solo Developer — Level 1 and Level N simultaneously, writing code and setting strategy and managing the infrastructure, all in the same afternoon, without a promotion in sight.
riclib was never promoted out of the thing he was good at. He was promoted into it — twenty-five years of enterprise consulting, transformation leadership, and Agile Transformation Lead roles, followed by a deliberate step sideways into solo development, where the hierarchy has one rung and one rung cannot produce the Peter Principle, in the same way that a monolith cannot produce Microservices communication overhead.
This is not the usual exemption. Most people avoid the Peter Principle by never being promoted. riclib avoided it by being promoted all the way to the top, looking around, and climbing back down to the rung where he was happiest — the one with the keyboard.
The Lizard blinks at this section. The Lizard has no opinion on career ladders. The Lizard has a warm rock. The warm rock is at exactly the right level.
Measured Characteristics
- Year published: 1969
- Years since confirmed: 57
- Employees currently at their level of incompetence: significant (estimated 30-50% of managers)
- Employees who were excellent at their previous role: most of the above
- Employees who were trained for their current role: ~10%
- Promotion conversations that assessed fitness for the new role: rare
- Promotion conversations that assessed performance in the current role: all of them
- IC tracks that are genuinely equivalent to management tracks: ~15% of companies
- Salary gap between IC and management at senior levels: 15-30%
- Best developers who became mediocre managers: too many
- Best managers who were mediocre developers: almost none (they were promoted from somewhere else)
- The reward for being excellent at your job: a different job
- The reward for being mediocre at the new job: permanence
