How to Handle Remote Employee Underperformance: Conversation Guide for New Managers

Track deliverables, commit history, and communication patterns first—then use a documented conversation framework to address underperformance objectively with the employee. Managing remote teams makes addressing underperformance both more critical and complex because you lack visual cues and must gather objective data instead of relying on gut feelings. This guide provides new managers with a structured approach including conversation scripts, documentation frameworks, and tips specifically adapted for distributed work environments.

Recognizing Underperformance in Remote Settings

The first step in addressing underperformance is accurate identification. Remote work can mask problems just as easily as it can create them. Before initiating any conversation, gather objective data rather than relying on gut feelings.

Track deliverables against agreed-upon expectations. Review commit history, task completion rates, pull request metrics, or whatever KPI framework your team uses. Look for patterns over weeks, not single data points. A developer who misses one deadline may be dealing with a complex problem. Consistent missed deadlines across sprints indicate a systemic issue.

Communication patterns also reveal performance trends. Has response time increased? Are standup updates becoming vague or absent? Is the employee withdrawing from team channels? These behavioral shifts often precede or accompany declining output quality.

Document everything. Create a simple tracking system in your project management tool:

## Performance Notes - [Employee Name]

### Week of [Date]
- Deliverables: [Completed/Incomplete]
- Communication: [Notes on responsiveness]
- Code quality: [Review feedback summary]
- Blockers: [Any identified issues]

### Patterns Observed
- [Specific observation 1]
- [Specific observation 2]

This documentation serves two purposes: it provides factual basis for conversations, and it protects you from appearing biased or unfair if the situation escalates.

Preparing for the Conversation

Once you’ve identified a pattern of underperformance, preparation becomes essential. Never initiate a performance conversation spontaneously. Both you and the employee need time to prepare.

Schedule a dedicated meeting. Do not combine this with other agenda items. Block 45-60 minutes and ensure it’s during the employee’s core working hours. For distributed teams, this means accommodating time zone differences.

Prepare your talking points. Structure the conversation around three elements: specific observations, impact on the team and projects, and collaborative problem-solving. Avoid generalizations like “your work has been declining.” Instead, use concrete examples with dates and outcomes.

Notify the employee in advance. A message like this works well:

“Hi [Name], I’ve noticed some patterns in your recent work that I’d like to discuss. I’d like to schedule a 1:1 to talk through some support options. Could we meet [suggest two times]?”

This gives the employee warning and opportunity to prepare their perspective.

The Conversation Framework

When it’s time for the actual conversation, follow a structured approach that balances directness with empathy.

Opening (5 minutes)

Begin by setting a collaborative tone. This is not a disciplinary action—it’s a problem-solving session.

Sample opening:

“Thanks for meeting with me. The purpose of this conversation is to discuss some patterns I’ve observed and to work together on solutions. My goal is to support you in succeeding in this role.”

Observations (10 minutes)

Present your documented observations factually. Stick to what you’ve seen rather than assumptions.

Sample observation statement:

“Over the past three weeks, I’ve noticed the following: the API endpoint you were assigned for Sprint 15 was delivered two days late, which blocked the frontend integration work. In our team code reviews, three of your last five PRs required major revisions before merging. In our async standups, your updates have been brief for the past two weeks without details on what you’re working on.”

Pause after presenting observations. Allow the employee to respond. They may have explanations—perhaps they were dealing with personal issues, unclear requirements, or technical blockers they didn’t communicate.

Impact Discussion (5 minutes)

Explain how the underperformance affects the team and projects.

Sample impact statement:

“When your deliverables are delayed, it affects the entire deployment schedule. The team has had to step in to cover integration work, which increases their workload. Additionally, unclear standup updates make it harder for the team to coordinate dependencies.”

Collaborative Problem-Solving (20 minutes)

Shift from observation to solution-finding. Ask open questions:

• “What do you think is contributing to these challenges?”
• “What support would help you get back on track?”
• “Are there blockers you’re facing that we haven’t discussed?”
• “What would success look like for you in the next 30 days?”

Listen actively. The employee may reveal issues you weren’t aware of—personal challenges, unclear expectations, technical debt slowing them down, or problems with team collaboration.

Action Plan (10 minutes)

Conclude with specific, measurable next steps. Document these together:

## Performance Improvement Plan - [Date]

### Identified Challenges
- [Challenge 1: agreed upon by both parties]
- [Challenge 2]

### Support Agreed
- [Support item 1: e.g., weekly check-ins]
- [Support item 2: e.g., pairing sessions]
- [Support item 3: e.g., clearer story point estimation]

### Success Criteria
- [Measurable outcome 1: e.g., deliver 2 stories per sprint]
- [Measurable outcome 2: e.g., PRs merged within 48 hours]

### Review Date
- [Date: typically 2-4 weeks out]

