Back to BlogEngineering Leadership

How to Handle the Engineer Who Hoards Context

|4 min read|
context hoardingknowledge sharingengineering cultureteam riskdocumentation

Every engineering team has at least one: the engineer who knows everything about a critical system, won't write it down, and gets pinged for context constantly. They're often your best engineer. They're also the team's single biggest continuity risk. Addressing this is a leadership problem, not a documentation problem.

Why context hoarding happens

Rarely deliberate. Usually a mix of:

  • Documentation feels lower-status than building.
  • The engineer enjoys being the go-to expert.
  • Writing things down feels like making themselves redundant.
  • The team has no documentation culture, so writing feels wasted.

You can't fix this by demanding documentation. You fix it by changing the incentives.

Step 1: make the cost visible

For two weeks, count: how many DMs does this engineer field per day asking for context? How many decisions stall waiting for them? How long does it take a new hire to ramp on systems they own vs. systems anyone else owns?

Share the numbers with them. Not as accusation — as observation. Most context-hoarders are unaware of the load they carry, because each individual interruption feels small.

Step 2: pair them with a designated backup

Assign one engineer as backup on each surface the context-hoarder owns. Backup attends decisions, shadows on-call, reviews PRs in that surface. The goal: in 90 days, the backup can answer 70% of the questions the primary currently fields.

This is the fastest path to context distribution. Documentation alone takes years; pairing takes a quarter.

Step 3: change what they're rewarded for

If the engineer's promotion case rests on "only person who understands X," they will protect that. Change it. The next level expects "developed two engineers who can independently own X." Promote on documented expertise, not hoarded expertise.

This is a conversation with HR and skip-level managers, not just a 1:1. The signal has to be company-wide for the engineer to believe it.

Make the writing easier than the speaking

If every "can you explain X?" gets answered with "let me write it up and link you," the engineer eventually realizes writing is less work than re-explaining. Provide templates. Provide a low-friction place to write. Don't make writing harder than the verbal answer they default to.

Context as a Team Asset

StandIn turns individual context into structured, queryable records — so no single engineer becomes the bottleneck for the team.

See the Workflow →

Run quarterly bus-factor audits

Every quarter, list every system and ask: how many engineers could keep it running if the primary left tomorrow? Anywhere the answer is one, that's the next surface to address. Make this a team-wide practice, not personal — the audit names systems, not people.

What to do if it doesn't change

Some engineers won't share context even with backup, even with incentives. That's a values misalignment with a distributed team. Escalate clearly: "This is a continuity risk. We need to fix it. Here are the specific behaviors I need to see in the next 60 days." Then enforce.

Most engineers will move. Some will leave. Either outcome is better than the status quo.

Common failure modes

Failure: avoiding the conversation because they're senior. Senior engineers especially need to share context. Their leverage is wider; their hoarding is more expensive.

Failure: assigning documentation as the fix. Documentation is the artifact, not the practice. The practice is pairing, training, and reward changes. Documentation follows.

Failure: treating it as a personal failing. It's a structural problem with personal expression. Fix the structure; the person mostly follows.

What to do tomorrow

Pick the engineer in your team who you'd panic about if they quit tomorrow. Identify the surfaces only they understand. Pick one of those surfaces and assign a backup this week. In 90 days, run the bus-factor question again on that surface and see whether the answer changed.

Frequently asked questions

What if the engineer says they don't have time to document?

They're right — they don't, because they're constantly being interrupted for context. Fix that by pairing them with a backup who absorbs the interruptions. Time follows.

Should we use AI tools to extract context from the engineer?

Limited value alone — the AI can compile what's written but can't extract what's in their head. The combination of pairing plus structured wraps captures more, sustainably.

What if context hoarding is rewarded by the company culture?

Then the org has a structural problem, not a team problem. The fix is at the VP or CTO level — changing what promotion looks like across engineering. Individual EMs can't fix this alone.

Get async handoff insights in your inbox

One email per week. No spam. Unsubscribe anytime.

Ready to eliminate your daily standup?

Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.

You might also like