Coaching Underperformers to Improve
Table of Contents
- Introduction
- 1. Core Principles
- 2. Practical Frameworks
- 3. Common Mistakes
- Mistake 1: Waiting Too Long to Address the Issue
- Mistake 2: Being Vague or Indirect
- Mistake 3: Making It Personal Instead of Behavioral
- Mistake 4: Not Listening to Their Perspective
- Mistake 5: Providing Solutions Instead of Coaching to Solutions
- Mistake 6: Not Following Through on Your Commitments
- Mistake 7: Confusing Underperformance with Misalignment
- Mistake 8: Coaching Someone Who Shouldn't Be Coached
- 4. Real Scenarios
- 5. Practice Exercises
- 6. Key Takeaways
- Appendix: Quick Reference Checklist
- Interview Practice
Introduction
As a technical leader, one of your most challenging yet impactful responsibilities is coaching engineers who are not meeting performance expectations. This is not about managing out or giving up on people—it’s about investing in their growth, unlocking their potential, and building a stronger team. The ability to coach underperformers effectively separates adequate leaders from exceptional ones.
This guide will help you develop a systematic, empathetic approach to performance coaching that respects the individual while maintaining accountability to the team and organization.
1. Core Principles
Why This Skill Matters
For the Individual: Underperformance is often a symptom of misalignment, unclear expectations, skill gaps, or external factors. Without intervention, talented engineers can spiral into disengagement, lose confidence, and ultimately fail. Effective coaching can redirect this trajectory and unlock capabilities they didn’t know they had.
For the Team: One underperformer impacts team morale, creates resentment among high performers who compensate for the gap, and establishes dangerous precedents. When you coach someone successfully, you send a message that growth is possible and that you invest in your people.
For You as a Leader: Your credibility comes from how you handle difficult situations. Leaders who avoid performance conversations lose respect. Leaders who handle them poorly create fear and resentment. Leaders who handle them well build trust and psychological safety.
The Foundation: Assume Positive Intent
Most people do not wake up wanting to underperform. Behind every performance issue is a story: unclear expectations, skill mismatch, personal challenges, lack of feedback, or misaligned priorities. Your job is to uncover that story with genuine curiosity, not judgment.
This doesn’t mean being naive. Some people are in the wrong role or unwilling to grow. But starting with the assumption that they want to succeed—and that you can help them—transforms the conversation from adversarial to collaborative.
The Coaching Mindset vs. The Manager Mindset
Manager mindset: “You’re not meeting expectations. Fix it or there will be consequences.”
Coaching mindset: “I see a gap between where you are and where you need to be. Let’s figure out together what’s causing it and how I can help you close it.”
The coaching mindset assumes partnership. It acknowledges that you have responsibility too—perhaps you haven’t been clear enough, haven’t provided the right support, or haven’t created conditions for success.
Performance Issues Are Systems Problems
When someone underperforms, it’s rarely just about them. Consider:
- Role clarity: Do they truly understand what success looks like?
- Skills: Do they have the capabilities required, or can they develop them?
- Environment: Are there systemic blockers (unclear requirements, thrashing priorities, poor tooling, toxic team dynamics)?
- Feedback loops: Have they been getting regular, specific feedback, or is this a surprise?
- Motivation: Are they working on things they find meaningful? Do they see a path forward?
Your first responsibility is to examine the system before concluding the problem is solely the individual.
The High-Stakes Nature of Performance Conversations
These conversations carry weight. Handle them poorly and you can:
- Destroy someone’s confidence and motivation
- Create legal liability for the organization
- Damage your credibility with the rest of the team
- Miss opportunities to develop talent
Handle them well and you can:
- Transform an underperformer into a strong contributor
- Build deep trust and loyalty
- Establish a culture of accountability and growth
- Demonstrate leadership that earns respect
2. Practical Frameworks
Framework 1: The Performance Coaching Cycle
This is a systematic approach to performance coaching that moves from diagnosis to action to accountability.
Step 1: Diagnose the Root Cause
Before any conversation, investigate. Gather data from multiple sources:
Objective evidence:
- Code review feedback and patterns
- Sprint completion rates and velocity
- Bug rates and severity
- Design review outcomes
- Missed deadlines and commitments
Subjective signals:
- Peer feedback (seek it discretely)
- Your own observations in meetings
- Engagement levels and communication patterns
- Responses to feedback
Self-assessment:
- Have you been clear about expectations?
- Have you provided adequate support and resources?
- Are there environmental factors you control that are contributing?
Common root causes you might uncover:
- Skill gap: They don’t know how to do what’s expected (e.g., junior engineer expected to architect systems, backend engineer struggling with frontend work)
- Clarity gap: They don’t understand what’s expected (vague acceptance criteria, unclear priorities, conflicting signals from different stakeholders)
- Motivation gap: They don’t care about the work (disengaged, burned out, working on things they find boring or meaningless)
- Capacity gap: They have too much on their plate (unrealistic workload, competing priorities, personal circumstances reducing availability)
- Behavioral gap: They have the skills but demonstrate poor judgment, communication, or professionalism (not responding to feedback, missing meetings, poor collaboration)
- Organizational gap: Systems are broken (requirements constantly change, technical debt is overwhelming, poor tooling, toxic dynamics)
The root cause determines your coaching approach.
Step 2: Have the Initial Coaching Conversation
Set the right context:
Schedule a private 1:1 with adequate time (45-60 minutes). Be explicit that this is a performance conversation. Don’t ambush them.
Example: “I’d like to schedule time to discuss some performance gaps I’ve observed. I want to understand what’s happening from your perspective and work together on a plan to get you back on track.”
Open with care and specificity:
Start by acknowledging that this conversation is difficult but necessary. Then present specific, factual observations. Avoid generalizations.
Poor opening: “You’re not pulling your weight on the team.”
Better opening: “I want to talk about some patterns I’ve noticed. Over the last two sprints, you’ve committed to 8 story points but completed 3. In code review, you’ve received consistent feedback about error handling that hasn’t been incorporated into subsequent PRs. I want to understand what’s going on and how I can help.”
Listen more than you talk:
After presenting your observations, ask open-ended questions and genuinely listen:
- “What’s your perspective on this?”
- “What’s been challenging for you lately?”
- “Is there something I’m not seeing or understanding?”
This is where you discover the root cause. Don’t interrupt, don’t defend, don’t problem-solve yet. Just listen.
Collaborate on diagnosis:
Once you’ve heard their perspective, synthesize:
“So it sounds like you’ve been struggling with the Redux architecture because your prior experience was all in backend services, and you haven’t felt comfortable asking for help because everyone seems so busy. Is that accurate?”
Get alignment on the diagnosis before moving to solutions.
Co-create an improvement plan:
Don’t dictate a plan. Build it together:
“What do you think would help you get up to speed on Redux?” “How can I support you in getting the help you need when you’re stuck?” “What would success look like for you in the next sprint?”
The plan should include:
- Clear, measurable expectations: What does good performance look like? Be specific.
- Concrete actions from both of you: What will they do? What will you do to support them?
- Milestones and checkpoints: When will you assess progress? Weekly 1:1s? Mid-sprint check-ins?
- Timeline: What’s the timeframe for improvement? (Typically 30-90 days depending on the gap)
Document the plan:
Send a written summary after the meeting. This protects both of you and ensures alignment.
Example:
“Following up on our conversation today, here’s what we agreed to:
Current gap: You’re completing ~40% of committed story points, and recurring code review feedback on error handling and testing isn’t being incorporated.
Root causes we identified:
- Unfamiliarity with Redux patterns after transitioning from backend
- Hesitation to ask questions when stuck
- Unclear priorities when balancing new features with tech debt
Improvement plan:
You will:
- Complete the Redux fundamentals course by end of next week
- Pair with Sarah for 2 hours this week on the authentication flows to see Redux patterns in practice
- Bring questions to daily standups when blocked for more than 1 hour
- Commit to 5 story points next sprint (reduced from 8) to focus on quality over quantity
I will:
- Schedule weekly 1:1s for the next 4 weeks to check in on progress
- Connect you with Sarah for pairing sessions
- Review your PRs within 24 hours to provide rapid feedback
- Provide clearer sprint planning with prioritized backlog
Success criteria for next 30 days:
- Complete 80%+ of committed story points
- Zero recurring code review feedback on the same issues
- Demonstrate improved Redux understanding through code quality
We’ll formally review progress in 30 days. I’m confident you can close this gap, and I’m here to support you.”
Step 3: Provide Ongoing Support and Feedback
The plan is not a one-time intervention. Your job now is to:
Increase touchpoints: Weekly 1:1s, mid-sprint check-ins, more frequent code reviews with detailed feedback.
Be present: Make it clear you’re invested. If you committed to responding to PRs in 24 hours, do it. If you said you’d set up pairing sessions, do it.
Catch progress and reinforce it: When you see improvement, name it specifically. “Your last three PRs have shown much stronger error handling. That’s the level I expect—great work.”
Address setbacks quickly: If they miss a commitment or regress, address it immediately in your 1:1. Don’t let issues accumulate.
“You committed to completing the Redux course by end of last week, but you mentioned in standup yesterday that you haven’t started. What happened? How can we get this back on track?”
Adjust the plan if needed: If you discover new root causes or the original plan isn’t working, adapt. This is a collaborative process.
Step 4: Assess Progress and Decide Next Steps
At the end of your agreed timeline (30, 60, or 90 days), have a formal progress review.
Scenario A: Significant improvement
“You’ve closed the gap. You’re now completing 90% of your commitments, code review feedback has dropped significantly, and you’re proactively asking questions when stuck. This is the level of performance I expect going forward. Great work.”
Transition back to normal 1:1 cadence, but continue to monitor. Sometimes people regress when they feel the pressure is off.
Scenario B: Some improvement but still below bar
“You’ve made progress—your Redux skills have clearly improved and you’re asking more questions. But you’re still only completing 60% of your commitments, and testing gaps remain. We need to see more. Let’s continue for another 30 days with adjusted goals.”
Be clear about the stakes: “If we don’t see you hit 80% by the end of next month, we’ll need to have a conversation about whether this role is the right fit.”
Scenario C: Minimal or no improvement
“We set clear expectations 60 days ago, and despite the support and resources we’ve provided, the gaps remain. You’re still completing less than half of your commitments, and recurring feedback isn’t being incorporated. At this point, I don’t believe this role is working out.”
This leads to a performance improvement plan (PIP) or transition off the team. This is hard, but it’s fair when you’ve genuinely tried to help.
Framework 2: The GROW Model (for Ongoing Coaching Conversations)
The GROW model is useful for regular coaching conversations, not just formal performance interventions.
G - Goal: What do you want to achieve?
“What are you hoping to accomplish in this sprint?” “What would make this quarter a success for you?”
R - Reality: Where are you now?
“What’s working well? What’s been challenging?” “How confident do you feel about your current approach?”
O - Options: What could you do?
“What are some ways you could tackle this?” “If you had no constraints, what would you try?”
W - Way Forward: What will you do?
“Which option feels most promising? What’s your next step?” “What support do you need from me?”
This framework keeps coaching conversations structured but collaborative. It empowers the engineer to own their growth while you guide.
Framework 3: The Situation-Behavior-Impact Model (for Delivering Difficult Feedback)
When you need to address a specific performance issue in the moment:
Situation: “In yesterday’s architecture review…”
Behavior: “…you interrupted Sarah three times while she was presenting, and when she finished, you dismissed her concerns without asking questions.”
Impact: “This undermined her credibility in front of the team and shut down potentially valuable technical discussion. It also made others less likely to share dissenting opinions.”
Path forward: “In future reviews, I need you to let people finish their thoughts and ask clarifying questions before offering your perspective. Can you commit to that?”
This model keeps feedback factual, behavioral, and focused on impact rather than personal attacks.
3. Common Mistakes
Mistake 1: Waiting Too Long to Address the Issue
What it looks like: You notice performance gaps but hope they’ll self-correct. You don’t want to “demotivate” the person or “seem negative.” Months pass. The gap widens. Frustration builds. Finally, you have a conversation, but by then the issue has calcified and the person is blindsided.
Why it’s harmful:
- The person had no opportunity to course-correct early
- The team has been carrying the burden for months
- You’ve lost credibility for tolerating underperformance
- Recovery is much harder after months of bad patterns
What to do instead: Address issues within 2-3 weeks of noticing a pattern. One bad week isn’t a pattern. Three is.
Mistake 2: Being Vague or Indirect
What it looks like:
You: “I think maybe there’s some room for improvement in your… you know, output quality.”
Them: “Okay, I’ll try to do better.”
Neither of you knows what that means.
Why it’s harmful: Vague feedback is useless. The person can’t act on it, and you can’t measure whether it’s been addressed.
What to do instead: Be uncomfortably specific.
“In the last sprint, you committed to 8 story points but completed 3. The login feature you delivered had 5 bugs found in QA, 3 of which were critical. This is below the standard I expect, which is completing 80%+ of commitments with fewer than 2 non-critical bugs per feature.”
Mistake 3: Making It Personal Instead of Behavioral
What it looks like:
“You’re lazy.” “You don’t care about quality.” “You’re not a team player.”
Why it’s harmful: These are character attacks, not actionable feedback. They trigger defensiveness and shut down learning. Even if true, they’re useless.
What to do instead: Focus on observable behaviors and outcomes.
Instead of “You’re lazy” → “You’ve missed three deadlines in the past month without communicating blockers in advance.”
Instead of “You don’t care about quality” → “Your last four PRs have been merged without tests, despite testing being a requirement for all new features.”
Mistake 4: Not Listening to Their Perspective
What it looks like: You’ve decided what the problem is and what the solution is. You deliver it as a monologue. They nod, leave, and nothing changes.
Why it’s harmful: You might have misdiagnosed the root cause. Even if you’re right, people don’t commit to plans they didn’t help create.
What to do instead: Ask questions and listen deeply.
“I’ve noticed X, Y, and Z. Before we talk about next steps, I want to understand what you’re experiencing. What’s been challenging for you?”
Then actually listen. Their perspective might reveal factors you didn’t know about.
Mistake 5: Providing Solutions Instead of Coaching to Solutions
What it looks like:
Them: “I’m struggling to estimate stories accurately.”
You: “Just use the Fibonacci sequence and multiply by your average velocity. Done.”
Why it’s harmful: You’ve robbed them of the learning opportunity. They’ll come to you for every problem instead of building their own problem-solving muscles.
What to do instead: Guide them to their own solutions.
“What have you tried so far?” “What do you think might help?” “If you were coaching someone else with this challenge, what would you suggest?”
Mistake 6: Not Following Through on Your Commitments
What it looks like: You promise to set up pairing sessions, review PRs faster, clarify requirements—then you get busy and don’t do it.
Why it’s harmful: You lose all credibility. They conclude you don’t actually care, and they stop trying.
What to do instead: Treat commitments in performance coaching as sacred. If you commit to something in a coaching plan, put it in your calendar and do it.
Mistake 7: Confusing Underperformance with Misalignment
What it looks like: Someone is executing well but on the wrong priorities because you weren’t clear. You label this as underperformance.
Why it’s harmful: It punishes them for your failure. They lose trust in you.
What to do instead: Own your part.
“I realize I wasn’t clear about priorities, and you’ve been focused on X when Y was more urgent. That’s on me. Going forward, here’s how we’ll ensure alignment…”
Mistake 8: Coaching Someone Who Shouldn’t Be Coached
What it looks like: Someone has fundamental behavioral issues (dishonesty, severe interpersonal conflict, refusal to take feedback) and you keep “coaching” them for months while the team suffers.
Why it’s harmful: Some issues are not coachable within a team context. You’re wasting time and damaging team morale.
What to do instead: Recognize when coaching has reached its limit. If someone has had multiple clear conversations, a documented plan, and adequate support, but shows no improvement or willingness to change, it’s time to transition them out.
4. Real Scenarios
Scenario 1: The Overwhelmed Mid-Level Engineer
Context: You’re leading a team at Aperia Solutions. Minh, a mid-level engineer, has been struggling for the past month. He committed to migrating three microservices from Azure Functions to containers but has only completed one. His PRs are taking 2-3 iterations because of basic errors: missing error handling, incomplete logging, failing to follow the agreed-upon patterns. In standups, he seems stressed and withdrawn.
Bad Approach
You pull Minh aside after standup:
You: “Hey, you committed to three microservices and you’ve only done one. What’s going on? The team is depending on you to deliver. I need you to step it up.”
Minh: “I’m doing my best. There’s a lot going on.”
You: “I get it, but we all have a lot going on. Just focus and get it done.”
Why this is bad:
- You didn’t diagnose the root cause—you assumed he’s not trying hard enough
- You made it adversarial (“the team is depending on you”)
- You didn’t listen or ask questions
- You provided no support or path forward
- Minh leaves feeling worse and still doesn’t know how to improve
Good Approach
You schedule a 1:1 with Minh:
You: “I wanted to talk about the microservices migration. I’ve noticed you’ve completed one of the three services you committed to, and your last few PRs have needed multiple rounds of feedback on error handling and logging. I want to understand what’s happening from your perspective so we can figure out how to support you. What’s been challenging?”
Minh: “Honestly, I’m drowning. This is my first time working with Kubernetes, and every time I think I understand something, I run into another issue. I’ve been Googling and reading docs, but it’s slow. Also, my daughter has been sick, so I’ve been leaving early a few days a week. I didn’t want to make excuses, so I just kept trying to push through.”
You: “Thank you for being honest. That helps me understand what’s going on. Let’s break this down. On the Kubernetes side, have you worked with anyone on the team who could pair with you to accelerate the learning?”
Minh: “Not really. Everyone seems busy, and I didn’t want to interrupt.”
You: “Okay, so part of the issue is you’re learning Kubernetes on your own while trying to deliver production code. That’s really hard. Here’s what I think we should do. First, I’m going to have you pair with Tuan two hours this week and next—he’s our Kubernetes expert and he’s happy to help. Second, let’s adjust your commitment for this sprint. Instead of two more services, let’s commit to one, and let’s focus on getting it right with clean error handling and logging. You can use the pairing sessions to address your blockers. Does that feel doable?”
Minh: “Yeah, that would really help.”
You: “Good. On the personal side, I appreciate you showing up even when your daughter is sick. If you need flexibility, just communicate it. I’d rather know you’re leaving early and plan around it than have you stress silently. How is she doing?”
Minh: “She’s getting better. Thanks for understanding.”
You: “Of course. Let’s check in on Friday to see how the pairing with Tuan went and whether you feel more confident. And if you get stuck again, flag it in standup. Sound good?”
Minh: “Yes, thanks.”
Why this is good:
- You opened with curiosity, not judgment
- You listened and uncovered the real issues (skill gap, personal circumstances, reluctance to ask for help)
- You provided concrete support (pairing sessions)
- You adjusted expectations realistically (one service instead of two)
- You addressed the personal situation with empathy
- You set a near-term checkpoint to monitor progress
- Minh leaves with a clear plan and feels supported
Scenario 2: The Senior Engineer Who Isn’t Acting Senior
Context: You’re at CoverGo. Lan is a senior engineer who writes solid code but doesn’t demonstrate senior-level impact. She doesn’t participate in architecture discussions, rarely reviews others’ PRs, doesn’t mentor junior engineers, and only works on her assigned tasks. She’s a solid individual contributor but not providing the leadership expected at her level.
Bad Approach
In a 1:1:
You: “You’re a senior engineer, so I expect you to be more of a leader. You need to step up.”
Lan: “Okay, I’ll try.”
Why this is bad:
- “Step up” and “be a leader” are too vague
- You didn’t explain what senior-level impact looks like at CoverGo
- You didn’t ask why she’s not doing these things
- She leaves confused about what to do
Good Approach
In a 1:1:
You: “I want to talk about your role as a senior engineer and what that means for the team. You’re doing good work on your individual contributions—your code quality is solid and you deliver reliably. But I’m not seeing the broader impact I expect from someone at the senior level. Specifically, you’re not participating in architecture reviews, you’re not doing code reviews for others, and you’re not mentoring the junior engineers. Can you help me understand why?”
Lan: “I guess I didn’t realize that was expected. I thought my job was to deliver my features. Architecture discussions feel like they’re for the architects, and I don’t want to step on toes. I’ve never really mentored anyone before, so I’m not sure how.”
You: “Okay, that’s really helpful context. Let me clarify what senior engineer means at CoverGo. At this level, we expect you to influence technical direction, not just implement. That means actively participating in architecture reviews with your perspective—your experience is valuable, and we need your input. It also means owning code quality across the team by reviewing PRs, not just writing your own. And it means helping grow the next generation of engineers by mentoring.”
Lan: “That makes sense. I just didn’t know that was part of the role.”
You: “I should have been clearer earlier. Let’s build a plan. Over the next month, here’s what I’d like to see: You attend and actively contribute to at least two architecture reviews—doesn’t have to be long, just share your perspective on the trade-offs. You review at least three PRs per week from other engineers. And I’m going to pair you with Hieu, one of our mid-level engineers, for a monthly 1:1 where you can mentor him on testing patterns and code design. How does that sound?”
Lan: “That’s clear. I can do that. For the architecture reviews, can you give me an example of the kind of input you’re looking for?”
You: “Absolutely. In the last review on the payment service redesign, we were debating between event sourcing and a traditional CRUD approach. You’ve worked on both patterns in previous roles. I would have loved to hear your perspective on the trade-offs based on your experience. That’s the level of contribution I’m looking for—sharing what you know to help the team make better decisions.”
Lan: “Got it. That helps.”
You: “Great. Let’s check in in two weeks to see how the first couple of reviews and mentoring sessions go.”
Why this is good:
- You were specific about what senior-level impact looks like
- You diagnosed the root cause: lack of clarity, not lack of ability
- You owned your part (not setting clear expectations earlier)
- You created a concrete, measurable plan
- You gave her a clear example of what “good” looks like
- She leaves knowing exactly what to do
Scenario 3: The Technically Strong Engineer with Poor Collaboration Skills
Context: You’re at YOLA. Duc is an excellent architect—technically sharp, high output, innovative. But he’s creating team friction. He interrupts people in meetings, dismisses ideas without exploring them, and sends terse, sometimes condescending messages in Slack. Two engineers have come to you privately saying they dread working with him.
Bad Approach
In a 1:1:
You: “People are complaining that you’re hard to work with. You need to be nicer.”
Duc: “I’m just trying to maintain quality. If people are offended, that’s on them.”
Why this is bad:
- “Be nicer” is vague and judgmental
- You didn’t give specific examples
- You didn’t explain the impact
- Duc is defensive because it felt like a personal attack
Good Approach
In a 1:1:
You: “I want to talk about something that’s affecting the team. You’re one of the strongest technical minds we have, and your contributions are valuable. But I’m seeing patterns in how you interact with others that are creating problems. In last week’s architecture review, you interrupted Nga three times while she was presenting her design, and when she finished, you said ‘That won’t work’ without asking any questions about her reasoning. In Slack, when Hung asked for feedback on his API design, you responded ‘This is wrong’ without elaboration. I’ve had two engineers come to me privately saying they’re uncomfortable bringing ideas to you because they feel dismissed.”
Duc: “I’m just being efficient. We don’t have time for bad ideas.”
You: “I hear that you’re trying to maintain quality, and I value that. But here’s the impact: when you shut people down without exploring their reasoning, you miss potentially good ideas. Nga’s design actually had merit—if you’d asked questions instead of dismissing it, we would have had a better technical discussion. More importantly, you’re making people afraid to share ideas, which means we’re getting less diverse input and weaker solutions. And it’s affecting team morale. People are talented engineers, and they deserve to be treated with respect even when you disagree with them.”
Duc: “I didn’t realize it was that bad.”
You: “I appreciate you hearing this. Let’s talk about what changes I need to see. In meetings, I need you to let people finish their thoughts before jumping in. When you disagree with an approach, I need you to ask clarifying questions first—‘Can you walk me through your reasoning on X?’ or ‘What alternatives did you consider?’—before offering your perspective. In written communication, I need you to explain your reasoning, not just state conclusions. Can you commit to that?”
Duc: “Yeah, I can do that.”
You: “Good. I’m going to give you real-time feedback when I see these patterns. If I see you interrupt someone in a meeting, I’ll step in. If I see terse messages in Slack, I’ll follow up. This isn’t optional—it’s a core expectation of working on this team. I’m confident you can adjust, and I want to support you in doing so.”
Why this is good:
- You led with his strengths (he’s technically sharp) before addressing the issue
- You gave specific, behavioral examples
- You explained the impact on the team, not just “people’s feelings”
- You framed the feedback as about behavior (interrupting, dismissing) not character (you’re mean)
- You gave clear, actionable expectations
- You committed to ongoing feedback and accountability
5. Practice Exercises
Exercise 1: Root Cause Diagnosis
Read each scenario and identify the most likely root cause(s). Then outline how you would verify your hypothesis.
Scenario A: An engineer on your team has strong technical skills but consistently misses deadlines. They often discover requirements late in the sprint and have to rework features.
Scenario B: A senior engineer used to be a strong performer but over the past two months has become withdrawn. They’re completing their work but not engaging in discussions or helping others.
Scenario C: A junior engineer asks a lot of questions, which is normal, but the same questions repeatedly. They implement feedback in one PR but make the same mistakes in the next.
Practice: Write down:
- What root cause(s) you suspect
- What questions you would ask to verify
- What evidence you would look for
Exercise 2: Rewriting Vague Feedback
Take these vague feedback statements and rewrite them to be specific and actionable.
Vague: “You need to communicate better.”
Vague: “Your code quality isn’t where it should be.”
Vague: “You’re not showing enough ownership.”
Practice: Rewrite each with specific behaviors and measurable expectations.
Exercise 3: Role-Playing the Conversation
With a trusted peer or mentor, role-play a performance conversation. Have them play the underperformer using one of these personas:
Persona A: Defensive (“I’m doing my best. The requirements keep changing. It’s not my fault.”)
Persona B: Deflecting (“Everyone else is struggling too. Why am I the only one being called out?”)
Persona C: Checked out (“Okay, I’ll try harder.” But with no real engagement or follow-up questions.)
Practice: Navigate the conversation while staying curious, empathetic, and clear about expectations.
Exercise 4: Building a Coaching Plan
Choose a real or hypothetical performance gap on your team. Build a complete 30-day coaching plan that includes:
- Specific, measurable performance expectations
- Root causes you’ve identified
- Actions the engineer will take
- Support you will provide
- Milestones and checkpoints
- Success criteria
Practice: Write it out as if you were sending it to the engineer after a coaching conversation.
Exercise 5: Catching Yourself
Over the next week, pay attention to your own reactions to performance issues on your team.
Notice:
- When do you feel frustrated or judgmental?
- When do you avoid addressing something you should address?
- When do you jump to solutions instead of asking questions?
Practice: After each 1:1 or team interaction where performance was discussed, write a brief reflection:
- What did I do well?
- What would I do differently?
- Did I stay curious or did I make assumptions?
6. Key Takeaways
The Core Truths
- Most people want to succeed. Start with that assumption and approach performance conversations with curiosity, not judgment.
- Underperformance is usually a systems problem. Before concluding it’s the individual, examine role clarity, skills, environment, feedback loops, and motivation.
- Specificity is kindness. Vague feedback feels like judgment. Specific, behavioral feedback is actionable and respectful.
- Coaching is a partnership. You don’t dictate a solution; you build a plan together. People commit to plans they help create.
- Follow-through is everything. If you commit to support in a coaching plan, deliver it. Your credibility depends on it.
- Not everyone can be coached. Some issues (dishonesty, refusal to take feedback, severe behavioral problems) are not coachable. Recognize when it’s time to transition someone out.
The Practical Essentials
- Address performance gaps within 2-3 weeks of noticing a pattern. Don’t wait months.
- Use the Performance Coaching Cycle: Diagnose → Initial conversation → Ongoing support → Progress review
- Make feedback behavioral, not personal: “You interrupted three times” not “You’re rude.”
- Listen more than you talk in coaching conversations. Their perspective reveals root causes you might miss.
- Document the plan in writing. This protects both of you and ensures alignment.
- Set clear milestones (30, 60, 90 days) and assess progress formally.
The Mindset Shifts
From: “This person is underperforming. I need to fix them.”
To: “There’s a gap between current performance and expectations. Let’s diagnose it together and build a plan.”
From: “I need to tell them what to do.”
To: “I need to ask questions and guide them to their own solutions.”
From: “If I give negative feedback, I’ll demotivate them.”
To: “If I avoid hard conversations, I’m failing them and the team.”
When You’ve Done It Right
You’ll know you’re coaching effectively when:
- Engineers come to you with problems before they escalate because they trust you’ll help, not judge
- People who were underperforming become strong contributors and credit your coaching
- Your team sees you address performance issues fairly and consistently, which builds trust
- You catch yourself staying curious instead of jumping to conclusions
A Final Thought
Coaching underperformers is hard, often uncomfortable work. It requires empathy, clarity, accountability, and persistence. But it’s also one of the most impactful things you can do as a leader. When you help someone turn around their performance, you don’t just improve their career—you demonstrate that growth is possible, that you invest in your people, and that accountability and support can coexist.
The best leaders are not the ones who avoid hard conversations. They’re the ones who have them with honesty, respect, and a genuine desire to help people succeed.
Appendix: Quick Reference Checklist
Before the Conversation
- [ ] Have I gathered specific, factual evidence of the performance gap?
- [ ] Have I identified the likely root cause(s)?
- [ ] Have I examined my own contributions (clarity, support, environment)?
- [ ] Have I scheduled adequate time in a private setting?
During the Conversation
- [ ] Did I open with care and specificity?
- [ ] Did I present facts, not judgments?
- [ ] Did I ask open-ended questions and listen deeply?
- [ ] Did we collaborate on diagnosing the root cause?
- [ ] Did we co-create an improvement plan with clear expectations?
- [ ] Did we define what success looks like and when we’ll assess it?
After the Conversation
- [ ] Did I send a written summary of the plan?
- [ ] Have I put my commitments (pairing sessions, faster PR reviews, etc.) in my calendar?
- [ ] Have I scheduled regular checkpoints?
- [ ] Am I prepared to give ongoing, specific feedback?
At Progress Review
- [ ] Am I assessing against the specific criteria we agreed on?
- [ ] Am I recognizing progress, even if incomplete?
- [ ] Am I being honest about whether the gap has closed?
- [ ] If improvement is insufficient, am I clear about next steps?
Interview Practice: Coaching Underperformers to Improve
Q1: "How do you diagnose the root cause of underperformance before taking action?"
Why interviewers ask this Jumping to conclusions about underperformance is one of the most common mistakes leaders make. Interviewers want to see that you investigate before you judge — and that you understand performance as a complex, multi-factor problem.
Sample Answer
I treat underperformance as a symptom until I know the diagnosis. I start by separating the categories: is this a skills gap — they don't know how to do the work required? A motivation gap — they can do it but aren't engaged enough to? Or a clarity gap — they aren't clear about what's expected and how success is measured? Those three causes look similar from the outside but require very different responses. To diagnose, I look at patterns. "Is this happening across all their work, or only in specific areas?" That helps distinguish skill from situation. I also have a direct conversation: "I've noticed this pattern. Help me understand what's happening from your side." Most of the time, engineers will tell you the real reason if you make it safe to be honest. I've been surprised by how often underperformance has context I wasn't aware of — a personal situation, an unclear expectation, a feeling of being stuck that hasn't been surfaced. Skipping diagnosis and going straight to performance management often means solving the wrong problem entirely.
Q2: "How do you have a performance conversation without de-motivating the engineer further?"
Why interviewers ask this Performance conversations carry real risk of backfiring — if handled badly, they can deepen disengagement. Interviewers want to see whether you can deliver honest, expectation-setting feedback while maintaining the person's sense of worth and capability.
Sample Answer
The key is separating the behavior from the person. I talk about specific, observable things — "In the last three sprints, your tasks have consistently been completed late." Not: "You're unreliable." The first is a fact about performance. The second is a judgment about character. I also anchor the conversation to growth and outcome, not judgment. "I'm raising this because I think you're capable of more, and I want to understand what's getting in the way." That signal — that I see potential, not a problem — changes the emotional register of the conversation significantly. I also listen before I prescribe. If I lead with solutions, I've framed the person as incompetent. If I ask questions — "What do you think would help?" — I treat them as a capable adult who has insight into their own situation. The goal of the conversation shouldn't be for them to feel judged. It should be for them to leave with a clear understanding of the gap, why it matters, and a credible path to close it.
Q3: "What's your approach to building a coaching plan for an underperforming engineer?"
Why interviewers ask this Vague coaching is ineffective. Interviewers want to see whether you translate good intentions into structured, measurable support — and whether you know what a meaningful coaching plan contains.
Sample Answer
A coaching plan needs four elements: a clear, specific statement of what needs to change; observable milestones — not "improve communication" but "lead the next three design reviews and receive specific positive feedback from at least two stakeholders"; a support model — what resources, mentorship, or reduced scope will help them succeed; and a review cadence — weekly check-ins during active coaching, with explicit reflection on progress. I co-create the plan with the engineer rather than handing it to them. Their buy-in matters enormously — a plan they've helped shape is one they're more likely to commit to. I also set a realistic timeframe. Most genuine skill development takes at least twelve weeks to show consistent change. I'm also honest about the stakes when they need to be clear: "I want this to succeed. And I want to be transparent that if the pattern doesn't change within this timeframe, we'll need to have a different conversation." That's not a threat — it's respect for the person's ability to make an informed choice.
Q4: "How do you distinguish between an engineer who needs coaching and one who needs to be managed out?"
Why interviewers ask this This is a judgment question. Interviewers want to see whether you can make this difficult distinction clearly — not staying in coaching mode past the point of effectiveness, and not giving up on someone prematurely.
Sample Answer
The signal I look for first is willingness. An engineer who acknowledges the gap, engages with the coaching, and shows even modest improvement in effort and behavior — even if results lag — is someone I continue to invest in. What makes me reconsider investment is the combination of persistent pattern, lack of self-awareness, and absence of effort to change. If someone consistently fails to follow through on the commitments they made in the coaching plan itself — the most basic form of accountability — that's a different situation. I also think about fit: "Is this the right role for this person?" Sometimes underperformance is a signal that someone is in the wrong job, not that they're a weak engineer. A lateral move or role change can be the best outcome for everyone. The decision to formally manage someone toward an exit is one I make only after genuine investment in coaching — not as a first response, and not as a final resort either. The team's wellbeing matters too. Tolerating persistent underperformance that's affecting others is a leadership failure, even when it comes from a compassionate place.
Q5: "How do you give feedback to an engineer who is defensive or doesn't accept that there is a performance problem?"
Why interviewers ask this Defensiveness breaks down the coaching conversation. Interviewers want to see whether you persist with clarity, manage your own frustration, and know how to re-anchor the conversation when it's going sideways.
Sample Answer
I don't argue about whether there's a problem. That conversation very rarely goes anywhere productive. Instead, I stay anchored to observable facts. "Here's what I observed. Here's the impact." If someone says "I don't agree with your assessment", I respond: "I hear that. I want to understand your perspective as well." I listen to their account genuinely — sometimes there's context I've missed. But if the disagreement persists, I'm clear: "Whether or not we agree on the interpretation, these are the observable patterns, and this is what I need to see change." The feedback conversation isn't a negotiation about whether something happened. I document the conversation and what I communicated. If the pattern continues and the person claims they weren't told, I have a record. I also reflect on whether my communication style has contributed to the defensiveness. Sometimes the way I've framed feedback in the past has been too evaluative rather than descriptive — and switching to a more behavior-impact style reduces the defensive response significantly.
Q6: "How do you handle underperformance in a high-potential engineer who has the skills but seems disengaged?"
Why interviewers ask this Disengagement and underperformance in talented people often signals a different kind of problem — growth stagnation, lack of challenge, or poor environment fit. Interviewers want to see whether you can diagnose this nuance.
Sample Answer
When I see a capable engineer underperforming, my first hypothesis is environment rather than capability. I have a honest conversation: "I'm noticing a change in your engagement over the last few months. I want to understand what's going on from your perspective." The responses I hear most often are: the work isn't challenging enough, they feel like their ideas aren't heard, they're not seeing a clear growth path, or something outside work is affecting them. Each of those requires a different response. If it's about challenge — I look for stretch assignments, ownership of something higher-stakes, involvement in strategic decisions. If it's about visibility — I look for ways to give their work more organizational impact. If it's about growth — I ask the honest question: "What would the next version of your career look like? What would you need to get there?" Talented engineers who feel invested in rarely underperform for long. The ones who quietly disengage are often the ones leadership didn't notice until they gave notice.
Q7: "What does success look like in a coaching engagement for you, beyond just improved performance metrics?"
Why interviewers ask this This question goes beyond the tactical and into your philosophy of leadership. Interviewers want to understand what you're actually trying to accomplish — whether you see people as resources to optimize or as individuals to develop.
Sample Answer
Success for me is an engineer who understands their own patterns clearly enough to self-correct — not just one who is performing well right now while I'm watching closely. The most durable outcome of good coaching is the person's improved self-awareness: they can recognize when they're falling into old patterns and adjust earlier, they ask for help differently, they communicate about constraints more proactively. That's visible in behavioral changes that extend beyond the specific issues we worked on. I also look for whether our working relationship has changed. A successful coaching engagement usually results in more candid, direct communication — the engineer trusts that I'll give them honest feedback, and they're more likely to surface problems early. That's better for both of us and for the team. Finally, I think success includes what I learn as a leader. Every coaching relationship shows me something about how I was communicating expectations, how I was structuring roles, or how I was designing work. If someone underperformed under my leadership, my first question is always: "What in the environment might have contributed to this?"