What Happens to Your Projects When Someone Leaves

Someone on a four-person team gives two weeks' notice on a Tuesday. Everyone is polite about it. There's a small cake. On the last day, someone remembers to ask for the laptop back and to revoke the shared logins, and that feels like the handoff is done.

Three weeks later a client asks why a decision was made a certain way in March, and nobody who's still there was in that conversation. Or a task marked "in progress" turns out to be forty percent finished and forty percent finished in a way only the previous person understood, because the other sixty percent was still in their head, not in the task.

That's the actual failure. Not the offboarding checklist. The state of the work.

A resignation is a data loss event

Nobody frames it that way at the time, because it doesn't look like data loss. Nothing crashed. Nothing got deleted. The person who left is still reachable by email for a while, still willing to answer a Slack message about "that thing with the client." But willingness fades, memory fades faster, and eventually you're paying someone's replacement to guess.

Here's what actually leaves with a person, even in a small, friendly, well-intentioned team:

• What was verbally agreed with the client that never made it into a message or a document
• Why a task is built the way it's built — the constraint that ruled out the simpler option
• Which half-finished thing is actually close to done and which just looks close
• Who on the client side actually makes the decision, versus who just relays it
• What was tried already and didn't work, so nobody wastes a week rediscovering it

None of this is secret or withheld. It's just uncaptured. The person doing the work didn't write it down because writing it down felt like overhead, and the work itself was the priority. That's a reasonable trade to make every single day until the day they leave, at which point it becomes an expensive one all at once.

Before: the departure that goes fine

A designer at a six-person agency puts in notice. In the two weeks before she leaves, the team lead sits with her and goes task by task through her open work. Not a formal document — just the two of them, on a call, walking through what's actually true about each thing she owns.

This works, as far as it goes. It surfaces the big stuff — the client who's upset about timeline, the file that's password protected somewhere nobody else knows. But it's still a one-time act of memory retrieval under a deadline. Whatever she doesn't think to mention in that hour doesn't get mentioned. Whatever her replacement needs to know six weeks later, after the departure is old news and nobody's thinking about it anymore, isn't in that conversation at all.

After: the departure that doesn't

A developer at a similar-sized shop leaves under identical circumstances — two weeks' notice, no ill will, reasonable amount of time to hand off. But the handoff meeting is short, almost boring, because most of what matters is already sitting outside his head.

The reason a particular API decision was made is in a comment thread on the task itself, from four months ago, not in his memory. The client's actual sign-off on scope is a request thread with a timestamp, not a recollection of a phone call. The task that looks half-done has a progress report attached to it explaining what's actually finished and what's still assumption. None of this was produced for the handoff. It was produced while the work was happening, because that's where it's cheapest to write down — in the moment, next to the thing it's about, not reconstructed later from memory.

His replacement still has questions. But the questions are about the work, not about excavating what the last person knew.

What to externalise before it matters

This isn't a case for a documentation culture, a wiki nobody updates, or a rule that everyone must write a paragraph before lunch. Most of that fails for the same reason ad hoc handoffs fail: it's disconnected from the work, so it goes stale, or it never gets written because it isn't next to the thing it explains.

The useful version is narrower. A short list of things worth putting outside someone's head as they happen, not after someone quits:

• The reason behind a non-obvious decision, attached to the task it affects, at the moment it's made
• Anything agreed with a client verbally — written back to them, even briefly, so there's a record on both sides
• What's actually finished versus assumed finished, on anything that takes more than a day or two
• Who the real decision-maker is on the client side, if it isn't the person who emails the most
• Dead ends — approaches that were tried and dropped, so the next person doesn't repeat them

Why this keeps happening on the same small teams

Small teams are the most exposed to this, not the least. A twelve-person company can absorb one departure without losing a project's memory, because more than one person usually had eyes on any given piece of work. A three-person agency often has exactly one person who knows why the client's invoicing works the way it does, or what the last two rounds of feedback actually meant. When that person leaves, that knowledge doesn't get diluted across the team. It just leaves.

This is also, in our experience, one of the more common reasons a team finally adopts something other than a shared doc and good intentions — right after a departure went badly, not before. The badly-handled exit is the one that convinces people the informal approach has a real cost, not a theoretical one.

Where this fits into how Team and Tricks is built

This is part of why a task in Team and Tricks carries more than a status. A Classic task has a description and progress reports attached directly to it, so the reasoning behind the work sits with the work, not in whoever did it. A checklist task carries comments and attention markers on individual rows, so "this part is blocked" or "this part needs a decision" is visible without asking the person who owns it. Requests keep the thread of what was asked and agreed, rather than letting it live in a phone call nobody else was on.

None of that replaces a real handoff conversation when someone gives notice — you still want that conversation. But it changes what the conversation has to cover. It stops being an attempt to extract everything from someone's memory before they walk out the door, and starts being a shorter check on things that were already written down.

The distinction worth keeping isn't "document more." It's that context has a place to live that isn't a person, and if it doesn't have that place while the work is happening, it won't magically acquire one during someone's last two weeks.