How would you handle an unresponsive teammate?

Scenario

You're on a project with a fixed deadline. A teammate who owns a critical task has stopped responding—they skip standups, don't answer messages, and show no visible progress. The rest of the team is stuck.

Questions

1. What would you do in the first 24–48 hours to get the project moving again?
2. How would you balance empathy (they might be dealing with personal issues) against accountability and delivery?
3. If the situation doesn't improve, when, how, and to whom would you escalate?
4. How would you communicate status and risks to your manager and stakeholders?
5. After the deadline, what would you do to prevent this from happening again (process or team changes)?

Overview: This question assesses interpersonal leadership and project-management skills—communication, accountability, escalation judgment, stakeholder risk communication, and empathy—in a software engineering, behavioral, and leadership context.

Solution

What a strong answer should demonstrate

• Ownership and bias for action: You move quickly to unblock the team instead of waiting indefinitely.
• Empathy plus professionalism: You assume good intent while still managing delivery risk.
• Communicating clearly: You keep stakeholders informed with facts, not blame.
• Good escalation judgment: Escalate early enough to protect the deadline, but not as the first step.
• Process improvement: You reduce single points of failure going forward.

A solid step-by-step approach (with reasoning)

1) Confirm the problem using multiple channels (same day)

Goal: Tell apart “busy,” “blocked,” and “truly unavailable.”

• Review existing signals: commit history, ticket updates, Slack/Teams status, calendar.
• Send a short, specific message:
  • What you need (status, ETA, blocker)
  • When you need it (e.g., “by EOD”)
  • Offer help (“Can I jump on a 10-min call?”)
• If there's no response, try a second channel (Slack + email; if your culture allows, a quick call). Pitfall to avoid: sending vague “ping” messages that don't make urgency clear.

2) Reduce project risk immediately (same day)

Goal: Keep delivery moving while the underlying cause is still unclear.

• Figure out what is blocked and put together a plan B:
  • Can you re-scope to ship an MVP?
  • Can you parallelize by breaking the task into smaller pieces?
  • Can someone else begin integration, tests, or scaffolding?
• If necessary, start a temporary re-assignment:
  • Ask another teammate (or yourself) to take over the most critical path.
  • Request access, docs, and context (design doc, PRs, partial code) to reduce ramp-up time. Key framing: “I’m doing this to protect the deadline, not to punish anyone.”

3) Have a direct, private conversation (within 24–48 hours)

If you reach them:

• Be respectful and stick to facts: describe the impact (blocked tasks, timeline risk).
• Ask open-endedly: “Is something blocking you? Anything I can do?”
• Agree on concrete next steps:
  • A small deliverable within 24 hours (e.g., design outline, partial PR)
  • A clear ETA
  • Update cadence (e.g., daily check-in until back on track) If they mention personal issues:
• Don’t probe for details; focus on what support is possible.
• Suggest involving the manager for workload adjustment or time off.

4) Escalate appropriately (early, with options)

When to escalate:

• The work is on the critical path and the deadline is only days away.
• You still can't get a response after repeated attempts.
• You suspect a health/emergency situation, or the person is completely unavailable. How to escalate (to manager/lead):
• Use a neutral, delivery-focused summary:
  • Facts: last contact, what's blocked
  • Risk: which deadline is affected
  • Actions taken: attempts to contact, mitigation started
  • Ask: reassign ownership, adjust scope, or formal check-in Pitfall: escalating with blame (“they’re lazy”). Keep it about impact and risk.

5) Communicate to stakeholders with clarity

• Provide a brief status update:
  • Current state
  • Risk level
  • Mitigation plan and updated ETA
• Avoid naming or attributing individual performance issues in broad channels.

6) After-action: prevent recurrence

Focus on systemic fixes:

• Cut down single points of failure:
  • Shared ownership, pairing on critical components
  • Better documentation, design reviews
• Increase visibility:
  • Smaller tasks, frequent PRs, clear definitions of done
  • Early risk flags in standup (“blocked > 1 day triggers help/escalation”)
• Set team norms:
  • Response expectations during work hours
  • Backup owners for critical tasks

STAR-style example outline (easy to deliver in interview)

• S: Critical feature due Friday; a teammate owns the API changes and has been unresponsive since Tuesday.
• T: Ship on time; keep the team from being blocked.
• A: Tried multiple channels; offered help; split tasks; took over integration; informed the manager with facts; re-scoped nonessential parts.
• R: Delivered the MVP on time; later rebalanced workload and added a “backup owner + daily PR” practice, reducing future risk.

Common edge cases to mention

• If there’s a possible emergency: involve manager/HR per policy instead of repeatedly contacting the person.
• If you’re not the lead: still take initiative to mitigate, but align escalation with your manager/tech lead.
• If it’s a recurring pattern: document the impact and work with the manager on the performance process (not public shaming).