Great Engineers Deserve Better Than an Accidental Management Role

An engineer reaches the top of their pay band. So you make them a Senior Engineer. They reach the top of that band. Principal Engineer. Then the pay scale problem surfaces again and someone in a meeting says the quiet part out loud: “We need to do something about this.”

So you make them an Engineering Manager.

The transition can be brutal. Not because the engineer did anything wrong, but because nobody stopped to ask whether they actually wanted to lead people, whether they were built for it, or whether the organization would invest in teaching them how. Usually the answer to all three was no, but the ladder had run out of rungs and something had to be done.

I’ve watched this happen more times than I can count. The decision gets dressed up as a career development opportunity when the real driver is a pay band ceiling. And it tends to land on the engineer like a ton of bricks about 90 days in, right around the time they realize their entire job has changed and nobody prepared them for any of it.

For a lot of engineers, that last step is a trap. For a lot of organizations, it is the beginning of a slow-moving problem that won’t fully surface until the team starts underperforming and nobody can figure out why.

The Peter Principle was first described in 1969 by Laurence J. Peter and Raymond Hull. The premise is simple and devastating: in a hierarchy, people are promoted based on their performance in their current role, not their potential in the next one. They rise until they reach a level where they are no longer competent. Then they stay there.

For a long time it was treated more as a satirical observation than a documented organizational problem. Then researchers started putting real numbers behind it.

A 2018 study published by the National Bureau of Economic Research, led by economists Alan Benson, Danielle Li, and Kelly Shue, tracked over 38,000 workers across 214 firms and found something that should make every promotion committee uncomfortable. The better an individual performed in their current role, the more likely they were to be promoted into management, and the worse outcomes their teams tended to see afterward.

A doubling of pre-promotion performance was associated with a 7.5% decline in the performance of the new manager’s direct reports. Read that again. The stronger your individual track record, the worse your team tended to perform once you became their manager.

The same study found something instructive about what actually predicts good management: collaboration experience. Workers who had regularly shared credit, coordinated across teams, and worked interdependently tended to produce measurably better outcomes as managers. Not the lone high performers. The connectors.

That is a completely different profile from the engineer who writes the best code, solves the hardest problems, and works with the most individual autonomy. Which is usually exactly the person getting the management offer.

The Chartered Management Institute surveyed over 4,500 workers and managers and found that 82% of people who enter management positions do so with no formal management or leadership training. They call them accidental managers. These are people promoted because they were good at something else, handed a team, and expected to figure the rest out on their own.

The consequences land on the people they manage. One in three workers has left a job because of a negative relationship with their manager. Among workers who described their manager as ineffective, only 15% felt valued and appreciated. Among those with an effective manager, that number jumped to 72%. The manager someone works for shapes whether they stay, whether they produce, and whether they care about the work.

Here’s what usually follows. The new engineering manager still has all the answers. Of course they do. They spent years building expertise and being rewarded for being the person with the answers. So they sit in every meeting. They review every decision. They stay in the weeds on technical work because that’s where they feel competent, and the people management side of the job feels unfamiliar and uncomfortable.

The behavior that made them a great engineer makes them a bottleneck as a manager. The team can’t move without them. Junior engineers stop developing because every decision gets escalated upward. The manager is stretched thin, doing two jobs badly instead of one job well. And everyone is frustrated, including the manager, who often misses the work they used to do and can’t figure out why this new role feels so hard.

This is textbook. It plays out constantly in engineering organizations. The most damaging part is that the organization often interprets the bottleneck as a team capability problem rather than a leadership model problem. So they hire more senior engineers to compensate, which just creates more people waiting on the same chokepoint.

Great engineering requires deep individual expertise, the ability to hold complex systems in your head, strong ownership over your own work, and a high tolerance for working through hard problems alone. Great leadership requires the opposite in several key ways: distributing ownership rather than holding it, developing other people’s capabilities rather than demonstrating your own, getting comfortable with ambiguity and imperfect decisions, and finding satisfaction in outcomes you didn’t personally create.

These aren’t just different skills. They’re genuinely in tension with each other. An engineer who has spent a decade building the habit of being the person with the right answer doesn’t shed that overnight because of a new job title.

The middle layer grows. Each promoted engineer who became a manager needed reports, so more people got hired. Those people eventually hit their own pay ceilings. The same logic applies. More managers get created through the same broken process.

Then the business hits a rough patch. Layoffs happen. The bloated management layer gets identified as overhead and people get cut or redistributed into invented roles to avoid losing them. A few years later the same cycle starts again from the beginning, because the underlying incentive structure never changed.

The real cost goes well beyond the individual engineer who struggled in a leadership role they weren’t ready for. It’s the teams that underperformed under ineffective management, the engineers who left because their manager couldn’t develop them, the organizational knowledge that walked out the door, and the time spent on a cycle that repeats because nobody addressed the root cause.

Let me be direct about something. This is not an argument against engineers moving into leadership. Some of the best leaders I’ve worked with came from engineering backgrounds. When someone genuinely wants that path and the organization actually develops them for it, real leadership can emerge.

The problem is using management as a compensation workaround for engineers who never asked for the job, and then failing to develop them once they’re in it. Those are two separate failures and organizations tend to commit both simultaneously.

There are two paths that both deserve real investment, and most organizations have only built one of them.

Most organizations haven’t built the technical track properly. Staff Engineer exists on an org chart somewhere but the pay ceiling sits below Engineering Manager, the scope is ambiguous, and the message that gets communicated, intentionally or not, is that real advancement eventually means management.

Until that changes, the cycle continues. Excellent engineers get pulled into management they didn’t ask for. Some figure it out. Many don’t. Teams suffer in the middle. The organization wonders why retention is a problem and why its best technical talent keeps leaving for companies that actually pay individual contributors what they’re worth.

The accountability here sits with the organization. The engineer who struggled as a manager usually didn’t fail because they lacked potential. They failed because the organization put them in a role they weren’t prepared for, with a skill set that doesn’t transfer cleanly, and then didn’t invest in changing either of those things.

The engineer who stayed in an IC role and got passed over for pay increases because the only real ladder went through management didn’t fail either. The organization failed them by not building a credible alternative.

These are organizational design problems that require organizational design solutions. Not individual blame, not softer performance reviews, and definitely not another round of layoffs that redistributes the same people into the same broken structure with different titles.

Highly skilled engineers who stay focused on engineering create enormous value. Developing genuine leaders from engineers who actually want to lead also creates enormous value. The organizations that figure out how to do both intentionally, at the same time, with real investment in each, tend to build something that lasts.

The ones that keep solving pay band problems by handing out management titles tend to build something different: a growing middle layer, a retention problem, and a cycle that repeats every few years until someone finally asks why.

Leadership development is something I come back to constantly. The gap between how organizations talk about developing people and what they actually do is wide, and engineering organizations are one of the places it shows up most clearly.

If this connects to something you’re seeing in your own organization, the truth about leadership development programs goes deeper on why most formal programs still miss the mark. And if you’re watching AI reshape your engineering headcount decisions right now, protecting your leadership pipeline from AI cuts is worth reading alongside this one.

A lot of what I’ve learned about where leadership actually comes from, and what separates the managers who develop people from the ones who just manage work, is in Beyond Management.

More at ericbevill.com/articles.