The Engineering Leadership Trap: When Good Engineers Make Bad Managers

TL;DR. Promoting the best engineer into management without changing the success criteria is how organizations get a leaderless team with a micromanager on top. The technical competence that makes someone excellent as an IC is frequently what makes the transition to management difficult — it creates a credibility anchor to the old job. The managers who navigate the transition successfully are explicit with themselves about what the new job requires before being explicit with their team. The organizations that consistently produce good engineering managers treat the transition as a structured development problem, not a sink-or-swim experiment.

The engineer had been the best technical person on the team for three years. Fast, precise, good at debugging impossible problems at midnight. When the engineering manager left, promoting them was the obvious call. It was also the call that nearly destroyed the team.

Eight months into the role, three of the five engineers they managed had started interviewing elsewhere. Velocity had dropped. The new manager was still doing individual contributor work 60% of the time, which meant their team was effectively leaderless while also feeling micromanaged on the 40% of work where they did engage.

I've seen this exact scenario unfold more times than I can reasonably attribute to coincidence. The technical competence that makes someone excellent as an individual contributor is frequently the same quality that makes the transition to management difficult.

What actually changes when you become an engineering manager — and why it is harder to accept than to understand

The job title changes. The success criteria change completely.

As an engineer, your output is code. It's measurable, reviewable, and attributable. A senior engineer who ships a complex feature cleanly has done their job. Their personal technical skill is directly visible in the work.

As an engineering manager, your output is a team. This is far more abstract and far slower to manifest. A manager who unblocks their team, makes the right architectural decisions at the right time, protects their engineers from organizational chaos, and creates an environment where people grow, that manager might not write a single line of code for months, and they will have done their job well.

The trap is that newly promoted engineering managers often don't believe this. They've built their identity and their confidence around technical expertise. The idea that their value now comes primarily from conversations, decisions, and structural changes rather than commits feels abstract to the point of being uncomfortable. So they stay in the technical work, because that's where they know they're adding value.

The team doesn't get a manager. They get a senior engineer who occasionally interrupts their work to ask questions.

The skills gap nobody teaches — and why new managers develop them slowly without structured support

Understanding that the success criteria have changed is necessary but not sufficient. The more difficult challenge is developing the new skills quickly enough to be effective before the team has degraded significantly.

Engineering management has a specific set of skills that are not adjacent to engineering skills and that are rarely taught explicitly. The ability to give effective feedback that changes behavior. The ability to navigate organizational dynamics above and around the team to protect engineers' capacity. The ability to run a hiring process that accurately predicts future performance. The ability to identify performance problems early and address them before they become team-wide issues.

None of these skills are developed through technical work. Some of them are developed through experience and reflection. Most of them develop faster with deliberate practice and a mentor or peer group who can provide honest feedback on technique.

The organizations that consistently produce good engineering managers have typically invested in the transition deliberately, not through a management training course but through structured support during the first 12 months in the role. A peer group of other engineering managers provides a safe space to discuss specific situations. A mentor with more experience can provide pattern recognition that new managers do not yet have. Regular feedback from the manager's manager on specific situations, rather than only on delivery outcomes, accelerates skill development.

The absence of this support does not mean new engineering managers cannot succeed. It means they succeed more slowly, make more recoverable mistakes, and carry more unnecessary uncertainty about whether what they are doing is right.

The signals that a new manager has not made the transition — visible before the team breaks

There are patterns that show up in a team whose manager is still operating as an IC. They tend to be invisible from the outside, the team continues shipping, the product roadmap stays on track, until something breaks and it breaks badly.

Engineers stop making decisions independently. When the manager is deeply technical and always present, the team learns to wait for their input rather than developing judgment of their own. This creates a bottleneck and a fragility: when the manager is unavailable, the team is paralyzed.

Feedback cycles collapse. Good engineering management requires regular, honest feedback conversations. When the manager is consumed with technical work, 1:1s get cancelled or become status reports. Engineers who need coaching don't get it. Problems that should be addressed at the junior level become surprises when someone quits or an engineer reaches a ceiling they shouldn't have hit.

The team doesn't grow. The most damaging long-term effect is that individual engineers stop developing because there's no one investing in their growth. The manager who stays technical tends to solve problems rather than create the conditions for their team to solve them.

Why 1:1s are the first thing to disappear — and what collapses when they do

The one-on-one meeting is the primary tool available to engineering managers for building the relationships and understanding individual engineers' circumstances that effective management requires. In teams where the manager has not made the transition, one-on-ones are typically the first thing that disappears.

The pattern is predictable: the manager is busy, the one-on-ones feel less urgent than the technical work, and they get moved, shortened, or cancelled. Over several weeks, the cadence collapses. Engineers who were used to having regular access to their manager develop a low-trust relationship with the process. They bring their concerns to peers instead of to their manager. The manager loses the signal about what is actually happening in the team.

