How to Handle Underperforming Employees C...

Nobody becomes a manager because they love difficult conversations. But ignoring underperformance is one of the fastest ways to lose your best people — they see the problem, they know you see it, and your silence tells them you don't care enough to act.

Here's how to handle it without being a jerk or a pushover.

First: Figure Out What's Actually Wrong

Before you schedule a meeting, take a step back and diagnose the situation. Underperformance usually falls into one of three buckets:

Skill gap. The person wants to do well but doesn't have the technical chops or experience. This is the easiest to fix — training, pairing, mentorship.

Motivation problem. They have the skills but aren't applying them. Maybe the work is boring, maybe they feel overlooked, maybe they're burned out. This requires a different conversation entirely.

Personal circumstances. Health issues, family problems, financial stress. You might not know about these, and the employee isn't obligated to share details. But you should at least open the door.

The fix for a skill gap is completely different from the fix for a motivation issue. If you treat every underperformance case the same way — throw a PIP at it and hope for the best — you'll lose people who could have been saved with the right support.

Having the First Conversation

The initial conversation matters more than anything that follows. Get it wrong and you'll either create an adversary or a person who shuts down completely.

Do it privately. Never in a group setting, never on a public Slack channel, never casually in passing.

Be specific. "Your performance has been slipping" is useless. "You've missed the last three sprint deadlines, and two of those caused downstream delays for the QA team" gives the person something concrete to respond to.

Don't ambush. Give them a heads-up that you want to discuss their recent work. "Hey, I'd like to chat about how the last few weeks have gone — can we find 30 minutes tomorrow?" That's enough.

Listen more than you talk. You might learn something that changes your entire approach. Maybe they've been pulled onto three other projects. Maybe the requirements keep changing. Maybe they're dealing with something outside work.

Building a PIP That Actually Works

Performance Improvement Plans have a bad reputation because most of them are just documentation for a firing that's already been decided. That's a waste of everyone's time.

A PIP that genuinely works has three things:

Clear, measurable goals. Not "improve code quality" — instead, "reduce PR review rejections to under 20% over the next six weeks." The person needs to know exactly what success looks like.
Resources and support. If you're asking someone to improve, give them the tools to do it. That might mean reducing their workload temporarily, assigning a mentor, or providing access to training. A PIP without support is just a countdown clock.
Regular check-ins. Weekly, at minimum. These aren't interrogations — they're quick syncs to see what's working, what's not, and whether the goals need adjusting. Waiting until the end of a 90-day PIP to check progress defeats the purpose.

Document Everything

This isn't about building a legal case (though it helps with that too). Documentation protects both you and the employee.

Write down the specific issues you've observed, dates, and any impact on the team. Record the conversations you've had and what was agreed on. Keep copies of the PIP and check-in notes. If you're using a tool like Notion, Confluence, or even a shared Google Doc, keep it updated.

Good documentation also forces you to be honest with yourself. If you can't write down a clear, specific performance concern, maybe the problem isn't as concrete as you thought.

Knowing When to Let Go

Sometimes a PIP works. The person gets back on track, and you both move on. But sometimes it doesn't, and you need to make the call.

If someone has had a fair process — clear expectations, real support, enough time — and they're still not meeting the bar, it's time. Dragging it out doesn't help them, and it actively hurts the rest of your team.

The conversation itself should be direct and respectful. Don't sugarcoat it, don't over-explain, and don't make it about them as a person. It's about the role and the work.

In Web3 and DAOs, It's Different

If you're managing contributors in a DAO or a decentralized team, the dynamics change significantly. There's often no formal employment relationship. People can leave whenever they want — and they do. You usually can't "fire" someone in the traditional sense; you can reduce their compensation, remove their access, or stop assigning them work.

This actually makes the early conversation even more important. In a DAO, an underperforming contributor might not even realize they're falling short because feedback loops tend to be weak. Governance token holders might grumble in Discord, but nobody has a direct conversation.

If you're a project lead or workstream owner, take ownership of those conversations even if you don't have a formal "manager" title. The health of the project depends on it.

Browse Web3 management roles if you're ready to take on leadership in this space.