Back to Blog
2 min read

The Real Cost of Context Switching

Last Tuesday I worked 10 hours. Got almost nothing done.

Checked my calendar: 6 meetings scattered throughout the day. None longer than 30 minutes. Plenty of “free time” between them.

But that free time was useless. By the time I loaded context for a task, it was time for the next meeting.

The Math

Research says context switching costs 20-25 minutes to fully recover focus. My day looked like this:

  • 9:00 - Meeting (30 min)
  • 9:30 - “Free” but recovering context (25 min)
  • 9:55 - Productive (5 min)
  • 10:00 - Meeting (30 min)
  • 10:30 - Recovering context (25 min)
  • 10:55 - Productive (5 min)
  • 11:00 - Meeting (30 min)

Six meetings. Maybe 30 minutes of actual deep work. In a 10-hour day.

What I Changed

Meeting Batching

All meetings now go into two blocks: morning (9-11) and late afternoon (3-5). The middle of the day is protected.

No-Meeting Days

Tuesdays and Thursdays. No exceptions unless something is genuinely urgent. “Urgent” has a high bar.

Communication Windows

I check Slack and email at 9 AM, 12 PM, and 4 PM. Three times. Not continuously.

The first week people complained. The second week they adapted. Now they batch their questions too.

Task Minimums

If I start a coding task, I commit to at least 90 minutes. No switching before that. If a meeting falls in the middle, I either move the meeting or start the task after.

The Results

Output doubled. Not exaggerating. Same hours, twice the meaningful work.

Quality improved. Fewer bugs because I could hold the full problem in my head.

Stress decreased. The frantic feeling of never finishing anything went away.

Team adapted. People learned to plan ahead instead of dropping spontaneous requests.

For Managers

If your engineers are in meetings all day, they’re not engineering.

Every meeting with an engineer has a hidden cost: the 25 minutes after it where they’re rebuilding mental context.

Four 30-minute meetings don’t cost 2 hours. They cost the entire day.

The Hard Truth

Being “available” and being “productive” are opposites for knowledge work.

You can optimize for responsiveness or for output. Not both.

Choose wisely.

Michael John Peña

Michael John Peña

Senior Data Engineer based in Sydney. Writing about data, cloud, and technology.