We built onboarding. We never built the other door.

I wrote last week about moving my family’s chat onto a server I own — twelve years of Slack, fourteen people, and a niece turning twelve who wants in.

Writing it, I noticed something I hadn’t expected, and it isn’t about servers.

Over twelve years that family workspace had a functioning membership process. People arrived — partners, children reaching the age where we let them in. People left, because on a long enough timeline some relationships end. And every single time, someone had to actually decide what happened: to the account, to the messages, to the person’s place in a shared archive they’d been part of.

Nobody wrote that process down. It worked anyway, because in a group of fourteen you cannot pretend a departure didn’t happen. The absence is visible. Somebody has to do something.

Then I looked at the companies I’ve worked with, which have written down a great deal more, and noticed they mostly handle this worse.

The asymmetry

Almost every organisation of any size has an onboarding process. Often a good one. A checklist, a buddy, a first-week plan, accounts provisioned before the person walks in, a welcome message in the team channel. Somebody owns it. It gets reviewed when it goes badly.

Now ask the same organisation what happens when someone leaves.

You’ll usually get an IT ticket. Revoke SSO, disable the laptop, recover the hardware, forward the mailbox for thirty days. Sometimes an exit interview that nobody reads. Occasionally a “please document your work before you go,” issued about a week before the go.

That’s not a process. That’s a cleanup.

The asymmetry is strange when you look straight at it, because both events are the same event viewed from opposite ends — a change in the membership of a group. We’ve built enormous care around one direction and left the other to whoever happens to be nearby.

Why it happens

I don’t think it’s negligence. I think it’s that arrival and departure feel like completely different kinds of occasion, and only one of them is comfortable.

Onboarding is optimism. Someone chose us. There’s budget attached, a manager who fought to fill the role, a team who wants the help. Everyone involved is motivated, and the work is pleasant.

Departure is awkward for everyone in the room. If the person resigned, there’s a small institutional sting to it. If they were let go, there’s discomfort and often legal caution. Either way the manager is already thinking about backfill, the team is anxious, and the person leaving is halfway out. Nobody wants to run a thoughtful three-week programme in that atmosphere. So it gets compressed into a checklist that mostly protects the company’s assets, and everyone is quietly relieved when the last day arrives.

There’s also a structural reason: onboarding has an owner. Usually HR, sometimes the hiring manager, but someone whose job it explicitly is. Offboarding is split between IT (accounts), HR (paperwork), and the manager (everything that actually matters) — and the third one has no template and no time.

Security is the shallow half

The part organisations do handle is access. Revoke the credentials, rotate the shared secrets, remove them from the repos. This is real work and it matters, and it’s also the part that gets automated first, because it’s mechanical and the failure mode is legible. Nobody has to have a difficult conversation to disable an account.

But if access were the whole problem, offboarding would be a solved problem, and it very obviously isn’t.

What actually walks out the door is everything the checklist has no field for.

The knowledge, first. I spent six weeks earlier this year trying to move knowledge out of one person’s head and mostly failed, and the thing I learned there applies exactly here: expertise doesn’t transfer because you asked for it in the final fortnight. It transfers when someone whose job it is brings real problems to the person who knows, and writes down why the answers were what they were. A departure announcement is the worst possible moment to start that, and it’s almost always when it starts.

Then the relationships. The person who had the working rapport with a difficult client. Who knew which colleague at the supplier actually answers. Who could get a decision out of a particular director because they’d built up fifteen years of goodwill. None of that is in a document, and none of it is transferable by introduction email.

Then the context — the reasons. Why the deployment runs at that hour. Why we don’t use that library. Which past disaster a strange-looking rule is preventing. This is the layer that makes a system comprehensible rather than merely operable, and it lives in people. When it goes, what remains is a codebase that works and nobody can safely change.

And the open threads. Half-finished negotiations, a conversation with a customer that was going somewhere, the thing they were about to raise. These don’t get inherited. They just stop.

The half nobody counts

There’s another cost, and it doesn’t appear on any risk register.

How you handle someone leaving is the last thing your organisation ever says to them — and it’s the version of your company they’ll describe to other people for years. The industry is smaller than it looks. People who left well recommend you, refer candidates, sometimes come back. People who left badly tell that story precisely and accurately, and it’s a story with your name on it.

But the more important audience isn’t the person leaving. It’s everyone still there.

Your team watches an exit very carefully. They are, in that moment, learning what this place does to people when they’re no longer useful to it. A rushed, cold, transactional departure teaches them exactly what to expect for themselves, and no amount of values-on-the-wall survives contact with that observation. A departure handled with some dignity — acknowledged, thanked, given time — teaches them something else.

This is the part where the family comparison bites. In a group of fourteen you cannot handle a departure badly and have it go unnoticed. Everyone sees it. The cost is immediate and social, so the behaviour self-corrects. Companies are large enough to absorb the damage invisibly, which means the behaviour never self-corrects — it just accumulates, one shrug at a time, into a culture.

What the other door should look like

I don’t think the answer is another checklist, mostly because the checklist already exists and it’s the shallow half.

What’s missing is that the departure has an owner and a runway.

Give it an owner. Someone whose explicit job is this departure — not IT, not HR, a person who is accountable for what the organisation retains and how the person leaves. If nobody owns it, the mechanical parts happen and nothing else does.

Start before the notice period. This is the uncomfortable one, and it’s the one that actually works. If knowledge transfer only begins when someone resigns, you’ve already lost. The organisations that survive departures well are the ones where the capture is continuous — where somebody’s job is asking the experts real questions and keeping the answers, permanently, regardless of who’s leaving. Then a resignation is a scheduling problem rather than a crisis.

Ask while they still care. The most honest, useful account of how your organisation actually works is available in the last two weeks of someone’s employment, and almost nobody collects it properly. Not the HR exit form — a real conversation, with someone senior enough to act on it, about what’s broken and what they’d fix. The catch is that this only produces anything if the rest of the departure was handled decently. People who feel discarded tell you nothing.

Name the inheritance explicitly. Not “the team will absorb it.” Every relationship, every ongoing thread, every piece of context gets a named person, and the handover happens as an introduction with the departing person in the room, while they’re still there.

Say something. Publicly, in front of the team, with specifics about what the person did. It costs nothing and it’s the part most often skipped, and skipping it is the loudest thing you can do.

The thing I keep coming back to

The family workspace has no HR department, no policy document, and no offboarding checklist. It handles membership change better than most companies I’ve seen — not because we’re wise about it, but because the group is small enough that avoidance isn’t an option. Somebody has to decide, and everybody watches.

Scale removes that pressure. It doesn’t remove the obligation, it just makes the obligation easy to ignore, and organisations reliably take the offer.

We’re very good at the day someone arrives. We built a whole practice around it. The other door is the same door, and most of us have never got round to building it at all.