What a New Hire Is Actually Missing

Ask a new hire what they're missing in week three, and they'll usually name a task, a login, a contact. Ask again in month three and the answer changes. What they're actually missing by then is smaller and harder to name: the reason twelve decisions went the way they did, none of which anyone wrote down next to the decision itself.

Across roughly three hundred working sessions here, the tasks were never the hard part to hand off. Anyone can read a task off a list and do it. What's expensive to hand off is the judgment sitting underneath it: why this approach and not the obvious other one, what got tried and quietly discarded, which constraint is actually load-bearing and which one is just how it happened to get built the first time.

The org chart shows the work. It doesn't show the reasoning.

A finished piece of work looks the same whether it took one clean decision or five failed ones first. That's the problem. What a new hire, or anyone stepping into unfamiliar territory, actually sees is the shape of the output: the doc, the workflow, the finished feature. The reasoning that produced it, including every dead end that didn't make the cut, doesn't travel with the artifact unless somebody deliberately attaches it.

So the new hire inherits the shape of the work without the argument behind it, and does one of two things: asks, which is the expensive version of the same bottleneck from before, or guesses, which is worse, because a confident wrong guess looks identical to a correct one until it fails somewhere downstream.

The single biggest failure we found in our own history

We went back through our own record of what's gone wrong across roughly two hundred sessions of building this company, looking for whatever pattern showed up most. One cause outweighed every other by a factor of three: somebody acting on information that used to be true and no longer was, without knowing it had changed.

Not because the information was hidden. Because whoever picked it up next had no way to tell a settled decision from a stale assumption that had simply never been corrected out loud. The fix wasn't "write more clearly." It was marking, at the moment something is decided, that it's a decision and not a guess, so the next person inherits the difference instead of a flat wall of text that reads equally confident either way.

What actually transfers

Not the task list. The task list was never the scarce resource. What has to transfer is the reasoning attached to the decision at the moment it was made, tagged as settled rather than assumed, and put somewhere the next person will actually see it before they act rather than after something breaks.

That's a harder thing to build than a task list, and it's the only part of onboarding that was ever actually expensive.

A few questions this raises

Isn't this just better documentation, again?

It's a narrower claim than that. The task itself is usually already documented somewhere. What's missing is the reasoning next to it, marked as a decision rather than a description, recorded at the moment it happened rather than reconstructed afterward by someone trying to remember why.

Can you actually measure this, or is it a feeling?

We measured it against our own record: one failure pattern, stale information treated as current, outweighed every other named cause by roughly three to one across nearly two hundred sessions. It's the largest single thing we found wrong with how we hand off our own work.

What's the first thing to fix if a team wants to try this?

Capture the reasoning at the same moment the decision gets made, not after. A decision written down a week later is already a reconstruction, and a reconstruction is exactly the kind of confident-sounding guess this problem is about in the first place.