How I Handle Underperformance on My Team
Every manager eventually has a conversation they would rather postpone: someone on the team is not delivering what the role requires. The instinct is to wait another sprint and hope the problem resolves itself. It rarely does, and the waiting quietly becomes a management decision of its own.
In this guide I explain the process I follow from the first signal to the final decision: diagnosing the cause, auditing my own contribution, setting measurable expectations, matching support to the problem, documenting progress, and knowing when improvement is not happening.
Underperformance is a symptom, not a verdict
Missed dates, heavy rework, and quiet disengagement are outputs. The cause sits upstream, and it is rarely the character flaw the word underperformance implies. A strong performer who declines suddenly is telling me that something changed. Someone who has never hit the bar is telling me something about hiring, onboarding, or expectations.
The second reframe is that this is a process, not a meeting. Feedback is one conversation inside it. Managing underperformance starts before that conversation and ends only when the person is meeting the bar or has moved on. Treating it as a single hard talk is how managers end up improvising at the worst possible moment.
Four causes that look identical from the outside
From a distance, all underperformance looks like lower output. Up close, it usually falls into one of four buckets, and each one needs a completely different response. Getting the bucket wrong wastes time and trust at the same time.
Three of the four causes start with me. That does not mean every case is my fault, but it does mean I have not earned the accountability diagnosis until I have ruled out the other three. Being wrong about motivation is the most expensive mistake here, because it damages trust in a way an honest skills conversation never does.
I diagnose from evidence, not from my desk
I treat diagnosis the way I treat an incident: gather evidence, form a hypothesis, change one thing, and watch what happens. I do not skip to the fix, and I do not diagnose from a feeling I have had for three weeks.
In that conversation I ask open questions and listen for the shape of the answer. What do you understand is expected of you on this project? What is getting in your way right now? Which parts of this work do you feel least confident about? If I were sitting in your seat, what would you change about how I run this?
Answers that contradict my expectations point to clarity. Blockers I can verify point to support. Hesitation around specific technical areas points to a skills gap. Clarity, support, capability, and vague answers about why the work is not happening point toward accountability.
A strong performer who drops suddenly deserves a different first question. Instead of asking what is wrong with their delivery, I ask what changed, because the answer is often a reorg, a project, or something I did without noticing.
Say the hard sentence without softening it into nothing
Once I have a working diagnosis, I say the sentence out loud: “Right now your performance is below the level this role requires. Here is specifically what that means, and here is what the bar looks like.” I do not bury it between two compliments or read it like a verdict from a tribunal.
Then I turn it into a shared diagnosis rather than an announcement. I describe what I observed, ask for their perspective, and name the likely cause together. If they correct me with facts I did not have, I update my view in the room. Agreement on the cause is what makes the plan theirs instead of something imposed on them.
The setting stays private, and it gets real time. Difficult news delivered in the last five minutes of a 1:1 is not a conversation. It is an ambush with a calendar invite, and people remember the ambush long after they forget the wording.
An expectation I cannot measure is not an expectation
Vague goals are the most common reason improvement efforts fail, because neither of us can tell whether we succeeded. “Be more proactive” and “take more ownership” sound like standards, but they describe a feeling rather than a behavior I can observe.
I translate each concern into an outcome, a measure, and a date. Then I ask the person to restate it in their own words. If they cannot, the expectation does not exist yet, no matter how clearly I thought I said it.
I keep the list to three to five items. A list of fifteen hides what actually matters and gives both of us an excuse to argue about the least important one. Each item gets a measure, a checkpoint date, and one line for the support I will provide, because that last line is what turns a demand into a plan.
Support has to match the cause, or it is just pressure
An expectation without support is a countdown. The help I offer has to fit the diagnosis, otherwise I am working hard on the wrong problem and calling it effort.
Whatever the cause, I make three commitments of my own. I hold a weekly 1:1 focused on this plan. I give feedback within days of the work instead of saving it for a review cycle. I do what I said I would do on the date I said I would do it. If I miss my own commitments, I say so, because the process loses its credibility otherwise.
I also stop rescuing. Carrying the work hides whether improvement is real, and it teaches the team that the standard bends whenever someone falls behind. Support is scaffolding, not a permanent structure.
The record exists to keep me fair, not to build a case
Documentation has a bad reputation because people associate it with building a file against someone. I see it differently. It keeps my memory honest, gives the engineer a record they can contest, and makes sure nothing in the process arrives as a surprise.
I tell the person I am documenting, and I share the substance at every check-in. A performance process that feels secret is a betrayal, and teams notice one long before the file appears.
I write facts, not character judgments. “The deployment on 14 October went out without rollback steps” is useful. “They were careless” is not. After every significant conversation I send a short recap of what we agreed, what I owe, and what they own next, which gives them a chance to correct me.
I involve HR early, not as a last step. Once a pattern is clear and before anything formal, I bring in the people who know company policy and local employment rules. The rule I hold myself to is simple: the engineer should never read something in the file that they have not already heard from me directly.
Hope is not a trend line
This is the part most managers defer, and I have been guilty of it. The plan has an end date, and I evaluate it against the criteria I set while I was calm rather than the hope I feel three months later.
Direction matters more than level. An engineer who is behind but closing the gap steadily is a different case from one on a flat line. I give real room to the first and I refuse to pretend the second is the first.
Before I decide anything, I answer three questions honestly. Did they genuinely understand what was expected? Did they have what they needed to succeed? Did I give it enough time? If the answer to all three is yes and the evidence still shows no meaningful progress, the process has done its job by telling me the truth.
At that point the conversation moves from development to transition. That might mean a role that fits better, a short extension with real evidence and a defined end date, a formal plan with HR, or a managed exit. None of it should be a surprise, because every step up to here was written down and shared.
The rest of the team is watching how I run this
Persistent underperformance is never private for long. Teammates absorb the unfinished work, the extra reviews, the on-call shifts, and the rework. The strongest engineers notice who is carrying the load, and they are usually the first to leave when nothing changes.
I do not discuss the details with the team. I do address the effect: rebalance the work, name the priorities, and acknowledge that a gap exists without turning it into gossip. The message I want people to receive is that standards are real and people are treated well while they are held to them.
Letting a gap drift sends the opposite message. It tells high performers that the standard is negotiable and that their extra effort is subsidizing someone else’s shortfall. Both messages outlast the individual case.
Common questions about handling underperformance
Q1How long should I give someone to improve?
It depends on the cause, the seniority, and the size of the gap. I look for direction within two to three weeks and a real result over roughly 60 to 90 days of structured effort. The number matters less than the fact that it is stated up front and never left open-ended.
Q2What if a strong performer suddenly drops?
Treat it as a signal that something changed, not as a performance problem. Start with a private, caring conversation and look for causes outside the four buckets, such as health, family, burnout, or a change in team structure.
Q3Is this the same as a performance improvement plan?
No. A formal plan is one possible stage in this process, and I only reach it when earlier steps have not worked. Most cases resolve before that, because diagnosing the cause and fixing it is usually enough.
Q4How is this different from giving difficult feedback?
Feedback is one tool inside the process. The rest of the work is diagnosis, expectations, support, documentation, and the decision at the end. My guide to giving difficult feedback without losing trust covers the conversation itself.
Q5Should I tell the rest of the team?
Not the details, because that is the engineer’s private matter. I do address the effect on workload and priorities so the team is not left silently covering a gap with no explanation.
Q6What if I inherited the problem from another manager?
Start fresh. Reset expectations in writing, run your own diagnosis, and begin the clock from your first documented conversation. Earlier history is context, not a substitute for your own evidence.
Q7How do I keep the process from feeling personal?
Talk about work and impact, never about character. Keep every conversation private, apply the same process to everyone, and say clearly that the door is open to improvement. People accept hard standards far more readily than they accept an unexplained judgment.
The process is the respect. Diagnose before you decide, put the bar in writing, support the cause you actually found, and let the evidence end the process.
When it works, someone who could improve does, and they know exactly how. When it does not, the decision is clear, fair, and no surprise to anyone in the room.