Common Engineering Manager Pitfalls (And How to Stop Doing Them)

It's Sunday night. You're reviewing a PR your staff engineer opened on Friday because nobody else "had the context." Your 1:1 doc with your most senior report has the same three bullets it had six weeks ago. You haven't run a retro since the reorg. You tell yourself you're a coaching manager. Your team would describe you as "nice but absent."

This guide is the gap.

I've been the bad EM in every one of these stories. I'm not going to moralize. I'm going to name the pattern, give you the number that quantifies the damage, and tell you exactly what to do this week. You can read Lara Hogan and Will Larson and Camille Fournier all year, but until you metabolize the advice into changed behavior on a Tuesday morning, your team is still suffering the version of you that hasn't read any of it.

Why This Matters Now

First-year EMs get graded on two things: team output and team retention. Most miss on retention because the failure modes are invisible until somebody resigns. By then it's a 3-month backfill, a 6-month ramp, and roughly $180K-$250K in fully-loaded cost per departure once you add loaded engineer comp, recruiter fees, and ramp drag on the team they left behind.

Two regrettable departures in a year wipes out most of the productivity gain you delivered. And you can't manage what you don't see, so the first job is to name the patterns. Here are the seven that show up most often in 6-18 month EMs.

Pitfall 1: Coding Instead of Coaching

Symptom. You're closing 3-8 PRs a week of your own. You tell yourself it's "unblocking the team." It's actually you avoiding the harder, slower work of deciding which person on the team should grow into that piece of the code.

Real number. Every hour you spend coding is roughly 1.5-2 hours of team coaching foregone, because coaching is interrupt-driven and you're now heads-down and unavailable. For a team of six, that's about 10 lost coaching hours a week. Over a quarter, you've stolen ~130 hours, or one full sprint of senior development time, from your reports' growth.

Fix. Cap your IC contribution at 10% of your week. Block it on your calendar, label it "IC time," and when the time is gone, it's gone. Hand the next "I'll just do this one" task to the report whose growth area it touches, and tell them why you're handing it to them: "This is the kind of work that gets you to senior. I want you to own it, and I want to review the design before you start." That last sentence is the difference between a handoff and a dump.

Pitfall 2: Skipping the Hard 1:1

Symptom. Your weekly 1:1 with the senior who ships but is toxic in code review keeps "running out of time" before you raise the behavior. Three months later, two people on the team are interviewing somewhere else.

Real number. Average tenure of an engineer who has a peer they consider toxic and a manager who hasn't addressed it: 8-11 months. Average tenure of an engineer whose manager named the behavior inside the first four weeks: 2.5+ years. The delta is one full backfill cost per year of avoidance, plus the cultural tax on the rest of the team who watched you not act.

Fix. If you've been dodging a topic for two weeks or more, the next 1:1 opens with it. No throat-clearing, no "how was your weekend." Script: "I want to use the first 15 minutes for a hard conversation about how code review is going. I've heard X from two peers. Walk me through your perspective." Do not soften the open. Soften the listening. The most common reason this conversation goes badly isn't that you said the wrong thing. It's that you said the right thing for 30 seconds and then spent the next 14 minutes apologizing for it.

Pitfall 3: Over-Relying on Velocity Metrics

Symptom. You quote story points in skip-levels. You celebrated a 20% velocity bump last quarter that came from a senior re-pointing the backlog, not from any change in actual throughput. When asked how the team is doing, "velocity is up" is the first thing out of your mouth.

Real number. Roughly 70% of velocity changes in a given quarter are estimation drift, not real productivity change. Teams that manage to velocity see DORA change failure rate climb 15-25% within two quarters, because they cut testing depth and review rigor to keep the points number flattering. You optimized for the dashboard and damaged the system underneath it.

Fix. Replace velocity in your weekly report with three numbers: deploy frequency, change failure rate, and time-to-recover. If your org doesn't track them, instrument them yourself in a spreadsheet for one quarter. It takes about 90 minutes to set up and 10 minutes a week to maintain. Bring DORA to your skip-level and explain why you're moving off points. The first time you do this, your skip will respect you more, not less. Stop quoting points.

Pitfall 4: Under-Documenting Promotion Criteria

Symptom. You have one report who "feels close" to senior and another who "isn't quite there yet." If somebody asked you to write down the difference between them in 90 seconds, you couldn't. You'd talk about "presence" and "ownership" and "judgment" and the room would politely nod.

Real number. Promotion outcomes correlate about 0.4 with documented criteria and about 0.7 with manager confidence and recency bias when criteria aren't written. The gap shows up in calibration as "I trust your read," which is how the loud get promoted and the quiet stall. The cost lands on the team about 18 months later, when the strongest IC, who got passed over without a clear reason, leaves for a company that gave them one.

Fix. This week, write a one-page "what staff looks like on this team" doc. Three sections: scope, impact, behaviors. Put 4-6 concrete examples under each, drawn from people you'd promote tomorrow. Share it with every report in their next 1:1, not in a vague "here's the doc, let me know if you have questions" email. Walk them through it. Ask where they think they are. Use the same doc in calibration. Update it quarterly. The doc isn't the goal; the conversation it forces is the goal.

