The Hidden Cost of Interruptions

Focus level graph showing how interruptions cause repeated 23-minute recovery cycles

The 23-minute problem

Every time someone on your team says "just ask Richard, he knows," you're not just asking a question. You're triggering a 23-minute productivity loss.

This isn't speculation. It's research.

Gloria Mark, a professor at UC Irvine, conducted a landmark study on workplace interruptions. Her findings were stark: it takes an average of 23 minutes and 15 seconds to return to the original task after an interruption.

Not 23 minutes to answer the question. 23 minutes to recover the mental context that was lost.

The math gets worse

Consider a team of 10 engineers. Conservative estimates suggest each person faces 4-6 interruptions per day. If your senior engineers are interrupted even 5 times daily:

Metric	Impact
Time lost per interruption	23 minutes
Daily interruptions (senior eng)	5
Daily productivity loss	~2 hours
Weekly loss (per person)	~10 hours
Monthly cost (assuming $150k salary)	~$3,600

And this doesn't account for the compounding effect: the senior engineer becomes a bottleneck, other team members wait for answers, and the entire team's velocity suffers.

The documentation paradox

The obvious solution is documentation. Write it down. Create a wiki. Build a knowledge base.

But here's the paradox: the people who have the knowledge are the same people who don't have time to document it. They're too busy being interrupted.

Even when documentation exists, it faces three fundamental problems:

Decay: Code evolves. Documentation doesn't. Within months, written docs diverge from reality.
Context loss: Documentation captures the what, rarely the why. "We use Redis for caching" tells you nothing about the three alternatives considered, the trade-offs evaluated, or the constraints that led to the decision.
Discoverability: Knowledge bases become graveyards. Engineers learn it's faster to ask Richard than to search through 200 Notion pages.

Knowledge lives in unexpected places

The insight that changed our approach: the knowledge already exists. It's just fragmented across systems that weren't designed to surface it.

Every pull request contains implementation decisions. Every code review captures architectural discussions. Every commit message (the good ones, at least) explains intent. Every design doc records trade-offs.

The problem isn't creating knowledge. It's connecting it.

A different approach

We're building Emisso around a simple premise: what if you could query your team's collective knowledge without interrupting anyone?

The core is what we call a context graph - a connected representation of your codebase that links:

Code: how it's implemented
Pull requests: why changes were made
Documentation: what was intended
Decisions: the reasoning behind architectural choices

When someone asks "why does the auth service work this way?", the answer isn't in any single artifact. It's in the connection between the PR that introduced it, the RFC that proposed it, the comments that refined it, and the code that implements it.

The goal

We're not trying to replace documentation. We're trying to make the knowledge that already exists accessible - automatically, continuously, without requiring Richard to stop what he's doing.

Because Richard should be writing code, designing architecture, mentoring juniors, and solving hard problems. Not explaining the same thing for the fifth time this week.

¿Tu equipo sufre de este problema?

Si las interrupciones constantes están afectando la productividad de tu equipo, me encantaría conversar contigo. Estamos construyendo Emisso precisamente para resolver este problema.

Agenda una conversación conmigo →

Building Emisso - understanding your product instantly is caring for your team and customers. Learn more