Product Thinking

The day someone quits, your company forgets how it works

Onboarding isn't broken because training is bad. It's broken because your company can't remember, and we got tired of watching the answer walk out the door.

ASR

Apollo Space Research

Apollo Space

· 13 min read

A new engineer joins on a Monday. By Thursday she needs to ship a small fix, and she hits a question only one person can answer, the person who built that deploy step and left three weeks before she started. His Slack handle is deactivated. His notes, if they ever existed, are in a doc nobody can find. So she does what every new hire does: she asks the next-nearest human, who half-remembers, and she ships on a guess.

Nothing about that is a training problem. The training was fine. The orientation deck was fine. The problem is older and stranger than any of that: the answer she needed was never stored anywhere a person could reach. It lived in one head, and the head walked out the door, and on the day it did, a small, specific piece of how the company actually works quietly stopped being knowable.

That is the pain we kept running into, in our own company and in every customer’s, and it is the pain nothing on the market actually solves. A company that can’t remember is a company that re-learns itself every time someone leaves. Onboarding is just the place where you finally feel it, the moment a fresh person collides with everything the company forgot to keep.

This post is a forensic: where the knowledge goes, why every existing fix misses it, and what becomes possible when the company itself can hold an answer.

Where the answer actually goes

Open up the welcome lunch and the swag bag and ask what onboarding is, mechanically. It’s a knowledge transfer, a fast, panicked one, that has to happen exactly when the source of the knowledge is least available. The new hire needs a hundred small truths: how we deploy, who approves what, why that broken-looking thing is load-bearing, which vendor to call, what the unwritten rule is. Almost none of it is in a system. It’s distributed across a few dozen human heads, each holding a different shard, none of them with the time to transcribe it.

So the new hire becomes a detective. Week one is fine, the assigned buddy is fresh, the intro calls are scheduled, the goodwill is high. Then week two arrives and the seams show. The buddy gets pulled into a launch. The one person who understands billing is on vacation. “How do we do code review here” returns three different answers from three different people, because the rule lives in five heads and none of them agree. The real lesson of week two isn’t any single fact. It’s the meta-fact: knowledge here is a person you have to catch, and catching people is a full-time job nobody told you was your job.

The numbers say almost everyone is living that version. Gallup reports that only 12% of employees strongly agree their organization does a great job onboarding, roughly seven in eight new hires are the detective above. And the SHRM Foundation has long documented that strong onboarding lifts first-year retention while a weak one is among the clearest signals that a new hire leaves inside the year. The cost of a bad first month isn’t an awkward week. It’s the person you hired walking back out, because a company that can’t remember made them feel like they were the only one who didn’t already know.

The two fixes the market keeps selling, and why both miss

When a company finally takes this seriously, the market hands it two answers. Both are honest attempts. Both miss, and it’s worth being precise about why, because the way they miss is the whole reason we built something with a different shape.

The first answer is a better buddy, a smoother program, a longer shadowing period, a checklist of intro calls. It feels humane: people learn from people, so point the new person at more people, more warmly. But it doesn’t touch the actual failure. It just nominates one human as the designated rememberer and prays that human stays in the building, stays un-busy, and happens to hold the exact shard this new hire needs. You haven’t made the knowledge durable. You’ve added a friendlier single point of failure who can still quit.

The second answer is write the wiki, mandate documentation, make people put it in a doc. You have seen how this ends. Writing docs is a separate task from doing the work, so it is always the task that gets cut. The wiki gets authored once, at launch, by someone who already knows everything and therefore can’t see what a newcomer won’t. Six months later it describes a system that no longer exists, and a wrong wiki is worse than no wiki, because the new hire trusts it and ships on a lie.

Notice the common error. Both fixes treat memory as a chore a human chooses to do, catch the right person, or sit down and write the doc. Anything that depends on a busy human doing extra work, at the moment that work is least urgent to them, will not happen at scale. A company that can’t remember on its own is not going to start because you asked it nicely. The losing assumption isn’t the buddy or the wiki. It’s that institutional memory is a favor people perform, instead of something the company is structurally capable of.

We weren’t trying to build a better buddy or a smarter wiki. We were building a company that doesn’t depend on either, where the remembering isn’t anyone’s chore because it’s a property of the substrate the work already runs on.

Two lanes for the same new-hire question. In the naive lane, knowledge is a person: the question routes to the one buddy who knows, who is busy, on vacation, or already quit, the answer dies in a dead Slack handle, and the new hire ships on a guess. In the Apollo lane, knowledge is a company asset: the same question routes into a company brain that captured the answer while the expert was still here, and gets back the same answer every time, the steps plus the reason behind them.

That picture is the difference between the two lanes, and it’s the whole argument in one frame: in one, knowledge is a person who can leave; in the other, it’s an asset the company owns and can serve forever.

What it takes for a company to actually remember

Here’s the part that took us real work, because “just store the knowledge” is exactly what the wiki promised and couldn’t deliver. The reason it couldn’t is that it asked a human to do the storing. The substrate has to do it instead, and it can, because of what the OS already is, not because of a documentation feature we bolted on.

Two things have to be true, and neither can be a favor anyone has to remember to do.

