Why good developers become bad managers
See why software companies promote people into roles they are not good at, how the Peter Principle shows up in engineering, and what actually fixes it.
Software's version of the Peter Principle is promoting a strong engineer into management because they excelled at engineering, even though management needs different skills. The fix is to reward technical excellence without forcing management, and test candidates against the next role before promotion.
Imagine the fastest baker in a bakery being promoted until they run the whole company. Being brilliant at making bread does not prove they can hire people, resolve conflict, set priorities or design a supply chain. Software companies make the same mistake when they treat management as a prize for technical excellence instead of a different job.
Software engineers often develop a suspiciously simple theory of organizational decay: the people doing the work understand the system, managers do not, and every extra layer of management makes the company slower, more political and less competent. That theory is wrong often enough to be dangerous — and right often enough that it keeps coming back.
The Peter Principle in software
The cleanest starting point is the Peter Principle: organizations tend to promote people because they are good at the job they already have, until they eventually reach a job that needs a different skill set. The phrase is old, but the mechanism has modern evidence behind it. A study by Alan Benson, Danielle Li and Kelly Shue found that firms strongly rewarded current sales performance when choosing new managers even though the same measure was not a comparably good predictor of management performance. The mistake is subtle: the company is not promoting a bad employee. It is using the wrong evidence for the next role.
Applying that finding to engineering is an analogy, not a result measured by the sales study. A senior developer may be exceptional because they can debug systems faster than anyone else, write difficult code under pressure and carry enormous product context in their head. None of those abilities automatically prove that they can delegate, coach a weaker engineer, mediate conflict, hire well, set priorities or make eight other people more effective.
The promotion can therefore look rational at every step. The engineer is visibly strong. The company wants to reward them. Management pays more and carries more status. The person accepts because it looks like progression. Six months later, the organization has lost a strong individual contributor and gained an inexperienced manager.
The key distinction
A promotion should answer “Can this person do the next job?”, not merely “Did this person deserve a reward for the current one?”
Why software makes it worse
Software magnifies the problem because the work is difficult to measure and much of the most valuable contribution is indirect. The engineer who prevents five incidents may look less impressive than the engineer who heroically fixes five incidents. The person who simplifies an architecture can create more long-term value than the person who ships the most visible feature, but the feature is easier to point at in a promotion meeting.
That is why simple productivity proxies are so dangerous. The SPACE framework explicitly argues that developer productivity is multidimensional and should not be reduced to a single measure such as commits, pull requests or raw activity. Once a company promotes against simplistic proxies, the people who optimize the visible surface can outrank the people who improve the system underneath it.
Management makes this measurement problem larger, not smaller. A good engineering manager may personally write almost no code. Their output appears indirectly: fewer blocked decisions, better hiring, stronger engineers, healthier ownership, lower regretted attrition and teams that no longer require constant rescue. A bad manager can also look productive for a long time if strong engineers absorb the damage on their behalf.
The dangerous case is the former technical hero who never really stops being the hero. They still rewrite important pull requests. They remain the final architecture gate. They jump into every incident. Delivery can look fine, but the team becomes more dependent on one person instead of less. The manager is producing output while reducing the team’s independence.
When managers really do damage
The instinct that bad managers can ruin software organizations is not imagined. Management decisions affect the whole team. Research on supervisor quality has found that replacing a very weak boss with a very strong one can have a large effect on team output, and other work has linked stronger people-management skills with lower employee attrition. In software, that influence compounds because managers influence hiring, promotions, priorities, team boundaries and who gets trusted with technical decisions.
That is why a weak manager is more dangerous than a weak individual contributor at the same level of competence. A poor engineer can create bad code that review and testing may catch. A poor manager can create the environment in which bad code, bad priorities and bad hiring all become normal.
The pattern becomes especially destructive when the manager begins reproducing the same system that promoted them. They select people who look like themselves, reward visibility over substance, promote the strongest political narrators, centralize decisions and interpret disagreement as disloyalty. At that point the problem is no longer one incompetent manager. It is a management system that is selecting for itself.
There is also a less dramatic failure mode: the bottleneck manager. Every decision must go through them, every cross-team question waits for their approval, and senior engineers stop exercising judgement because authority has moved upward. Nothing explodes. Everything just becomes slower. This is organizational technical debt.
Why managers get blamed for systemic problems
Engineers also over-attribute problems to the nearest visible manager. A manager can be executing a bad strategy written two levels above them, carrying an impossible roadmap, dealing with a hiring freeze, or enforcing incentives they did not create. If every manager in a department behaves badly in the same direction, the useful question is usually not why all of them became foolish at once. It is what the system is rewarding.
This distinction matters because otherwise companies replace people without changing the mechanism. The new manager inherits the same goals, the same promotion rubric, the same reporting structure and the same impossible dependencies. Six months later the organization concludes that it hired another bad manager.
There is good software-specific evidence that structure itself matters. Microsoft research on Windows Vista found that organizational properties of software ownership and coordination were strongly associated with failure-prone components. That does not prove that a particular manager caused a bug. It does show that organizational design is part of the technical system, not an administrative layer floating above it.
So the more useful version of the cynical engineer’s complaint is not “managers ruin companies”. It is “management systems can multiply harm across teams”. Sometimes one manager is the cause. Sometimes they are merely where a larger design flaw becomes visible.
What good organizations do instead
The best fix is to stop treating management as the default prize for technical excellence. Companies such as GitLab publish separate engineering and management career paths, and GitLab explicitly treats engineering management as its own craft. That removes one of the most perverse incentives in technical organizations: forcing someone to manage people simply because that is the only route to more status, pay or influence.
The second fix is to evaluate people against the next role. If the candidate is becoming an engineering manager, evidence should include delegation, coaching, hiring judgement, prioritization, conflict handling and the ability to create outcomes through other people. Their current coding speed should be background information, not the central argument.
The third fix is to make promotions less irreversible. Acting-manager assignments are useful because they turn a promotion from a permanent identity decision into a test. Someone can discover that they dislike people management, or that the organization is getting less value from them there, and return to an IC path without the move being treated as humiliation.
The fourth fix is measurement discipline. Google’s management research identified concrete behaviors such as coaching, empowering teams, communicating well, supporting career development and making effective decisions. Whether a company copies those exact behaviors matters less than the principle: define what good management looks like before choosing the person, then evaluate the role by the effect on the team rather than by the manager’s personal activity.
And finally, companies need promotion systems that are resistant to political favoritism without pretending politics can be removed. Social influence is not inherently fake work. Senior engineers and managers must persuade people, build coalitions and communicate. The failure begins when narrative skill becomes a substitute for evidence of impact instead of a way to make real impact legible.
Remember
The Peter Principle is not really a story about stupid people rising to the top. It is a story about organizations repeatedly confusing performance in one role with evidence for another — and then making the mistake expensive by giving the new role more authority.
For the technical alternative to management, see senior versus staff engineering. When preparing for either track, the promotion packet explains how to gather evidence of the work you already do and the role you are seeking.
Questions people also ask
4 QUESTIONSWhat is the Peter Principle?
It is the idea that people in hierarchies are promoted because they are good at their current job until they eventually reach a role for which they are not well suited. The important point is that performance in the old role may be a poor predictor of performance in the new one.
Why do good software engineers become bad managers?
Because the jobs are different. Strong engineering rewards technical judgement, problem solving and individual contribution. Management depends much more on delegation, coaching, prioritization, conflict handling, hiring, communication and improving the output of other people.
Are managers usually the reason software companies become worse?
Sometimes, especially when they distort priorities, create bottlenecks, reward the wrong people or drive good engineers away. But managers also inherit bad incentives, unclear strategy and broken structures from above. Blaming one manager can hide a system that keeps producing the same failure.
How can companies avoid promoting the wrong people?
Treat management as a separate profession, keep an equally prestigious individual-contributor track, assess people against the next role rather than the current one, use acting assignments and structured promotion criteria, and make returning to an IC role normal rather than humiliating.