How to Deal with an Underperforming Engineer on Your PM Team (Without HR)
TL;DR
You cannot fix a broken engineer with empathy alone; you must document specific behavioral gaps against engineering standards within 14 days or risk your own credibility as a leader. The solution is not a heart-to-heart conversation but a rigid, data-driven feedback loop that forces a decision: improve immediately or exit. Waiting for HR to solve this is an admission that you lack the operational control required for product leadership.
Who This Is For
This guide targets Product Managers managing technical teams who have discovered a critical performance gap but lack direct hiring/firing authority or immediate HR support. You are likely a PM at a mid-stage startup or a specialized unit within a larger corp where headcount is frozen, and the engineer in question holds institutional knowledge you cannot afford to lose tomorrow.
Your base salary is likely between $165,000 and $210,000, and your bonus depends on shipping features this quarter, not on how nicely you manage interpersonal conflict. If you are waiting for a formal performance improvement plan template from Human Resources, you have already lost the quarter.
Why Does Waiting for HR to Intervene Often Make the Performance Problem Worse?
Waiting for HR to intervene transforms a manageable performance issue into a terminal leadership failure because HR operates on legal risk mitigation, not product velocity. In a Q3 debrief I led for a fintech scale-up, a PM spent six weeks "gathering evidence" while waiting for an HR business partner to return from leave, during which the underperforming senior engineer introduced three critical regression bugs that delayed our Series C due diligence by two months.
The problem isn't your lack of authority; it's your misconception that HR exists to fix people. HR exists to protect the company from lawsuits; your job is to protect the product from mediocrity. When you delay action hoping for an external savior, you signal to the rest of the team that low performance is tolerable as long as no one complains loudly enough to trigger a formal process.
The counter-intuitive truth is that the longer you wait to address the issue without HR, the harder it becomes to remove the engineer later. I watched a hiring committee reject a transfer request for a struggling engineer because the PM had "managed around" the issue for nine months, creating a paper trail of positive quarterly reviews that contradicted the sudden claim of incompetence.
You are not being kind by waiting; you are creating a legal and logistical trap. The moment you identify a pattern of missed commits, vague technical explanations, or inability to debug without hand-holding, the clock starts. You have exactly two weeks to establish a documented baseline of failure before your silence becomes complicity.
What Specific Evidence Do You Need to Prove Underperformance Without Subjective Bias?
You need objective, time-stamped data points that map directly to engineering output standards, not subjective feelings about "attitude" or "culture fit." During a tense calibration session at a cloud infrastructure company, a hiring manager dismissed a PM's concerns about an engineer's "lack of urgency" until the PM presented a spreadsheet showing the engineer took 48 hours to resolve bugs that peers solved in 4 hours, with a 40% re-open rate on pull requests.
The judgment here is binary: if you cannot quantify the gap, you do not have a performance problem you can solve; you have a perception problem you need to adjust. Stop saying the engineer is "slow" and start measuring cycle time, bug introduction rate, and the ratio of planning time to shipping time.
The first counter-intuitive insight is that anecdotal evidence from other team members is often more damaging than helpful in these scenarios. In one instance, a PM collected quotes from three designers saying the engineer was "hard to work with," which the engineer's manager immediately flagged as hearsay and potential harassment, derailing the performance conversation entirely.
Instead, focus exclusively on the artifact: the code review comments that were ignored, the API specifications that were misinterpreted, and the deadlines missed without prior communication. Your evidence must be so concrete that if you handed it to a stranger, they would independently conclude the engineer is not meeting the bar. If your evidence requires your personal interpretation to make sense, it is weak.
How Can You Structure a Feedback Conversation That Forces Accountability Without Authority?
You must structure the conversation as a factual review of gaps against expectations, removing all emotional language and leaving no room for ambiguity about the consequences of inaction.
I recall a specific scene where a PM sat down with a struggling backend engineer and opened with, "In the last sprint, three of your five tickets were blocked by missing schema definitions, which delayed the frontend team by 120 hours; this is a pattern that puts your role at risk," rather than asking, "How are you feeling about your workload?" The difference is the distinction between a coaching chat and a performance intervention. You are not their therapist; you are the guardian of the product roadmap.
The second counter-intuitive truth is that expressing empathy too early in a performance conversation often dilutes the severity of the message. When a PM starts with "I know you're going through a lot," the engineer hears "I have an excuse," and the urgency evaporates.
Instead, state the facts, state the impact, and then ask a single, sharp question: "What is your plan to ensure zero schema errors in the next 48 hours?" This forces the engineer to commit to a specific behavioral change rather than offering a sob story. If they cannot produce a plan, you document the refusal. Your goal is not to make them feel better; it is to make the cost of underperformance undeniable.
When Should You Escalate to Engineering Leadership Instead of Handling It Yourself?
You should escalate to engineering leadership the moment the engineer fails to meet a specific, agreed-upon micro-commitment within your documented feedback loop.
In a high-stakes scenario at a consumer social app, a PM waited until the engineer missed a critical launch deadline before escalating to the VP of Engineering, only to be told, "Why am I hearing about this now when you've known for three sprints?" The escalation signal is not the severity of the bug, but the failure of the correction mechanism. If you have provided clear data, set a micro-deadline, and the engineer still failed, you have exhausted your leverage as a PM and need the engineer's manager to intervene.
The third counter-intuitive insight is that escalating too early can sometimes save an engineer, while escalating too late guarantees their exit. If you bring an issue to an engineering manager while it is still a "pattern of slowness," the manager can reassign tasks, provide mentorship, or adjust scope.
If you wait until the engineer has actively blocked a release, the manager has no choice but to treat it as a crisis, often leading to immediate removal discussions that bypass rehabilitation. Your timing dictates the outcome. Escalate when the data shows a trend, not when the trend becomes a disaster.
What Are the Risks of Trying to "Manage Around" a Low-Performing Engineer?
Trying to "manage around" a low-performing engineer destroys team morale and accelerates the departure of your top performers. I witnessed a scenario where a PM quietly reassigned complex tasks away from a struggling senior engineer to keep the project moving, which the rest of the team interpreted as favoritism or incompetence on the PM's part.
Within six weeks, two high-performing engineers updated their resumes, citing "uneven standards" as their reason for leaving. The cost of replacing those two engineers exceeded $400,000 in recruiting fees and lost productivity, all because the PM was afraid to confront the underperformer directly.
The problem isn't your desire to keep the peace; it's your failure to recognize that high performers demand equity in workload distribution. When you absorb the slack for an underperformer, you are effectively penalizing your best people by giving them harder work and the same credit. This is not leadership; it is cowardice disguised as teamwork. The only sustainable path is to either bring the underperformer up to speed through rigorous accountability or remove them from the equation. There is no middle ground where you hide their incompetence forever.
Preparation Checklist
- Identify the single most critical metric where the engineer is failing (e.g., cycle time, bug rate) and gather 5 specific data points from the last 14 days.
- Draft a written summary of the gap that contains zero adjectives describing personality, focusing only on actions and outcomes.
- Schedule a 30-minute sync specifically labeled "Performance Feedback" to ensure the gravity is understood, avoiding casual coffee chats.
- Prepare one specific micro-commitment for the engineer to agree to within the next 48 hours as a test of responsiveness.
- Work through a structured preparation system (the PM Interview Playbook covers stakeholder management and difficult conversation frameworks with real debrief examples) to rehearse your opening statement until it is devoid of emotional leakage.
- Review your company's engineering ladder or job description to align your feedback with official competency levels.
- Set a calendar reminder for 48 hours post-meeting to follow up in writing, regardless of the meeting's tone.
Mistakes to Avoid
Mistake 1: The "Sandwich" Feedback Method
BAD: "You're great at coding, but you're missing deadlines, though we really like you." This confuses the recipient and dilutes the urgency.
GOOD: "Your code quality is high, but missing deadlines by 2 days per sprint is unacceptable and risks your role. We need a plan to fix the timing immediately."
Mistake 2: Relying on Vague "Vibe" Checks
BAD: Telling an engineer, "You just don't seem engaged," which is subjective and defensible.
GOOD: Stating, "You have spoken less than 5 minutes in the last 5 stand-ups and missed 3 code reviews without comment," which is factual and undeniable.
Mistake 3: Delaying Documentation
BAD: Keeping a mental note of issues to discuss during the annual review, rendering them legally and operationally useless.
GOOD: Sending a summary email within 1 hour of the conversation stating, "As discussed, the expectation is X, and the failure to meet Y on date Z is the current gap."
More PM Career Resources
Explore frameworks, salary data, and interview guides from a Silicon Valley Product Leader.
FAQ
Can a PM fire an engineer directly?
No, Product Managers rarely have direct firing authority; your role is to document the performance gap and escalate to the engineering manager or HR with irrefutable data. Attempting to fire someone without proper process exposes the company to legal risk and will likely result in your own disciplinary action. Your power lies in influence and data, not administrative termination rights.
How long should I wait before escalating an underperformance issue?
You should wait no longer than two weeks or two sprint cycles after identifying a clear pattern of failure. Waiting longer suggests the issue is not urgent to you, and it allows the behavior to become entrenched. Immediate documentation and a rapid feedback loop are required to establish that this is a critical business issue.
What if the engineer claims I am micromanaging them?
Reframe the conversation from "how they work" to "what they deliver" by pointing to specific missed commitments and quality gaps. Micromanagement is controlling the process; performance management is enforcing the standard. If they cannot meet the standard without your intervention, they are not performing at the required level, and that is the core issue to address.