When a teammate disappears

It happens almost every time

On unpaid team projects, people vanish often. That isn't a sign of bad people and it isn't your fault: jobs change, coursework piles up, interest fades.

Plan for it rather than hoping it won't happen.

Why people leave silently

Because saying it is awkward. They feel they've let everyone down, and instead of a conversation they simply stop replying. It seems less harmful that way.

The conclusion: make leaving unembarrassing. Say out loud at the very start that "I can't manage this any more" is a fine thing to say and nobody will take offence.

One sentence at the start noticeably raises the chance someone warns you rather than disappearing.

What to agree in advance

A point worth stating before you start:

If someone is gone for more than a week without notice, we treat them as having left. Their tasks go back to the list. No hard feelings, and they can come back.

It sounds dry, but it prevents the main affliction: a week in which everyone waits, does nothing, and is too embarrassed to ask.

What to do when someone goes quiet

Three or four days. Write privately, not in the group chat. Simply: "Hi, how are things? Everything okay?" No reproach. It's often something mundane.

A week. Write again, now about the work: "If this isn't working out right now, say so — that's fine, we just need to know. I'll take your task for now."

A week and a half to two weeks. Treat them as having left. Take the tasks, remove access, carry on.

The key thing is not to wait in silence. Projects die less often from someone leaving than from everyone else waiting three weeks and losing momentum too.

Taking over the work

Check nothing is lost. Anything not pushed to the shared repository is gone. Hence the rule: push unfinished work regularly rather than "when it's done".

Assess what got done. Sometimes it's half-finished, sometimes nothing.

Decide honestly. It's often cheaper to rewrite than to untangle someone's unfinished code.

Record the contribution. Even if they left, what they built was built. Acknowledging it is correct: the work happened and it's still in the project.

Restarting the project

If half the team is gone, those remaining need a decision rather than a slow burn.

Cut the scope. What three people planned, two won't build at the same size. Trim it to what's achievable and set a new date.

Decide whether to recruit. Sometimes finishing a trimmed version yourselves is faster than onboarding someone mid-flight.

Finish something. A trimmed but completed project is worth more than an ambitious abandoned one. And you can talk about it at interview.

Reducing the odds

Short timeframes. People don't scatter in two weeks. Three months is survived by few beginner teams.

Visible movement. When a result appears every week, interest sustains itself.

Regular check-ins. A stall is visible immediately: someone writes "nothing done" for the second time.

Recognised contribution. When what was built is recorded and confirmed, taking part gains a meaning beyond the product itself — and walking away becomes harder.