Short answer
Stop calling it lazy and name the gap: one specific, recent, observable example, the expectation it missed, and a question. Most "lazy" engineers turn out to be blocked, under-specified, bored or quietly checked out, and each of those has a different fix. Set a short written expectation with a date, check it weekly, and let the record decide whether this becomes a performance conversation.
Which habit is behind this for you? The free 3-minute assessment names it and links the playbooks that fix it. Take the assessment →
You can see it from across the room. One engineer picks up the small tickets and leaves the hard ones. Their standup update is the same three days running. Pull requests arrive late and thin. Nobody has said anything yet, but the two strongest people on the team have started quietly absorbing the work, and one of them has started looking at you to see whether you have noticed.
You have. The question is what to do that does not make it worse. Complain to your own manager and you sound like you cannot run your team. Say "you need to step up" in a 1:1 and you get a nod, a week of visible effort, and then the same pattern. Move the work to the people who will do it and you have just told the whole team that the reward for being reliable is more work. The way out is to treat "lazy" as the symptom you can see, not the diagnosis, and to run the 1:1 like an investigation rather than a verdict.
The Attribution Trap
When someone else underdelivers, we explain it with their character: lazy, unmotivated, checked out. When we underdeliver, we explain it with circumstances: the ticket was vague, the environment was broken, the week was full of meetings. Psychologists call this the fundamental attribution error, and it is expensive for managers because a character label ends the investigation. Once a person is "lazy", you stop looking for the blocker, the unclear brief or the burnout that would actually explain the data - and that you could actually fix.
Five things that look like laziness from the outside
Before the 1:1, hold the label loosely. The same visible behaviour - slow output, easy tickets, thin updates - is produced by at least five different situations, and only one of them is about effort.
- Blocked and not saying so. Waiting on a review, an environment, a credential, a decision from another team. Quiet people wait rather than chase. Ask: "What are you waiting on right now?"
- Under-specified work. Vague tickets with no definition of done. The rational response is to pick the ones that are clear, which are also the small ones. Ask: "Can you tell me what done looks like on this one?" If they cannot, neither could you.
- Mismatch. A senior engineer on CRUD endpoints, or a junior on a migration nobody scoped. Both go slow, for opposite reasons. Ask: "If you could own one thing on the roadmap, what would it be?"
- Checked out. Interviewing elsewhere, burned out, or dealing with something at home. The tell is a change: pace drops and they withdraw from the team at the same time. Ask: "Something changed about six weeks ago. What was it?"
- Actually coasting. It exists. It is rarer than it looks, and the way you find it is by ruling out the other four and then watching what happens to a clear, written, dated expectation.
Before the meeting: get the evidence straight
The conversation goes wrong when it runs on impressions. "You seem disengaged" invites "I'm not", and you are now arguing about feelings. Spend twenty minutes beforehand and write down:
- Two or three specific examples from the last month. What was expected, what arrived, when, and the effect on someone else. "The migration ticket was sized at three days, took two weeks, and the mobile team waited on it." Not "your velocity is low".
- Whether they knew. Was the expectation ever stated, by anyone, in words? When did they last get feedback from you that was not "looks good"? If the honest answer is "never", the first 1:1 is a reset, not a warning.
- What you have already done. If you have silently rerouted their work, you have been hiding the problem from them as well as from your own manager. Stop before the meeting, so the gap is visible to both of you.
The 1:1 script
Open with the observation and a question, then stop talking. Most managers lose this conversation in the first minute by softening the opening into something the engineer can politely agree with and ignore.
Opening:
"I want to talk about pace on the payments work. The migration ticket was sized at three days and it's been two weeks, and twice this sprint the standup update was the same as the day before. I'm not assuming why - that's what I want to understand. What's going on?"
Then silence. Count to ten if you have to. What comes back decides the rest of the meeting.
If it is a blocker or an unclear brief:
"OK - that one's mine to fix. I'll get the staging credentials sorted by Thursday and we'll rescope the ticket together tomorrow. Next time, I'd rather hear 'I'm stuck' on day one than find out on day ten. Can we agree on that?"
If it is a mismatch or they are checked out:
"Thanks for telling me. I can't promise the roadmap changes, but I can promise what you work on next quarter is a real conversation, not an allocation. For the next four weeks, though, the migration still needs to land. What would make that doable?"
If there is no reason, or the reason does not hold:
"Here's what I need: the migration merged by the 28th, and a message in the team channel the moment you're stuck for more than a couple of hours. We'll look at where it stands every Tuesday. Is there anything that makes that unrealistic?"
Note what is not in any version: the word lazy, the word attitude, the word motivation, and any comparison to a colleague. Those are opinions. Dates, tickets and messages are facts, and facts are what you will need later if this goes further.
Put it in writing the same day
A short message after the meeting does three jobs: it checks you heard the same thing, it makes the expectation real, and it starts a record. Keep it factual and keep it kind.
"Thanks for the chat today. Writing down what we agreed so we're looking at the same thing: migration PR merged by Tue 28th; you'll flag in #payments if you're blocked for more than a couple of hours; I'll sort the staging credentials by Thursday. We'll check in on it in our Tuesday 1:1. Shout if I've got any of that wrong."
The four weeks after
- Check the written expectation, not the vibe. Every weekly 1:1 opens with where the agreed item stands. Nothing else about this topic gets discussed until that is answered.
- Praise the first real improvement, specifically. "You flagged the API blocker on Monday instead of waiting - that's exactly it." People repeat what gets noticed.
- Do not move the goalposts. If they hit the date, say so and set the next one. Discovering a new complaint every week is how an honest reset turns into a grievance.
- If it is missed twice with no blocker you can remove, this stops being a diagnosis and becomes the performance conversation: explicit, documented, and the start of whatever formal process your company uses. Done this way, a formal plan is never the first time they hear there is a problem - which is what it looks like from their side when it is.
What not to do
- Do not quietly reassign their work to your strongest engineer. It hides the gap from everyone who could act on it and it is how your best people start job-hunting. This is what it looks like from the colleague's side, and it is not flattering for the manager.
- Do not start counting commits. Surveillance metrics measure activity, not output, and the one person who notices you are doing it is the rest of the team.
- Do not wait for the review cycle. Six months of silence followed by a bad rating is the version of this story that ends up on a forum with you as the villain.
- Do not write the label down. "Lazy", "poor attitude" and "not motivated" in a message or a review are opinions that HR cannot defend and that the engineer will remember. Dates and deliverables are what you can stand behind.
Sentences that keep the conversation honest
"I'm not assuming why. What's going on?"
"What are you waiting on right now?"
"I'd rather hear 'I'm stuck' on day one than find out on day ten."
"Writing down what we agreed so we're looking at the same thing."
Each one states a fact or asks a question. None of them requires you to have already decided what kind of person they are.
Related, for engineers
- If you're the colleague, not the manager — how to stop absorbing someone else's work without starting a fight
- The performance conversation — what to say when the reset has not worked
- If you manage engineers — the conversations that make up the first year
Frequently asked questions
How do you deal with a lazy employee as a manager?
Replace the label with an observation. Bring one or two specific, recent examples of work that was expected and did not arrive, say what the impact was, and ask what is going on before you decide what it means. Then set a short written expectation with a date and check it weekly. The record, not your impression, decides whether this becomes a performance issue.
What do you say to an employee who is not pulling their weight?
Name the gap and ask a question: "The migration ticket was sized at three days and it has been two weeks. I am not assuming why - what is going on?" Then stop talking. The answer tells you whether you are dealing with a blocker, an unclear brief, a mismatch or a genuine effort problem, and each needs a different response.
When does a lazy employee become a performance issue?
When a clearly stated expectation, with a date, has been missed twice after the blockers you could remove have been removed. Before that point it is a management problem to diagnose. After it, it is a performance conversation, documented, and if that does not change anything, the formal process your company uses.
Should I tell the rest of the team why someone is underperforming?
No. Tell the team what you are doing about the work - who owns what now and by when - not what you think of the person. The team already knows there is a gap; what they are watching is whether you act. Quietly moving the work to your strongest engineer is the one move that makes everyone else slower.