How do you manage an underperforming engineer?

Manage an underperforming engineer by separating skill gaps from will problems, stating expectations in writing, giving frequent specific feedback, and running a time-boxed performance improvement plan with measurable outcomes. Document conversations, involve HR early for consistency, and protect team morale while you decide whether recovery is realistic.

Why does underperformance on an engineering team feel so hard to address?

Engineering work is ambiguous, collaborative, and often invisible until something breaks in production. That makes it easy to confuse a struggling engineer with a “bad hire” or to delay hard conversations because you hope the next release will fix the pattern. Meanwhile, peers carry extra review load, incidents rise, and trust in your leadership erodes. Research on team performance consistently shows that one chronically underperforming member lowers group output and increases conflict—not because colleagues are cruel, but because fairness and reliability matter in high-trust teams.

Your job is not to win an argument about talent. It is to restore clarity: what “good” looks like in this role, whether the person can reach that bar with support, and what the team needs if they cannot. Treat managing a low performance developer as a leadership process with evidence, not a one-off emotional correction.

What should you diagnose before you label someone an underperforming engineer?

Start with facts, not vibes. Collect three to five concrete examples from the last sixty to ninety days: missed deadlines with dates, review comments that repeated the same theme, incidents tied to ownership gaps, or collaboration friction documented in retros. Compare those examples to the level expectations for their title and tenure. A mid-level engineer who misses estimates differs from a senior who cannot unblock others.

Then run a context check before you escalate. Burnout, unclear priorities, a toxic dependency, onboarding after a reorg, or a mismatch between IC work and de facto tech-lead duties can mimic underperformance. Google’s Project Oxygen and similar manager-effectiveness studies emphasize that clarity, coaching, and removing blockers often recover performance faster than replacement—when the underlying issue is environmental.

What is the step-by-step plan for managing an underperforming engineer?

Use this numbered plan as your default playbook. Adapt timing to your company’s HR policies, but keep the sequence: clarify, coach, document, formalize, decide.

1. State the gap in observable terms. Replace “not senior enough” with behaviors: “design docs do not list failure modes,” or “PRs merge with failing checks twice this month.” Share this in a 1-on-1 and confirm they understand the standard.
2. Reset expectations in writing. Email or doc a short summary: role outcomes, quality bar, collaboration norms, and how you will measure progress over the next four weeks. Written clarity prevents drift and protects everyone if you later need a performance improvement plan in engineering.
3. Increase coaching cadence. Weekly 1-on-1s should include one performance thread: what improved, what did not, and what help they need. Match your style to their maturity—direct structure for novices, questions and ownership for experienced ICs who lost focus.
4. Give constructive feedback with examples. Use recent artifacts: a PR, incident timeline, or meeting note. Describe impact on the team, not character. Ask what they will do differently before the next checkpoint.
5. Remove blockers you control. If unclear priorities, missing tools, or unfair on-call rotation contributed, fix those and say so publicly where appropriate. Teams tolerate performance management when they see you leading fairly.
6. Define two or three measurable milestones. Examples: lead one feature with design review sign-off, reduce review cycles on module X, or facilitate a retro action to completion. Milestones must be within their control and verifiable by the team.
7. Launch a formal PIP if the pattern persists. After repeated feedback on the same gaps, partner with HR on a performance improvement plan: duration, milestones, support offered, and consequences. Never surprise someone with termination without this step unless policy requires immediate action for misconduct.
8. Decide and communicate. At the end of the plan, either close it with explicit “back to standard performance,” adjust role scope, or begin separation. Tell the team only what they need to know about ownership changes; do not vent or gossip.

How do you run a fair performance improvement plan in engineering?

A performance improvement plan engineering teams respect is specific, short, and tied to the job—not a generic HR template about “attitude.” Work with HR to include: the exact behaviors that must change, success criteria, weekly manager check-ins, optional training or pairing hours, and the date of the decision meeting. Avoid piling unrelated grievances onto one document; courts and employees alike read that as bad faith.

During the PIP, your calendar is part of the intervention. Sit in on a design review, skim their PRs early, or assign a trusted peer as a temporary mentor—with consent and credit, not as unpaid babysitting. If they meet milestones, celebrate closure loudly. Nothing damages psychological safety faster than a manager who treats a successful PIP as still tainted. If they miss milestones despite real support, execute the next step promptly. Dragging out failure punishes high performers who already compensated.

How should you talk to the rest of the team?

You cannot discuss one person’s performance in detail, but you can reinforce standards. In team forums, reaffirm definition of done, review norms, and how you expect escalation when someone is stuck. When work shifts because you redeployed an underperformer, explain the new ownership map without blame. Peers often know there is a problem before you act; what they watch is whether you address it with consistency and dignity.

If resentment built because others covered gaps, acknowledge the load in 1-on-1s and adjust priorities or hiring plans where you can. Ignoring their fatigue while you “work with” one engineer for quarters is how burnout spreads through otherwise strong squads.

When is termination the right outcome?

Termination is appropriate when values violations, safety issues, or repeated disregard for commitments continue after clear feedback and a fair PIP—or when role fit is fundamentally wrong and no reasonable redeployment exists. It is also appropriate when you realize you hired far below the bar and coaching cannot close a multi-level gap in the time the business can afford.

Do not keep an underperforming engineer indefinitely to avoid discomfort. Ambiguity hurts retention among your best people. Exit with HR guidance, offer respect and clarity in the final conversation, and learn from the hiring or onboarding signals you missed.

What mistakes do engineering managers make with low performance?

• Waiting for annual review. By then, the narrative is entrenched and documentation is thin.
• Feedback without examples. Engineers need code, dates, and impact—not “you need to be more proactive.”
• Over-coaching will problems. Endless training on someone who ignores agreements burns your time and the team’s patience.
• Silent PIPs. If HR requires a plan, follow it completely; half-measures create legal and cultural risk.
• Star protection. Excusing toxic or sloppy work from a high-output individual teaches the team that performance standards are political.

Frequently asked questions

Related: Beyond the rating: 5 questions to build psychological safety in your next performance review, The Hersey-Blanchard Situational Leadership Framework, Architecting resilience: solving the engineering burnout crisis and the future of strategic leadership.

Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.