Start by making the work visible and specific, then talk to the person directly and privately before assuming bad intent. If nothing changes, raise it with the lead or supervisor using facts, not complaints. Quietly doing their work yourself feels helpful but hides the problem and burns you out.
What people tell me
I am working in a team, either a university group project or a small team at work. One person consistently does very little. They miss meetings, deliver late or not at all, and the rest of us end up covering their part. I do not want to be the person who complains or causes drama, but I am tired of doing extra work and worried it will affect our grade or how our team is seen. I do not know whether to talk to them, tell someone, or just do it myself.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Vague ownership makes it easy to drift. Assign named tasks with dates where everyone can see them.
- Talk to them privately first, with curiosity. There may be a reason you do not know about.
- Describe specific facts and impact, not their character.
- If it continues, escalate to the lead or supervisor with a short factual record.
- Silently covering their work hides the problem from the people who could fix it.
Before anything else, make the work visible
In many teams I have seen, the "person who does not contribute" is partly a symptom of unclear ownership. When tasks live in a group chat and everyone is loosely responsible for everything, it is easy for one person to drift and hard for anyone to say exactly what was missed.
So the first move is structural, not personal:
- Put every task in one shared place: a board, a spreadsheet, a ticket system.
- Give each task exactly one owner and a due date.
- Hold a short weekly check-in where each person says what they finished and what is next.
This alone fixes a surprising number of cases, because it becomes obvious to everyone, including the person themselves, what they have and have not done.
Talk to them directly, privately, and early
If the pattern continues, speak to them one to one before going to anyone else. Assume there might be a reason: a family situation, a health problem, being lost technically and embarrassed to say so, or simply not understanding what was expected.
Something like:
"Hey, I noticed the API part has slipped two weeks in a row, and we need it for the demo next Friday. Is something getting in the way? If you are stuck on it, I am happy to pair for an hour."
Notice what this message does: it names a specific fact, states the impact, asks a genuine question, and offers help. It does not say "you never do anything".
Describe behaviour and impact, not character
| Instead of | Say |
|---|---|
| "You are lazy" | "The last two tasks assigned to you were not done by the date" |
| "You never care about the project" | "When the login part was late, we could not test the rest" |
| "Everyone is annoyed with you" | "I am worried we will miss the deadline" |
People can respond to facts. They defend against labels.
If it continues, escalate with facts
If you have made ownership clear and had a direct conversation, and nothing has changed, it is time to involve the lead, manager or supervisor. This is not snitching. It is giving the person responsible for the team the information they need.
Keep it short and factual:
"I wanted to flag a delivery risk. Three of the four tasks assigned to one teammate over the last month were not completed, and I spoke with them directly two weeks ago. I am concerned about the deadline. How would you like us to handle it?"
A simple record of tasks, dates and outcomes from your board is enough evidence. You do not need to build a case file.
Why you should not just do it yourself
It is tempting. It feels faster and avoids an awkward conversation. But it has real costs:
- You burn out, and your own work quality drops.
- The lead or supervisor sees a team that delivers and has no idea there is a problem.
- The teammate learns that missing work has no consequences.
- In a graded project, you may end up with the same grade as someone who did nothing, with no record of why.
Covering once in a real emergency is fine. Covering as a habit is not.
If you are the lead
If you are leading the group, the same steps apply, but with more responsibility for the structure. Check that expectations were actually clear. Ask whether the person has the skills for the task, and adjust if not. Sometimes reassigning someone to work they can do well turns a non-contributor into a solid one.
What this teaches you
Handling this calmly is one of the most valuable workplace skills you can build early. Every team you ever join will have moments of uneven effort. Engineers who can raise it clearly, without drama and without covering it up, become the people others trust to lead.
A worked example from a group project
A composite of a situation students describe often: four people building a final year project, one of whom has not pushed any code in five weeks.
- Week one: the group moves tasks from the chat into a shared board, one owner each, and agrees a Friday check-in.
- Week two: the quiet teammate's task (the reporting page) is still untouched. One member messages privately and learns they are stuck on the charting library and too embarrassed to say so.
- Week three: they pair for an hour. The teammate delivers a basic version by Friday.
Not every case ends this well. If the teammate had not responded, the group would have shown the supervisor the board with dates, and asked for guidance on redistributing the work and recording contributions fairly. Either way, the board did the heavy lifting.
A self-check before you escalate
Make sure you can say yes to these first:
- Were tasks clearly assigned with one owner and a date?
- Did I speak to the person directly, privately and without accusing?
- Did I offer help or ask what was in the way?
- Do I have a simple, factual record of what was missed?
If any answer is no, start there. It is fairer to them and it makes your escalation far more credible if it is still needed. If you are nervous about the conversation itself, how to give feedback without creating conflict has wording that works here too.
If you are still stuck
Read The habits that make an engineer worth routing work through and What actually changes in your first two years as an engineer. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
- The Habits That Make an Engineer Worth Routing Work ThroughEvery team has one or two engineers other people route work through, and what they have in common is not raw technical strength. It is that when something is given to them it comes back, and when it will not, you hear about it early. Fifteen habits that build that reputation, none of which require a title or permission.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.