The best engineer on your team is not necessarily your next best engineering manager. The best engineering manager is not necessarily your next best leader of leaders. And yet, most companies promote on a criteria that ignores this entirely: they look at how well someone performs in the role they hold today, and treat that as evidence that they will perform well in a role they have never done.
This is the Peter Principle, and it's one of the most persistent traps in performance management.
What is the Peter Principle?
Formulated by Laurence J. Peter in his 1969 book The Peter Principle, the idea is deceptively simple:
In a hierarchy, every employee tends to rise to their level of incompetence.
The logic is straightforward. If promotions are granted based on performance in the current role, then people keep being promoted as long as they perform well. The moment they reach a role where they no longer perform well, the promotions stop — and they stay there.
Over enough time, the argument goes, every position ends up occupied by someone who is not competent at it. It is of course an exaggeration, but the mechanism behind it is very real, and I've seen it play out in tech many times.
Why It Hits Software Engineering So Hard?
The Peter Principle is particularly damaging in software engineering because the skills that make someone excellent at one level are often not the skills required at the next one.
An excellent Senior Software Engineer is deeply technical, delivers complex projects, and is a trusted authority within their team. Promote them to Staff and the job changes: influence without authority, technical direction across teams, and the ability to pick the right problems rather than solve the assigned ones.
Promote a Senior Engineer to Engineering Manager and the change is even more radical. The craft that earned the promotion — writing code, designing systems, solving hard technical problems — is no longer the job. The new job is people management, delegation, feedback, hiring, and team management. It's a career change, not a promotion.
The same happens one level up. Going from managing a team to managing managers means you no longer lead the work — you lead the people who lead the work. My own experience taking on a full product vertical taught me that lesson: the levers you have as a leader of leaders are strategy, organizational design, and developing other leaders, not the day-to-day execution you used to control.
I explored some of these transitions in The traits and pitfalls in Software Engineering careers. The pitfalls listed there are, in a sense, a catalog of what happens when someone lands at a level they were not prepared for.
The cost is real, and it's paid by everyone:
- The person: They lose the sense of mastery they had, their confidence erodes, and they may be pushed into a performance improvement plan for a role they never really chose;
- The team: They get a leader who is struggling to learn the basics of a role instead of one who can support them;
- The organization: It loses a great performer at one level and gains a struggling one at the next.
And there's a second-order effect that's often ignored: the person who is not promoted because there was no room left. Levels occupied by people who plateaued block progression for everyone below them.
The Fix: Promote for the Next Level, Not the Current One
The antidote to the Peter Principle is straightforward to state and hard to execute: promote people who are already performing at the next level, not people who are performing well at their current one.
This is the principle the Tech Org career track at VTEX follows. Promotion is not a reward for a great cycle in your current role — it is the formal recognition of a reality that is already visible. By the time someone is promoted, they have been consistently demonstrating the expectations of the next level, and the promotion simply makes the title match the behavior.
This changes the nature of the whole conversation:
- Promotion becomes evidence-based. The question a leader has to answer in a calibration committee is not "do they deserve it?" but "where is the evidence that they are already operating at that level?" Evidence is concrete: scope owned, decisions made, impact delivered, autonomy demonstrated;
- Development comes before promotion, not after. If someone needs to perform at the next level to be promoted, then the leader's job is to create the opportunities where that performance can happen. This is what an Individual Development Plan is for;
- Nobody is set up to fail. A person promoted for behaviors they already demonstrate does not fall off a cliff on day one. The role gets bigger, but it is not foreign to them;
- The bar is explicit. Since expectations are defined per level in the career ladder, both the engineer and the manager can point at the same document. There is much less room for surprise or perceived unfairness.
It also has an uncomfortable but healthy consequence: excellent performance at your current level is not, by itself, a case for promotion. It is a case for recognition, for compensation adjustments, for scope and for trust — but the promotion conversation requires something different. Being clear about this early, in one-on-ones, avoids frustration much later.
The Compensation Caveat
There is a fair objection to this model: if someone has to perform at the next level before being promoted, they can spend a long time delivering next-level scope while being paid for the previous one.
The objection is legitimate, but the problem is not the promotion criteria — it's treating title and compensation as the same lever. They should move on different cadences. A promotion recognizes a level that has been consistently demonstrated; compensation should follow the value being delivered along the way. This is why salary bands are tipically broad and overlap between adjacent levels in the industry: so that someone operating above their level can be moved toward the top of their band, without waiting for the title to catch up.
If a person is delivering next-level scope and their compensation hasn't moved at all, the failure isn't in the promotion model. It's in not using a tool the company already has.
Two things make this work in practice: a defined horizon, so the person knows roughly how long the demonstration period is expected to last, and explicit criteria, so they know exactly what is still missing. Without those, "perform at the next level first" stops being a development path and becomes an open-ended request.
What This Looked Like For Me
I took on the senior engineering leadership of the Omnichannel Experiences vertical at VTEX in November 2024 — four teams, 35 engineers and engineering managers across Brazil and Colombia. I was promoted to Senior Engineering Manager in August 2026.
Almost two years separate those two dates. That gap is the point.
I did not get the scope because I was promoted. I got promoted because I had been operating at that scope, consistently, across several performance review cycles — leading managers, owning the technical direction and organizational health of a vertical, and contributing to hiring and engineering leadership beyond my own teams. The promotion did not hand me a new job to figure out. It recognized the job I had already been doing.
That interval was not a formality either. It was where the actual development happened, and the gaps were not the ones I expected. Leading through other managers was something I had already practiced in previous roles. What my development plan actually targeted was different:
- Multiple problem spaces: going from a single domain to holding several distinct problem spaces at once — marketplace integrations, in-store and remote sales, live shopping — each with its own technical challenges, and none of which I could afford to go deep on the way I used to;
- Strategic vision: shifting from planning execution to shaping where the vertical should be in a year, and being able to defend that direction with a rationale that connects technical decisions to business outcomes;
- Stakeholder management: operating with product, business, and leadership peers across the company, where influence and alignment replace the direct authority you have inside your own teams.
Those three are precisely the skills you cannot acquire from a title. They come from sitting in the chair, adjusting your leadership style to a much wider range of situations, and getting comfortable with the fact that at that level you influence outcomes far more than you control them. Had I been promoted first and asked to grow into them afterwards, that learning would have happened under pressure, with much higher stakes, and with a real chance of becoming a textbook Peter Principle case.
It requires patience, from both the individual and the organization. Waiting is uncomfortable when you feel ready. But the alternative — being promoted into a role you have never actually practiced — is far worse.
The Leader's Responsibility
If you lead engineers, this principle puts a specific obligation on you. Promoting for the next level only works if people are actually given the chance to perform at the next level before the promotion. Otherwise it becomes a circular trap: you can't be promoted without demonstrating the behaviors, and you never get the chance to demonstrate them.
Concretely, this means:
- Delegate scope that stretches. Delegation is not only about your own bandwidth — it's the primary mechanism for creating next-level opportunities;
- Be explicit about the gap. Tell people exactly which expectations they are already meeting and which ones they are not. Vague encouragement is not feedback;
- Make the ladder visible. People cannot aim at a target they can't see;
- Validate the aspiration. Not everyone wants the next level, and moving to management in particular should be a deliberate choice, not a default reward. Assuming that everyone wants to climb is its own version of the trap.
Conclusion
The Peter Principle is not a law of nature. It is the predictable outcome of a specific design choice: rewarding past performance with a different job.
Change the criteria and the outcome changes with it. When promotion recognizes performance that is already happening at the next level, you stop converting great performers into struggling ones. People arrive at new levels prepared, teams get leaders who can actually lead them, and career progression becomes a process people can understand and plan for, rather than a lottery.
The question to ask in a promotion discussion is not "have they earned it?". It's "are they already doing it?"