The one-on-one disciplines that good engineering managers maintain are not complicated, but they require consistency in the face of competing demands. The meeting happens. The manager asks open questions rather than taking status updates. The engineer's agenda takes priority over the manager's. Commitments made in the meeting are tracked and followed up on. These practices do not require talent. They require discipline.

What the managers who navigate the transition successfully have in common

The managers who navigate this transition successfully usually have two things in common.

First, they're explicit about the change with themselves before they're explicit about it with their team. They have a clear-eyed conversation with themselves about what the new job actually requires, and they accept that their previous definition of "adding value" no longer applies. This sounds obvious and is genuinely difficult.

Second, they have a system for staying technically informed without doing technical work. This might mean doing structured code reviews focused on learning rather than fixing, or building time for architectural discussions that leverage their experience without creating dependency. The goal is staying connected enough to the technical reality that their decisions are grounded, without the team developing reliance on them for execution.

The organization also has a responsibility here. Promoting an excellent engineer into management and then leaving them to figure out the job change on their own is a failure at the leadership level. The expectations of the new role should be spelled out clearly, including what success looks like and what the time allocation should roughly be. Support structures, whether that's a mentor, a peer group of other new managers, or explicit coaching, are not a luxury.

The technical credibility anxiety — and why the best resolution is becoming excellent at management

One of the most common anxieties among new engineering managers is losing technical credibility with their team. This anxiety is understandable and mostly misplaced, but the way organizations respond to it matters.

Engineering managers who stayed deeply technical because they feared losing credibility are typically managers whose teams are less effective, not more. The engineers on the team need a manager who understands the technical context of their work well enough to make good prioritization decisions and remove the right obstacles. They do not need a manager who can also write the code.

The engineering managers with the highest credibility among their teams are usually not the ones who stayed most technically active. They are the ones who consistently made good decisions with the technical information available, who protected their teams from organizational overhead effectively, and who invested in their engineers' growth visibly. These are management skills that require technical understanding but are not the same as technical execution.

The credibility concern is real and worth addressing, but it is best addressed by becoming genuinely excellent at management, not by remaining excellent at individual contribution.

When management is the wrong fit — and how to know before the team pays for it

Not every excellent engineer should become a manager, and the industry is slowly getting better at accepting this. The staff engineer and principal engineer tracks at many companies exist precisely because the management path is not the only path to seniority and influence.

If you're a VP who's trying to decide whether to promote a strong IC, the most useful question to ask is not "are they ready to manage?" It's "do they want to manage, and do they understand what that actually means?" Engineers who become managers because they feel like that's the expected progression, or because the compensation structure makes management the only viable path to seniority, are much more likely to stay stuck in technical work and much less likely to build the skills they need.

The best engineering managers I've worked with chose management because they were genuinely motivated by seeing other people grow. They got satisfaction from removing obstacles. They liked having the organizational position to fix structural problems that had been frustrating them as ICs. That motivation is a better predictor of success than any technical skill.

An organization with great individual contributors and mediocre managers will always underperform one with good individual contributors and great managers. The investment in developing leadership at every level is not a soft skill initiative. It's a delivery improvement initiative.

Why dual-track career paths improve management quality — not just IC retention

The introduction of a staff or principal engineer track alongside the management track is one of the most impactful organizational design decisions available to engineering leadership. Its primary value is not providing a path for engineers who do not want to manage, though it does that. Its primary value is improving the quality of engineering management by removing the engineers who should not be managers from the management pipeline.

When management is the only path to seniority, all the engineers who want to advance become managers. This includes a significant proportion who have the technical skills to be excellent staff engineers but not the disposition or skills to be good managers. They take management roles because that is what the organization offers, not because they are well-suited to them. The team gets a manager who does not want to manage and would rather be writing code. The organization loses an excellent individual contributor and gains an ineffective manager.

The dual-track model changes the selection dynamics. Engineers who want to grow their technical impact have a path that does not require them to become managers. Engineers who want to become managers are choosing the role based on genuine interest in the work rather than as the only available advancement option. The average quality of both the individual contributors and the managers improves.

Implementing a dual-track model well requires specific investment. The staff engineer and principal engineer roles must have genuine organizational influence, not just senior IC pay grades. If the staff engineer has no power to shape architectural decisions, no influence on roadmap prioritization, and no authority to drive cross-team technical improvements, the role is a title rather than a track. Engineers will recognize this and will continue to take management roles in order to have real influence.

The development challenge that emerges in years two and three — after the "settled in" window closes

The engineers who transition into management tend to get intensive attention from leadership during the first few months of the role, then reduced attention as they are considered to have "settled in." This pattern misses the more interesting part of the development curve.

