Onboarding without tribal knowledge

The first month on a team is a scavenger hunt. Who reviewed the payments retry? Why does checkout debounce submits? Which folder is “ours”? The answers live in people’s heads until those people go on leave.

Helix is built so that hunt has a place to end.

What a new hire should open

1. Graph: people, files, directories, pull requests. Click a folder. See who touches it.
2. Pulse: hot files, single-owner silos, architecture. The org’s current shape, not last year’s wiki.
3. Ask Helix: “Who knows src/checkout.ts?” Every sentence has a citation.

That is enough to make a first pull request without pinging five strangers.

The alternative is a buddy system that does not scale and a confluence page that froze in 2023. Neither is cruel. Both are slow. The graph is neither: it updates when the team merges.

Coupling is a map of fear

Files that always ship together are the places where a small change becomes an incident. Helix draws COUPLED edges when two files share multiple merged PRs. Pulse lists them. A new engineer can see the blast radius before they “just tweak the copy.”

Helix Review will say the same thing on the pull request itself, so the lesson is not trapped in a tab they forgot to open.

Mentions close the loop

When #41 says “Fixes #40”, that is a relationship. Helix records MENTIONS so history is a graph, not a scrollback. “Why did we add the debounce?” should not require the original author to still work here.

The org-sized version

Scale adds bus-factor alerts: people whose absence would strand a file. That is not surveillance. It is how you plan vacation, staffing, and review load without folklore.

Onboarding is the first test of whether software can explain itself. If a new hire still needs six weeks of Slack, the graph is not in the path of work yet.

Give the next engineer a graph instead of a scavenger hunt. Open Helix and index the repository they will actually touch.