The context switching calculator: full methodology and downloadable model

The full-fidelity version of the homepage calculator, with the complete methodology written out beside it. Every assumption is visible. Every number is auditable. Export the model as CSV and bring it to your CFO.

The base formula is transparent and intentionally simple:

Each variable is independently overridable. The formula is not intended to be a rigorous academic instrument. It is intended to be a transparent back-of-envelope calculation that any manager can audit, challenge, and own in a boardroom. The strength is not precision; it is shared language and visible assumptions.

The 15% conservative model. For teams doing substantial amounts of shallow, easily resumable work, or for teams with mature context-switching hygiene (paired work, strong module boundaries, low interruption culture), the 15% loss per switch is the appropriate starting point. It assumes that a context switch costs approximately half a Weinberg switch and that some recovery happens quickly.

The 20% Weinberg model (default). From Quality Software Management, Vol 1 (Dorset House, 1991, pp 284-285). The most-cited figure in the field. Weinberg presents this as the switching overhead in a two-concurrent-project scenario: with two projects, each receives 40% of productive time, with 20% lost to switching. Using 20% as the per-switch loss in our model applies Weinberg's estimate to each individual switch rather than each project transition. This is a reasonable approximation for high-cognitive-load environments.

The 30% Mark refocus model. Based on Gloria Mark's 23-minute 15-second refocus finding (CHI 2005/2008). If an engineer is in an 80-minute deep-work block and is interrupted at the 50-minute mark, the remaining 30 minutes of the block is effectively consumed by the refocus cost (23 of the 30 minutes, rounded to 30%). For engineering teams with frequent unplanned sync interruptions (Class 4 on the interruption taxonomy), the 30% model reflects actual observed costs more accurately than the Weinberg default.

All variables are linear: doubling any single input doubles the annual figure. This is a feature, not a limitation. The deliberate transparency means a reader can stress-test every number:

The CSV export (Download CSV button in the calculator) contains: all input parameters, all output figures, and the formula in the final column so the reader can audit the arithmetic. The export is designed to be self-contained: a non-technical CFO should be able to open the CSV in Excel or Google Sheets, read the assumption labels, and understand the calculation without referencing this page.

Three practical applications, in order of impact:

In a VP Engineering 1:1. Run the calculator with your team's numbers. Bring the CSV. The conversation is not "here is a scary number" but "here is a number that is currently unmanaged. What is our plan?" The calculator makes the cost legible, which is the prerequisite for managing it.

In a board review. Apply the organisation-wide number as a P&L line item alongside salary, facilities, and tools. For a 100-person engineering-heavy organisation at $150/hr fully loaded with 4 switches/day, the Weinberg model produces an annual context-switching cost of approximately $1.7M. That number is larger than most engineering tool budgets and comparable to a senior hire.

In an attention audit. Use the calculator output as the before measurement. After 90 days of calendar discipline, deep-work block protection, and notification hygiene, re-run the calculator with the updated switches/day number from RescueTime or similar telemetry. The delta is your measurable ROI.

This is a back-of-envelope calculator. It trades precision for transparency. It does not model: indirect costs (morale decline, turnover risk from burnout, quality degradation from constant interruption, error rates), team-specific task load variations, or non-linear effects (some interruptions have asymmetric costs depending on depth of work disrupted). For a regulated setting requiring auditable precision, commission a formal study. For an engineering or operations leader who needs a defensible number to move a conversation, this calculator is sufficient.

The most common objection to this kind of model is "my team doesn't experience these costs that severely." The appropriate response is to instrument it: measure actual focus-block lengths, actual Slack DM frequencies, and actual switches per day using passive telemetry (RescueTime, Timing, or similar), then re-run the calculator with observed numbers rather than assumed ones.