A new engineer joining your team in 2026 takes roughly 60 to 90 days to ship meaningful work. This is the industry norm. Companies optimize their onboarding documents, pair programming schedules, and 30 / 60 / 90 day plans to try to reduce this number. Most efforts produce marginal improvements.
There is a better path. Teams that build institutional memory into their tooling consistently see new engineers ship meaningful work in 30 to 45 days. The difference is structural, not procedural.
This article explains the difference and what to do about it.
Why traditional onboarding is slow
Three friction sources account for most of the 60 to 90 day ramp.
Friction 1: Asking the same questions everyone asked. New engineers ask senior engineers questions that have been asked before. The senior engineer answers, often by typing the same answer they have typed three times in the last month. Both lose time. The new engineer eventually learns by asking enough questions; the senior engineer gradually becomes less responsive as fatigue sets in.
Friction 2: Hunting for decision rationale. The new engineer encounters something in the codebase that seems odd. They do not know if it is intentional (with good reason) or accidental (legacy that should be cleaned up). They have to either ask someone or assume one or the other. Wrong assumptions in either direction cause real problems.
Friction 3: Reconstructing project context. The new engineer is assigned to a project that has been in flight for months. The full context exists across Slack threads, Linear tickets, Notion pages, and meeting transcripts. Reconstructing it takes weeks of part time effort.
These frictions are not solvable by writing better onboarding documentation. The documentation gets stale. The documentation cannot capture the actual decision rationale. The documentation cannot reconstruct project context because the context is fundamentally cross tool.
These frictions are solvable by structural changes to how institutional memory is captured.
What structural change looks like
When a team has institutional memory captured as a process graph (decisions, commitments, failures as tracked entities), the new engineer onboarding flow changes in three specific ways.
Change 1: The new engineer asks the system, not a senior person. “Why do we use Postgres over MongoDB?” returns a structured answer: the decision entity with rationale, evidence, and the original Slack thread cited. The new engineer gets the answer in 30 seconds without bothering anyone.
Change 2: Decision rationale is structurally preserved. When the new engineer encounters the odd looking pattern in the codebase, they can ask “why is this structured this way?” and get the original decision entity. They understand the constraints that drove the design without having to guess or interrupt.
Change 3: Project context is one query away. “What is the current state of the auth migration project?” returns the structured project history: the original decision, the commitments and their owners, the failures encountered and lessons learned, the recent progress. The new engineer ramps to full context in hours, not weeks.
| Question | Traditional | With memory |
|---|---|---|
| Why do we use X? | 2 to 3 days | 30 seconds |
| How does Y work? | 1 week | 15 minutes |
| What is the status of Z? | Multiple meetings | 2 minutes |
| Who knows about W? | Trial and error | Instant |
The compounding effect
The time savings on individual questions add up. If a new engineer asks 50 questions in their first month and each one saves an hour of someone’s time (theirs or a senior engineer’s), that is 50 hours saved per new hire.
For a team that hires 5 engineers a year, that is 250 hours of senior engineer time recovered. At loaded engineering cost, that is a meaningful slice of an FTE.
But the bigger impact is on the new engineer’s confidence. When they can self serve answers, they feel productive immediately. They stop feeling like a burden on senior engineers. They start asking better questions (deeper, more specific, more valuable) because they have handled the basic ones themselves.
This confidence change is hard to measure but enormous in effect. New engineers who feel productive in week 1 stay engaged. New engineers who feel like a burden in week 1 sometimes never recover.
What this looks like in practice
A working example: a new engineer joins on Monday. Standard onboarding includes a single 30 minute session with the engineering manager to set up their tools and explain the company brain (Pulse, in this case).
By Tuesday afternoon, they have asked the system roughly 20 questions: how does our auth flow work, why do we use Linear instead of Jira, who handles incident response, what is the deployment process, what is the status of the active sprint. Each answer comes with sources cited. The engineer can dig deeper on anything that needs it.
By end of week 1, they have reviewed the active project they will be working on (entire history accessible via the process graph) and started writing their first PR. By end of week 2, they have shipped something meaningful. By end of month 1, they are at full productivity for their assigned scope.
This is not a fantasy. Teams that have institutional memory built into their tooling consistently see this pattern. The new engineer onboarding cycle compresses from 60 to 90 days to 30 days.
What to do if you are not there yet
Three practical steps to reduce onboarding time even without a full company brain.
- Build a structured decision log. Even a simple list of past decisions with rationale, captured in a single Notion database, beats scattered Slack threads. New engineers can browse it on day 1.
- Document the “who knows what” map. For each major system in your codebase, identify the 1 to 2 people who know it best. Make this map accessible to new engineers from day 1. Reduces “who do I ask?” friction.
- Schedule context loading time in week 1. Before the new engineer is expected to ship anything, give them dedicated time to load context: review past decisions, browse active projects, sit in on meetings. The week of investment pays back over the following weeks.
These steps help. They do not fully solve the structural problem. The structural solution is institutional memory captured as a process graph: every decision, commitment, and failure preserved as a queryable entity. This is what Pulse provides. Live demo at pulsehq.tech.