The answer has to get captured from the work itself. When the deploy runs, the steps are already observed. When a question gets asked and answered in a channel, that exchange is already a retrievable fact. When the expert explains a thing once, the explanation is kept, not as a chore they did on documentation afternoon, but as the exhaust of them doing their actual job. The company brain fills up from the normal motion of the company, which means the writing-it-down step that always got cut isn’t a step anyone has to perform. That capability isn’t a wiki. It’s what a system does when it’s on and living where the work happens, the same property that lets it do a dozen other things, pointed here at memory.

And the new hire has to be able to reach it in their own words. Capture is half the job; the other half is recall that works the way a stuck person actually thinks. Not “know the magic search term the doc was filed under,” but “ask the question the way you’d ask a coworker”, how do I deploy a hotfix here, and who has to approve it?, and get back the captured steps and the reason behind them. The reason is the part that matters most and survives least. A list of commands tells you what to type; it doesn’t tell you why approval exists, or which step is the one people skip and regret. The captured answer carries both, because it came from the people who learned it the hard way, and now the new hire inherits the lesson without having to relive it.

A company that can’t remember makes its newest, least-equipped person re-derive truths the company already paid to learn. The fix isn’t a thicker handbook. It’s making the memory a property of the company instead of a property of whoever happens to still be sitting there.

The person who already quit is the whole point

You could read all of that as a nice convenience for week two and miss the thing that actually matters. So let me say it plainly.

Every company, at every moment, is leaking knowledge through the people about to leave. Turnover isn’t an event you recover from, it’s a constant drain. The US Bureau of Labor Statistics tracks millions of voluntary quits every month; in any team of real size, someone is always on their way out. When they go they don’t just vacate a seat. They take the answers only they had: the why behind a weird workaround, the vendor contact, the reason the load-bearing thing that looks broken must not be touched.

The standard defense, the exit interview, the two-week handoff doc, is a fiction, and the same fiction as the wiki. Nobody transcribes two years of judgment in their last fortnight, and the things you most need are precisely the things they don’t think to write, because to them they’re obvious. The knowledge that’s hardest to capture is the knowledge that’s most expensive to lose, and it leaves in a person’s head every single time.

This is the case where “a company that can’t remember re-learns itself every time someone leaves” stops being a phrase and becomes a number on a calendar. You cannot stop people from leaving; you shouldn’t try. What you can change is whether leaving takes the knowledge with it. If the answer was captured while the expert was here, then the day they quit, their seat empties but their answers don’t. The new hire three weeks later asks the company and gets the answer the expert would have given, without the expert.

A loop showing why the person who quit is the point. An expert solves something the hard way and explains it once; that answer is captured into the company brain while they are still on the team; the expert eventually leaves and their seat empties, but the captured knowledge stays; the next new hire asks the company instead of chasing a person who already quit, and in asking, adds to the same brain again.

That loop is the actual thing we’re building. Capture the answer while the head is here. Keep it when the head leaves. Serve it to the next person who needs it, and let their question deepen it further. Turnover stops being a knowledge cliff and becomes a normal flow of people across a memory that outlives any of them.

Hire well and you keep good people. Build a company that can remember and you keep what they knew, whether they stay or not.

The breadth nobody bolted on

Worth naming why this isn’t an onboarding product and never will be. To make the new hire’s Thursday work, we didn’t build an HR tool. We pointed the same two things the OS already does, capture the exhaust of real work, answer questions in plain language with the reason attached, at one painful moment in one person’s first week.

Which is why the same substrate quietly answers the support engineer who inherits a ticket about a system its author left, the manager reconstructing why a decision was made two reorgs ago, the auditor tracing who approved what. Those aren’t five features shipped to resemble five tools. They’re one shape, a company holding its own memory and serving it back, falling out for free wherever a person would otherwise chase another person. The breadth isn’t a checklist we’re proud of. It’s the tell that we built memory at the level of the company, not one department at a time.

The turn: the welcome was never the documentation

So be precise about what this replaces and what it must never touch.

It does not replace the human who walks the new hire to coffee on day one, notices she’s overwhelmed, says the right thing, makes a stranger feel like she belongs. The welcome, the trust, the sense that these are people worth doing hard work beside, no company brain captures that, and none should try. Belonging is not a retrievable fact.

What it replaces is the tax sitting on top of the welcome. The senior engineer answering the same setup question for the eleventh time instead of building. The new hire spending week two as a detective instead of contributing. The slow dread of not knowing who to ask and not wanting to look like you don’t know. That tax was never the human part of onboarding, it was the part that made the human part impossible, because the people who should have been welcoming were stuck being a search engine for institutional memory the company never bothered to keep.

That world, where leaving stops costing the company its own memory, where the newest person can ask the company instead of chasing a person who already quit, does not exist on the market yet. The market is still selling thicker handbooks and friendlier buddies, still treating memory as a chore a human must volunteer for. We think a company should simply be able to remember, the way a person remembers, as a property of being alive and at work. We’re building that from the pain of watching the answer leave, one quit at a time, and onboarding is just the first place you get to feel it work. The new hire on Thursday gets the deploy right on her first try, the expert’s seat empties and his answers stay, and the people who used to be a search engine get to be people again.

Apollo runs your company's repetitive ops so your team doesn't.

Join the waitlist for early access, founding-user pricing, and a front-row seat as we ship.

Join the waitlist