The High Cost of Interruptions

Teresa Torres follows up her controversial argument that teams should ignore some bugs by explaining why interruptions are so costly. Using a series of escalating analogies about co-writing a paper, she shows how context loss grows with group size, missing authors, unfamiliar languages, and incompatible tools. The point is that engineers hold large amounts of context in their heads, so an interruption can cost far more than the fix is worth. Product managers, even non-technical ones, need to grasp this cost so engineering time goes to the highest-impact work rather than to chasing every imperfection.

01Key takeaways

• Interruptions carry a hidden cost because engineers must rebuild lost mental context before resuming work.
• The cost of an interruption rises with team size, missing original authors, and unfamiliar code or tooling.
• Some bug fixes are trivial, but others require reconfiguring environments and understanding unfamiliar code, which can be expensive.
• Product managers should weigh the cost of context switching against the impact of a fix before pulling engineers off current work.
• Non-technical product managers don't need to code, but they do need to understand the true cost of interruptions to set sensible priorities.
• Aiming for good enough, rather than perfect, helps teams focus engineering time on the work that matters most.

02Key sections

Why interruptions cost more than they seem

Torres opens by acknowledging the backlash to her bug post and says the missing point was the high cost of interruptions. She frames the discussion around people who already understand this cost and those who think every bug must be fixed immediately.

The paper analogy

She asks readers to recall writing a school paper and imagines being interrupted at different stages. Each added complication, such as co-authors, missing authors, or a foreign language, makes resuming work harder.

Engineering context and tooling

Torres maps the analogy onto software, where code is written by people who have left, in varied languages, with varying expertise. Fixing an old bug can mean setting up unfamiliar environments and risking new defects.

Prioritizing for impact

She argues that product managers should direct engineers toward high-impact work rather than pixel-perfect polish. Her experience over twelve years leads her to conclude that good enough really is good enough.

03From the post

“In this post, I argued that you should ignore bugs. It was easily the most controversial blog post I've written. If you haven't read it, go ahead, read it. I'll wait. It was fun. Naturally, some people disagreed. If you read the comments, you'll see that”

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.