The first year of engineering management is typically characterized by two challenges: stopping the IC work and learning the basic processes of the management role. Most new managers figure these out, imperfectly but adequately. The more significant leadership development challenge emerges in years two and three, when the manager has the basics but has not yet developed the judgment required for the harder situations: the performance conversation that needs to happen but keeps getting deferred, the architectural decision with significant tradeoffs and no clearly correct answer, the team dynamic that is subtly damaging but difficult to surface.

The managers who develop into excellent engineering leaders in years two and three tend to have access to honest feedback on specific situations. A peer group of other engineering managers who can say "the way you handled that one-on-one situation is why the engineer did not feel heard" is more valuable than any management training course. The feedback loop is the developmental mechanism.

Organizations that have built peer-group development programs for engineering managers, structured conversations around real situations rather than case studies, see measurably better retention among their engineering management cohort and better delivery outcomes from teams led by those managers. The investment is modest and the return is substantial.

How to measure whether a new manager is actually making the transition

Engineering organizations rarely measure the outcomes of IC-to-manager transitions systematically. They track whether the new manager passed their first performance review. They do not track the attrition rate in the teams of new managers, the change in delivery metrics for those teams, or the career trajectory of the engineers who reported to new managers during their first year.

These measurements are available and would be informative. Teams managed by new managers who have not fully made the transition from IC to management mode tend to have higher attrition than teams managed by experienced managers. They tend to have lower code review velocity because the manager is creating a review bottleneck rather than developing reviewers. And they tend to have lower junior engineer satisfaction, because the investment in their development is not being made.

Tracking these outcomes would provide engineering organizations with the data to answer a question they currently answer by intuition: is this manager making the transition successfully? The intuition-based answer often arrives too late, after attrition has already occurred. The data-based answer arrives earlier and with enough lead time to intervene with additional support.

The measurement framework for new manager effectiveness is not complicated: the four DORA metrics for the team, the team attrition rate, and the developer satisfaction score from the team's direct reports. These data points, tracked quarterly, provide a clear signal. Teams where all three are moving in the right direction have managers who are making the transition effectively. Teams where one or more is deteriorating have managers who need additional support or, in some cases, a conversation about whether management is the right path.

Frequently asked questions

What breaks in a team when the manager does not make the transition from IC to manager?

Three things, in order. Engineers stop making decisions independently — when the manager is always present with a strong technical opinion, the team learns to wait rather than developing judgment of their own. Feedback cycles collapse — 1:1s get cancelled or become status reports, and engineers who need coaching do not receive it. Individual engineers stop developing — the manager solves problems rather than creating conditions for the team to solve them. These patterns are invisible from outside until someone quits, and then the departure is surprising even though all three signals were present for months.

How does a new engineering manager stay technically credible without doing IC work?

By becoming genuinely excellent at management rather than staying excellent at individual contribution. The engineering managers with the highest credibility among their teams are consistently the ones who make good decisions with available technical information, protect their teams from organizational overhead effectively, and invest visibly in individual engineers' growth. Credibility in management comes from management skills that require technical understanding — but they are not the same as technical execution.

What is the most important support structure for a new engineering manager?

A peer group of other engineering managers who can provide honest feedback on specific real situations. Not a management training course. Not a mentor with abstract advice. A structured peer conversation where someone can say "the way you handled that 1:1 situation is why the engineer did not feel heard." That feedback loop is the developmental mechanism. Organizations that have built it see measurably better retention in their engineering management cohort and better delivery outcomes from the teams those managers lead.

How do dual-track career paths improve management quality?

When management is the only path to seniority, engineers who have excellent technical skills but no interest in management take management roles because that is what the organization offers. The team gets a manager who would rather be writing code. When a staff or principal engineer track exists with genuine organizational influence over architectural decisions and roadmap prioritization, the selection into management improves — engineers choose it based on genuine interest in the work. Average management quality rises alongside average IC quality.

---

If your engineering organization is experiencing friction that might trace back to leadership development gaps, reach out. The diagnostic is often quicker than you would expect.

For the developer experience dimension of this problem — why engineers leave when leadership does not fix the environment — read why developers are quitting — and why it is not about compensation.

For the measurement work that makes leadership decisions data-driven rather than intuition-driven, read why DORA metrics are lying to you — signal integrity in platform engineering.

For how the platform team maturity level affects engineering leadership's ability to deliver outcomes, read 5 signs your platform team is stuck in ad-hoc mode.

For the ROI conversation that lets engineering leaders defend platform investment to senior leadership, read platform engineering ROI — what to measure and how to defend it.

The Foundations Assessment produces the baseline data that replaces intuition-driven leadership decisions with evidence — a gap analysis across all five platform capability pillars in four to six weeks.