Why Hiring Makes Your Best Engineers Worse
A new engineer posts a question in Slack: "Why does the deployment pipeline retry three times before failing?"
A senior engineer sees it. She context-switches from the code she was refactoring, opens the deployment config, traces through the retry logic, remembers the incident from six months ago that led to that decision. Twenty minutes later she's written a thoughtful explanation. Both people walk away feeling good. Healthy team, right?
Except now the senior engineer opens her editor and the refactoring she was halfway through has evaporated from her head. She'd been tracing a data flow across four files, had just identified an edge case with how nullable fields propagate through the transform chain. That context is gone from working memory. She scrolls through the files, trying to remember where she was, which edge case she'd found, what fix she was about to try.
Fifteen minutes later she's partially back. The question took 20 minutes to answer, but it cost an hour of productive time.
The Numbers
Most people have heard that interruptions are bad. Maybe they've seen the 23-minute stat from Gloria Mark's research on knowledge workers: managers, financial analysts, project leaders switching tasks constantly and taking 23 minutes to return after an interruption.
For engineers, the numbers are worse.
Chris Parnin and Spencer Rugaber tracked 10,000 programming sessions across 86 programmers using Eclipse and Visual Studio to measure what actually happens after an interruption. When a programmer gets interrupted mid-edit, they resume in under one minute only 10% of the time. The other 90% lose 10-15 minutes rebuilding context before they can start editing code again. In 93% of interrupted sessions, the programmer had to navigate to multiple code locations just to reconstruct what they were doing. Only 7% could pick up where they left off without any navigation at all.
A programmer gets approximately one uninterrupted 2-hour session per day.
The rebuild cost is higher for programming than for general knowledge work because engineering requires holding more state in working memory. The data flow across four files, the edge case with nullable fields, the architectural context of why the pipeline retries three times: all of that has to be reconstructed from scratch after an interruption. The general interruption research understates the problem for engineers.
But that's not the real issue.
The Asymmetry
In sales and support, the core work is already interrupt-driven. Sales reps take customer calls, respond to inbound emails, manage live chat queues. Support leads jump on customer escalations throughout the day. The rhythm of the work is built around real-time responsiveness. When a new rep asks their manager a question between calls, the cognitive cost is low because the manager was already operating in interrupt mode. They weren't holding a complex mental model that gets destroyed by context-switching.
Engineering is different. The valuable output requires sustained, uninterrupted focus: holding a mental model of a data flow across multiple files, tracing how edge cases propagate through a system, debugging a race condition that only shows up under specific load patterns. This is focus-driven work. The output happens inside a single person's working memory when no one is asking them questions.
The onboarding model engineering inherited was designed for those interrupt-driven functions: shadow the senior person, ask when you're stuck, interrupt someone if you're blocked. This playbook is structurally hostile to how engineering work actually happens. Not because engineering managers are worse at onboarding. Because the playbook doesn't fit the function.
Pair programming is the exception that proves the rule. It works because both people are engaged in synchronous shared focus on the same problem at the same time, driver and navigator switching roles as they go. That's collaboration, not interruption. But most companies don't onboard through sustained pair programming. They onboard through "read the code and ask when you're stuck," which combines passive observation (low learning for the new hire) with ad hoc interruptions (high cost to the senior). The gap between what works and what companies actually do is the problem.
A few companies have invested in structured engineering onboarding programs. Stripe and Shopify are notable examples, but they're the exception. Many engineering orgs default to the borrowed playbook because that's what the rest of the company does for new hires.
The Compound Effect
Week one of a hiring batch, one new hire posts a question a day. No big deal. The senior engineer answers them during natural gaps between tasks, and she's still shipping.
By week four, five new hires are all ramping simultaneously, hitting different parts of the codebase at different times. The questions are constant. One asks about the deployment pipeline, another about the database migration strategy, a third is debugging an authentication edge case. The senior engineer is context-switching six times a day. Her editor is open, but she's mostly scrolling through code she wrote three context-switches ago, trying to remember where she was. The mental model she needs to hold for her own work keeps evaporating before she can act on it.
Week eight. The senior engineer has quietly shifted her real work to evenings and weekends. The daytime is consumed by context-sharing that nobody tracks as "work." The new hires are making progress, getting unblocked, learning the codebase.
But the person who's supposed to be shipping the hardest technical projects is underwater.
This doesn't last 60-90 days like customer support or sales SDRs. Engineering ramp times to full productivity, meaning an engineer who can independently manage complex work without senior guidance, typically run 6-9 months. Some organizations report longer. Customer support ramps in 60-90 days, sales SDRs in about 90, and even complex enterprise sales roles with long deal cycles take about 170 days. Engineering is 2-3x longer than every other function because "productive" doesn't mean "shipped a PR." It means "understands the architecture well enough to make safe decisions about it."
For the senior engineer, she's subsidizing this for six to nine months per hire. And if the company is growing, hiring cohorts overlap. It never actually ends. One person is at week four while another is at week ten while a third just started.
The interrupt stream is constant.
Nobody tracks this cost. Companies measure time-to-first-commit and maybe time-to-first-PR, but nobody measures flow-state-hours-lost-to-onboarding. That metric doesn't exist, and so the new hire's ramp time stays visible while the senior engineer's hollowed-out day does not.
AI coding tools like Copilot and Cursor can help with environment setup, syntax, and boilerplate. They can even surface code patterns and documentation through codebase-aware chat. But they lack the tacit knowledge, judgment, and historical context that explains why the deployment pipeline was designed this way, what failed before, what was tried and abandoned. The architectural and historical knowledge is the slow part of onboarding. It still lives almost entirely in people's heads.
The Escape Hatch
The problem isn't the questions, which are entirely legitimate. The new engineer needs to know why the deployment pipeline has that edge case.
The problem is that a real-time interruption is the only mechanism for getting the answer.
What if the senior engineer had already answered that question? Not in a doc that went stale three months after someone wrote it. In a 10-minute conversation with an AI agent three weeks ago, where it asked her "what happens when the deployment is slow?" and she talked through the edge cases, the reasoning, the history. A conversation she barely remembers having because it happened in a natural gap in her day, between a code review and a standup, not in a scheduled documentation sprint.
Here's what the mechanics look like.
An AI agent reads the existing codebase, documentation, and recent incident reports. It identifies gaps: areas where the docs are thin, where the code is complex, where decisions were made that nobody wrote down. Then it has short, structured conversations with the experts who own those systems. It asks things like "What would someone less experienced miss about this retry logic?" and "When was the last time this broke, and what did you try first that didn't work?" These are the questions that surface the reasoning and judgment calls that never make it into commit messages or PR descriptions.
The expert opens the session when she has ten minutes free, talks through the answers at her own pace, and closes it. No scheduling, no time-zone coordination, no "knowledge transfer week before someone leaves." When things change (a production incident, a code refactor, an architecture decision), the AI re-engages: "You mentioned the CI/CD pipeline was going to change last quarter. Two incidents have touched it since. What actually happened?" The knowledge stays current because the system tracks what changed and asks about it, instead of waiting for someone to update a wiki that nobody reads.
The output is queryable: at 2pm on Tuesday, the new engineer asks "why does the deployment pipeline retry three times?" The answer is already there: the senior engineer's full reasoning and context drawn from her own words three weeks ago, covering the edge case, the incident that triggered the design decision, and the trade-offs they weighed. The senior engineer was never interrupted. The new engineer gets unblocked in minutes instead of waiting for someone to be free on Slack.
From "every question costs an hour" to "every question costs nothing, because the answer already exists."
The new hire gets unblocked without becoming a constant interrupt stream. The senior engineer keeps her focus. And the knowledge gets captured in passing, without anyone treating documentation as a second job.
The ramp time gap isn't a management problem or a documentation problem. It's an architecture problem. The mechanism for transferring knowledge (real-time interruption) is structurally incompatible with the mechanism for creating value (uninterrupted focus). No amount of better docs or more structured onboarding programs fixes that incompatibility.
You have to decouple the asking from the answering.
That's a design change, not a process change.