Closing

End with encouragement while being clear about consequences.

“I believe you can turn this around, and I’m committed to supporting you. We’ll revisit this in [timeframe] to assess progress. Between now and then, my door is open if you need to discuss anything.”

Following Up

The conversation only matters if you follow through. Schedule the follow-up meeting before ending the current meeting. Hold yourself accountable to providing the support you promised.

During the improvement period, increase your check-in frequency. Brief weekly 15-minute syncs help you stay informed without micromanaging. Note any improvements or continued struggles objectively.

At the follow-up meeting, be honest about progress. If improvements are evident, acknowledge them and adjust the plan accordingly. If no progress has been made, escalate to your HR partner or management chain according to company policy.

Common Mistakes to Avoid

New managers often make predictable errors in these conversations. Avoid these pitfalls:

Being vague: “Your work hasn’t been good enough” provides nothing actionable. Always tie observations to specific deliverables, dates, and impacts.

Making it personal: Focus on behaviors and outcomes, not character. “This code had bugs” differs from “you are careless.”

Bypassing the employee: Never discuss performance issues with other team members or vent to colleagues. Confidentiality matters.

Ignoring context: An employee’s cat may have died, or they may be going through a divorce. Context doesn’t excuse persistent underperformance, but understanding it prevents premature escalation.

Moving too slowly: Addressing problems early prevents them from compounding. A two-week delay becomes a two-month problem.

Adapting for Async Communication

Some remote teams operate with minimal synchronous contact. If your team is highly asynchronous, adapt the framework accordingly.

Send a thoughtful async message first:

“Hey, I’d like to discuss some observations about recent work. Could we schedule a video call for [time]? I’ll send you a brief outline beforehand so you can prepare.”

Provide time for the employee to compose their thoughts. Async communication favors considered responses over spontaneous ones, which can actually benefit performance discussions.

Shell Automation for Remote Team Workflows

Small shell scripts eliminate repetitive tasks that compound into significant time loss across distributed teams.

#!/usr/bin/env bash
# daily_standup.sh — Aggregate git activity for standup notes

REPOS=(~/code/project-a ~/code/project-b ~/code/project-c)
SINCE="yesterday"
AUTHOR=$(git config user.email)

echo "=== Standup Notes: $(date +%A\ %b\ %d) ==="
echo ""

for repo in "${REPOS[@]}"; do
    repo_name=$(basename "$repo")
    if [ -d "$repo/.git" ]; then
        activity=$(git -C "$repo" log             --since="$SINCE"             --author="$AUTHOR"             --oneline             --no-walk 2>/dev/null)
        if [ -n "$activity" ]; then
            echo "### $repo_name"
            echo "$activity"
            echo ""
        fi
    fi
done

# Output to clipboard (macOS):
# bash daily_standup.sh | pbcopy
# Output to clipboard (Linux with xclip):
# bash daily_standup.sh | xclip -selection clipboard

Add this script to a morning cron job or run it manually before standups. It builds a habit of commit-based status updates rather than vague progress descriptions.

Time Zone Coordination for Distributed Teams

Managing meetings across time zones without dedicated tooling leads to scheduling errors and missed calls.

from datetime import datetime
import pytz

TEAM_TIMEZONES = {
    "Alice (NYC)": "America/New_York",
    "Bob (London)": "Europe/London",
    "Carlos (Singapore)": "Asia/Singapore",
    "Dana (SF)": "America/Los_Angeles",
}

def find_overlap_windows(date_str, start_hour=8, end_hour=18):
    # Find times where all team members are within working hours
    utc = pytz.UTC
    good_slots = []

    # Check each UTC hour
    for utc_hour in range(24):
        utc_time = datetime.strptime(f"{date_str} {utc_hour:02d}:00", "%Y-%m-%d %H:%M")
        utc_time = utc.localize(utc_time)

        all_available = True
        slot_info = {}
        for person, tz_name in TEAM_TIMEZONES.items():
            tz = pytz.timezone(tz_name)
            local_time = utc_time.astimezone(tz)
            local_hour = local_time.hour
            if not (start_hour <= local_hour < end_hour):
                all_available = False
                break
            slot_info[person] = local_time.strftime("%I:%M %p %Z")

        if all_available:
            good_slots.append(slot_info)

    return good_slots

slots = find_overlap_windows("2026-03-25")
for slot in slots:
    print("--- Available slot ---")
    for person, time in slot.items():
        print(f"  {person}: {time}")

For most globally distributed teams, there are 0-2 overlap hours. Use async-first communication for everything that doesn’t require real-time discussion.

Real-World Performance Conversation Examples

Understanding what works in practice helps you adapt the framework to your specific situation:

Example 1: Developer Missing Deadlines

Opening:
"Thanks for meeting. I want to discuss some patterns I've noticed
and work together on solutions."