Pitfall 5: Shielding the Team From Context (Badly)

Symptom. You "protect the team from politics" by not telling them the project is at risk, the headcount is frozen, or the customer hates the v1. They find out via a Slack channel two weeks later, often from somebody who doesn't even work on your team. Then they ask you about it and you say something like, "Yeah, I was going to mention that."

Real number. Engineers who feel under-informed score 30-40 points lower on engagement surveys than peers who feel over-informed. Bottom-quartile engagement predicts attrition within 12 months at 2-3x the base rate. Translation: bad shielding costs you roughly one in every four reports per year, and the four you lose are the four with options.

Fix. Default to share. The test isn't "will this stress them out," it's "would I want to know this if I were them." Run a weekly 15-minute team standup-of-context: what changed at the leadership level, what's still uncertain, what they should ignore. If something is genuinely too sensitive, say "there's a thing I can't share yet, here's when I expect to be able to." That sentence buys more trust than any euphemism. Engineers can tell the difference between a manager who's protecting them and a manager who's protecting themselves.

Pitfall 6: Not Running Retros (Or Running Fake Ones)

Symptom. Last retro was 11 weeks ago. Or you do run them, but the actions never get owners or due dates, so the same three problems show up in every retro forever. Somebody mentions deploys are still painful. Everyone nods. Nothing happens. Next retro, somebody mentions deploys are still painful. Everyone nods.

Real number. Teams running real retros, with named owners and dates and follow-up at the next retro, ship about 25% more incident-free quarters than teams that don't run them. Teams running fake retros score the same as teams running zero, which means the ritual without the loop is actively worse than nothing. You've taught the team that surfacing problems doesn't fix them, which is a much harder lesson to undo than starting from scratch.

Fix. Cadence: every two sprints, 60 minutes, no exceptions. Format: four columns (kept, dropped, doing more of, blocked on). Every action gets an owner-name and a date. Track the actions on a public board. Open the next retro by reviewing the previous actions. If less than 70% are closed, that's the conversation, and you skip the brainstorm. The team will object the first time. Do it anyway. Two cycles in, they'll start showing up with actions already named, because they know you'll check.

Pitfall 7: Hiring Slow Because Hiring Is Hard

Symptom. You have an open req that's been open for four months. You've interviewed eight candidates. None were "the bar." Meanwhile your team has been at 80% capacity for a quarter and your strongest senior is doing two people's jobs and starting to look tired in 1:1s.

Real number. Cost of an open senior req at typical SaaS comp: roughly $20K-$30K a month in foregone output, plus the load you're putting on the rest of the team, which raises their attrition risk (see Pitfall 5). A four-month open req has cost the company $100K and probably bought you a regrettable departure on top of it. The bar you're holding has now cost more than two cheaper hires would have cost combined.

Fix. Define the bar in writing: three must-haves, three nice-to-haves. Run every interview loop against that doc, not against vibes. If you've rejected five candidates in a row, the bar is the problem, not the market. Either lower it deliberately and tell your skip-level why, or split the role into two cheaper hires who can grow into one strong one. The companion Staff Software Engineer Job Description is a good starting point for what "the bar" looks like written down. Stop holding out for a unicorn while your team burns. The unicorn isn't coming, and the team is the asset you actually have.

Putting It Together: A 30-Minute Self-Audit

Set a timer. For each of the seven pitfalls above, score yourself 1-5. Be honest. Your skip-level already knows.

Anything 3 or below: pick one fix from this guide, calendar it for this week, and tell one peer EM what you committed to so you can't quietly drop it. Don't try to fix all seven at once. You'll bounce off all of them. Pick the lowest score, run that fix for two weeks, then audit again.

The reason this works and "I'll be more intentional about coaching" doesn't is that the fix is a calendar block, not an aspiration. Calendar blocks survive Mondays. Aspirations don't.

What Good Looks Like 90 Days From Now

Concrete picture. If you ran the audit this week and committed to one fix per fortnight, here's the team you should have by August:

• You ship code less than 10% of your week and you don't feel guilty about it.
• You've had at least two hard 1:1s and the team is better for them, not worse.
• Your weekly report leads with deploy frequency and change failure rate, not story points.
• Every report knows what the next level looks like for them, on paper, and has had at least one conversation with you about where they are against it.
• The team gets context defaults-shared, not defaults-shielded, and your weekly context standup is a habit nobody questions.
• Retros run on a two-sprint cadence with a closed action log that's >70% on time.
• No req has been open more than eight weeks without a written bar-recalibration.

None of this requires a personality transplant. It requires deciding that the version of you who tolerates these patterns is the one your team is paying for, and then making one change at a time until they're not.

Learn More

• The First 30/60/90 Days as a New EM
• Running 1:1s With Engineers That Move Things
• EM Metrics: Velocity, Quality, Retention, Hiring
• Promotion and Performance Conversations
• Staff Software Engineer Job Description