Cutting engineer onboarding from weeks to days by making tribal knowledge searchable
We hired two engineers within a month of each other last spring, which gave us an accidental A/B test. The first started before we had our own search in place. The second started after. The difference in their first three weeks was large enough that I want to write down what caused it, because I don't think the tooling was the whole story.
Where the first weeks actually go
I asked the first engineer to keep a rough log of what slowed her down. Over three weeks it clustered into:
- "Where is X" — which repo, which service, which config. Answerable in seconds if you know, a scavenger hunt if you don't.
- "Why is it like this" — the decisions. Why two services instead of one, why this queue, why we don't use the obvious library. Almost never written in the code.
- "Who do I ask about Y" — routing. Figuring out which of eight people owns the thing you're stuck on.
- "Is this a known issue or did I break it" — the flailing you do when something behaves oddly and you can't tell if it's you.
The first and third categories are annoying but bounded. The second and fourth are the ones that eat days, because the answer exists — someone knows it — but it's in a person's head or a two-year-old thread, and a new person has no idea it exists or where to look.
What changed for the second engineer
He had the same four categories of question. The difference was that for "why is it like this" and "is this a known issue," his first move was the search box, not a Slack DM.
"Why do we have a separate service for exports" returned the original design discussion — the export jobs were blocking the main API's worker pool, and splitting them out was the fix. Thirty seconds, no human interrupted, and he got the reasoning, not just the fact, which meant he understood the constraint rather than just memorising the layout.
"Is the staging deploy supposed to take twelve minutes" returned three old tickets confirming yes, that's normal, here's why. He didn't spend half a day convinced he'd misconfigured something.
By the end of week two he was opening small PRs. The first engineer hit that point in week four. Same difficulty of work, same amount of help available from the team — the gap was almost entirely in how fast he could resolve his own "why" and "is this normal" questions.
The part that isn't tooling
Search only works if the answers are written down somewhere. The reason our index was useful to the second engineer is that we're a team that argues in Slack and comments extensively on tickets. All of that is messy, but it's text, and text is searchable.
If your team makes decisions in meetings and never writes them up, a search tool has nothing to find, and a new engineer is back to asking humans. The tool didn't create the knowledge. It made knowledge that already existed — scattered, undated, unlabelled — reachable by someone who didn't know it was there.
So the honest recommendation is two-part. Give new people a way to search across your tools, yes. But also notice, in that first month, every time they ask a question that should have had a written answer and didn't. That list is your actual onboarding problem. The search box just makes the list visible.
What we do now
New engineers get access to the search on day one and an explicit instruction: before you DM someone, ask the box, and if the box doesn't know, tell us — that's a documentation gap and we'll fix it. The second half matters. It turns onboarding into a process that improves the knowledge base instead of just consuming it.
Three weeks to three days is the headline, and it's real, but it's specific to us and to how much of our context happens to live in searchable text. Your mileage will depend on the same thing.
Set up search for your team and hand it to your next hire on day one.