Observation:
"In the last four sprints, you've missed your story point commitment
three times. Sprint 12 you committed to 20 points, delivered 12.
Sprint 13: committed 18, delivered 14. Sprint 14: committed 20,
delivered 15. This pattern is consistent."

Impact:
"When stories aren't completed on schedule, downstream teams
have to adjust. The frontend team had to pull in other work because
API endpoints weren't ready. This cascades through the entire
product roadmap."

Problem-solving:
"What's contributing to these misses? Are story points miscalibrated?
Are you facing blockers? Time management issues?"

Possible solutions:
- Better estimation process
- Breaking stories into smaller chunks
- Weekly planning check-ins
- Pairing with more senior engineer

Example 2: Communication Breakdown

Observation:
"Over the past two weeks, your standup updates have become very brief.
Monday: 'working on feature X.' Tuesday: 'same.' Wednesday: no update.
Thursday: 'debugging.' Friday: same. This vagueness makes it hard
for the team to coordinate."

Impact:
"When the team doesn't know what you're working on, we can't identify
blockers early. On Thursday, the QA team asked if feature X was
ready to test. Because we didn't know your status, they wasted 2 hours
preparing test cases before realizing you were blocked."

Problem-solving:
"What would help you provide better updates? Do you understand what
information we need? Would a template help?"

Success criteria:
- Standup updates describe: what you're working on, progress toward completion, any blockers
- Updates posted by 9 AM daily
- Reviews in one week

Example 3: Code Quality Issues

Observation:
"I've been reviewing your PRs more closely. In the last 10 PRs:
- 7 required revision for quality issues (missing tests, unclear logic)
- 3 were merged with issues that caused follow-up bugs
- Average review cycle took 3 days due to revisions

For comparison, your peer Sarah: 10 PRs, 1 required revision,
no follow-up bugs, 1-day review cycle."

Impact:
"Code quality issues create technical debt. Sarah's code requires
less review work, which means other developers can unblock faster.
Your code creates more maintenance burden down the line."

Problem-solving:
"Where's the gap happening? Are you rushing? Unclear on requirements?
Missing context about our codebase? Need different tools or processes?"

Documenting for Protection

Managers sometimes worry that honest performance conversations create legal exposure. Actually, the opposite is true. Documented, evidence-based conversations protect you:

What helps legally:

• Specific dates and metrics (Sprint 15 deadline, 3 of 5 PRs revisions)
• Tied to job requirements (your job description expects daily standup participation)
• Consistent with team expectations (everyone participates in standup)
• Showing support offered (weekly check-ins, pairing sessions proposed)

What hurts legally:

• Vague complaints (your work isn’t good enough)
• Subjective judgments (you’re lazy or not engaged)
• Inconsistent enforcement (other people miss standups without comment)
• No paper trail (he told me his work was poor, but I didn’t document it)

Date your documentation and keep copies in your performance management system. This isn’t about building a case to fire someone—it’s about creating clarity for everyone.

When Coaching Doesn’t Work

Sometimes employees don’t improve despite clear feedback and support. When this happens, escalate:

1. Two-week mark: If no improvement shows, schedule a second conversation
2. Four-week mark: If still no improvement, involve your HR partner or manager
3. Document everything: Keep notes of all conversations, all support offered, all improvement attempts
4. Determine next steps: Performance improvement plan, role change, or separation

This progression shows the employee you’re genuinely trying to help them succeed, while also protecting your team and company.

Performance Improvement Plans (PIPs) Done Right

If you move to a formal performance improvement plan, structure it carefully:

# Performance Improvement Plan - [Employee Name]
# Period: [Start Date] to [End Date] (typically 30-90 days)

## Performance Issues
1. [Specific issue with metrics]
2. [Specific issue with metrics]

## Required Improvements
1. [Measurable outcome] by [date]
2. [Measurable outcome] by [date]

## Support Provided
- Weekly 1:1 check-ins (30 min, Tuesdays 2 PM)
- Pairing sessions with [senior engineer] (2x weekly)
- Training on [specific skill] via [Pluralsight/etc]
- Clear documentation of expectations

## Consequences
If improvements are not demonstrated by [end date]:
- [Next step: role change, demotion, termination]

## Success Definition
- Measurable: [specific metrics]
- Achievable: with support offered
- Relevant: directly tied to job requirements
- Time-bound: specific end date

A good PIP shows the employee exactly what success looks like and gives them reasonable time and resources to achieve it.

Related Articles

• conversation-prompts.yaml - Example prompt rotation system
• Zulip vs Slack: A Deep Dive into Threaded Conversation
• How to Handle Client Revision Rounds in Remote Design Agency
• How to Handle Confidential Client Data on Remote Team
• How to Handle Emergency Client Communication for Remote

Built by theluckystrike — More at zovo.one