For a few weeks, a new person on a team can see something nobody else can. Not because they’re sharper — they know less than everyone around them, by a lot. But they’re the only one in the room who hasn’t yet been trained to stop noticing. They read the repo layout and find it strange. They ask why the deploy has two steps that seem to do the same thing. They can’t tell from the code which of the three services is the one that actually owns the customer record. Every one of those reactions is a measurement, and it’s a measurement no one else on the team is capable of taking anymore.

The reason it’s uniquely valuable is that legibility isn’t a property you can assess from inside. Once you know why the deploy has two steps — there was an incident, the second step is a safety check, it was supposed to be temporary — the strangeness dissolves. You don’t experience the system as confusing, because you’re not reading it; you’re recognizing it. Every question you’ve ever had the answer to has been quietly subtracted from your perception of how hard the thing is to understand. The team’s collective sense of its own clarity is therefore systematically wrong in one direction, and there’s no amount of care that fixes it, because the distortion is what expertise is.

So the new person is an instrument. And the specific thing about this instrument is that it’s perishable. Three weeks in, they’ve learned the deploy quirk. Six weeks in, they’d have to work to remember that it ever seemed odd. By the time they’re productive enough for their opinion to carry weight in a design discussion, the reading is gone — they’ve been successfully converted into another person who can’t see it either. The window in which they can tell you something true about your system’s legibility is almost exactly the window in which they’re least confident that they have standing to say it.

Which is how the measurement gets destroyed, and the destruction always looks like helpfulness. Someone asks a confused question, a teammate gives a clear and generous answer, both parties feel good, and the confusion is resolved. What just happened is that a signal about the system was converted into a fact in one person’s head. The next new hire will ask the same question and get the same generous answer. The team will experience this as onboarding working well, and in one sense it is — but the thing that produced the question is still there, unchanged, and it will keep charging the same toll to every person who arrives.

The fix isn’t complicated, it’s just unnatural: treat the question as data about the system rather than a gap in the asker. Answer it, obviously — then write down that it was asked. Not the answer; the question. A running list of what each new person had to ask is the closest thing you’ll get to an objective map of where your system is opaque, and it’s built out of material you were going to throw away anyway. Anything asked three times in a row isn’t a series of individuals not reading carefully. It’s a finding.

The uncomfortable part is that the list mostly won’t produce documentation work. It’ll point at things that are confusing because they’re actually wrong — the second deploy step that nobody has removed, the service boundary that stopped matching reality two reorgs ago, the two names for the same concept. New people find those with unfair ease, because they’re the only ones without a working mental patch installed over the top. That’s the reading you’re getting for free, for about three weeks, once per hire.