A new software engineer joins a company on a Monday. By Thursday, she has accumulated a list of fourteen questions — about deployment procedures, about the difference between two internal environments, about how to get access to the logging dashboard. She spends a portion of each afternoon tracking down whoever might know the answer. By the end of week two, she's identified the two people on the team who seem to know everything, and she routes almost all her questions through them.
This is not a story about a poorly-run team. It's a description of almost every knowledge worker's first month at a company with more than fifty people. The knowledge exists. It's just not findable.
The measurement problem with onboarding friction
The cost of onboarding knowledge gaps is diffuse enough that most organizations don't measure it directly. Time-to-productivity metrics — when they exist at all — tend to capture when a new hire starts delivering output, not the cumulative hours lost to information search, repeated questions, and wait time for answers from busy colleagues.
The real cost has two components. The first is the new hire's own time: estimates from IT and operations teams that have tracked this closely suggest that in the first four to six weeks, new employees spend somewhere between three and six hours per week seeking out information that already exists in written form somewhere. Across a team that hires twenty people a year, that's a meaningful but invisible tax.
The second component is the senior colleague's time. The people who get pinged — the "human search engines" of a team — often can't fully quantify the interruption cost. But three or four context-switch interruptions per day, even if each resolves in five minutes, represent a significant attention budget drain. The McKinsey Global Institute's research on knowledge work has consistently found that employees spend roughly 20% of their working time searching for and gathering information. For senior engineers asked the same onboarding questions repeatedly, the friction is qualitatively worse because it involves interrupting focused work.
Why "we have a wiki" doesn't solve this
Most organizations that have been around more than a few years do have internal documentation. The problem is that documentation written for people who already understand the system is structurally different from documentation useful to someone who doesn't. This isn't a failure of intent — it's a natural consequence of how documentation gets created.
Documents get written reactively, typically after an incident or a repeated question reaches a threshold. The author knows the context. They write for an imagined reader who also knows the context — they're documenting the edge case or the exception, not the baseline. The result is documentation that reads as a list of caveats to an unstated mental model that new hires haven't yet built.
There's a secondary problem: even well-written documentation becomes unfindable as the corpus grows. A Confluence space with four years of history and three organizational restructures has a navigation structure that makes sense to no one who wasn't there for each phase. Search helps, but keyword search can't bridge the vocabulary gap between how a new hire asks a question and how the documentation is titled.
The specific failure mode: the question that can't be Googled
External search fails for internal questions, which sounds obvious but has important implications. A new DevOps engineer at a mid-size SaaS company can easily find general documentation about Kubernetes RBAC on the public internet. What they cannot find externally is how their specific company has structured its namespace permissions, what the internal approval process looks like, or which team owns which cluster. That knowledge is internal-only, scattered across a Confluence page written two years ago, a Jira epic that's been closed, and a Google Doc that was shared in a Slack channel in 2023 and never linked from anywhere else.
This is the onboarding knowledge gap in its most concrete form: the question that has a written answer, that can't be Googled, and that the new hire doesn't know how to find in the internal documentation system. They are left with two options — ask a colleague, or spend an hour trying to navigate a wiki they don't yet understand.
What good onboarding knowledge infrastructure looks like
The organizations that handle this well have a few things in common. First, they maintain documentation that is searchable by intent, not just by title. The person asking "how do I get read access to the production database?" needs to find the document whether it's called "Production Database Access Request Process" or "RDS Read Permissions — Engineering" or buried inside a general "Data Access Controls" page.
Second, effective onboarding knowledge infrastructure surfaces answers with their sources visible. This is more important than it might seem. A new hire who receives an answer without provenance has no way to assess whether it's current, who wrote it, or where to go for follow-up questions. An answer that comes with a link to the source document is verifiable, updatable by the new hire themselves if they discover an error, and gives them a mental model of where that category of knowledge lives.
Third, the best knowledge environments reduce the activation energy for asking questions. If the answer retrieval mechanism is a separate tool that requires a separate login, most new hires won't use it. The friction of adopting a new tool during an already cognitively demanding onboarding period is high. Integration into existing communication surfaces — particularly Slack, where most early-tenure questions get asked anyway — dramatically increases adoption.
The counterintuitive cost of the tribal knowledge shortcut
We're not saying that human mentorship and colleague relationships are bad for onboarding — they're essential. New hires should be building relationships with their teams. The problem is when colleague-as-search-engine becomes the primary knowledge retrieval mechanism, it creates incentives that compound over time.
Senior engineers who are consistently pinged with the same questions often write down answers — in Slack threads, in one-off emails, in personal notes — in forms that aren't indexed or retrievable by anyone else. The answer gets delivered, the new hire is unblocked, and the institutional knowledge stays in the same two or three people's heads. Nothing gets better at the system level.
The goal isn't to eliminate the human interaction — it's to reserve it for genuinely novel or ambiguous questions that require judgment, rather than burning it on lookups that a well-structured knowledge base should answer automatically. New hires who can self-serve on reference knowledge ramp faster, build broader mental models of the organization, and impose substantially less interruption cost on the senior engineers whose attention is expensive.
Measuring whether it's working
For IT and knowledge management teams trying to evaluate their onboarding knowledge infrastructure, a few leading indicators are worth tracking. New hire ticket volume in the first thirty days — specifically tickets that resolve to a link to existing documentation — is one direct signal. Query success rate in your internal search (sessions that end without reformulation) is another. The most honest signal, if you can collect it, is asking new hires at the end of their first month to categorize the questions they couldn't answer themselves: how many had written answers they couldn't find? That gap size is the baseline you're trying to close.
The onboarding knowledge gap doesn't require a cultural fix or a massive documentation project. It requires that the information which already exists becomes retrievable by the people who don't yet know where it lives.
Continue reading
Knowledge Hoarding in IT Teams →