A few years ago I sat down to write a critical piece of integration logic. I had the whole problem mapped out in my head. Twenty minutes in, an IM message pulled me into a production question. Ten minutes after that, a meeting reminder popped up for a sprint review I’d forgotten about. By the time I got back to the integration code, I had to re-read everything I’d already written just to remember where I was going with it.
That wasn’t a bad day. That was a normal day. And if you lead a development team, you’re probably creating days like that for other people without realizing it.
What’s Actually Happening When You “Multitask”
The word “multitasking” implies you’re doing two things at once. You’re not. What you’re doing is task-switching: stopping one thing, mentally unloading it, loading the next thing, and trying to pick up where you left off. Every switch has a cost.
Gerald Weinberg estimated that cost in Quality Software Management. His model is simple: one project gets 100% of your productive time. Two projects don’t get 50% each; they get 40% each, with 20% lost to switching overhead. Three projects? 20% each, with 40% lost. The math gets ugly fast.
For developers specifically, the cost is even higher than Weinberg’s general model suggests. Chris Parnin at Georgia Tech studied programmer interruptions and found that it takes an average of 10 to 15 minutes to get back into a coding task after an interruption, and that developers often can’t resume a task at the same point where they left off. They restart from a simpler place, retracing steps they’d already taken.
If you’ve ever come back from a meeting and stared at your code for five minutes thinking “what was I doing?”, that’s exactly what the research describes.
The Real Problem: Flow State Is Fragile
Mihaly Csikszentmihalyi’s research on flow describes a state of deep, focused engagement where you’re working at the edge of your ability and losing track of time. Developers know this feeling. It’s the two-hour stretch where the code practically writes itself and you look up and realize you forgot to eat lunch.
Flow takes time to enter. Most estimates put it at 15 to 20 minutes of uninterrupted focus. A single interruption resets the clock. So a developer who gets interrupted three times in an afternoon doesn’t just lose the interruption time. They lose the flow state entirely. They might never reach it that day.
Paul Graham captured this perfectly in his 2009 essay Maker’s Schedule, Manager’s Schedule. Managers work in one-hour blocks, and meetings are just entries in the calendar. Makers (developers, writers, designers) work in half-day blocks, and a single meeting in the middle of an afternoon can destroy the entire block. As Graham put it: “For someone on the maker’s schedule, having a meeting is like throwing an exception.”
I think about that line every time I schedule a 2:00 PM check-in and then wonder why the team’s velocity is slipping.
How Leaders Make It Worse
I’ll be honest: I’ve been the cause of this problem more than once. Here are the patterns I’ve caught myself in, and that I’ve seen other engineering leaders fall into.
Assigning people to multiple projects simultaneously feels efficient on a resource plan. In practice, nobody is doing their best work on any of the projects. Weinberg’s numbers apply here directly. If someone is split across three initiatives, you’re getting less than a third of their capacity on each.
Scheduling meetings in the middle of the day is the second one I’ve had to unlearn. A standup at 9:00 AM is fine. A design review at 2:30 PM fragments the afternoon. If I have to hold a meeting in the afternoon, I try to push it to 4:00 so the maker block stays intact.
Treating instance messaging as synchronous is subtler but just as damaging. When a leader sends a question and expects an answer within minutes, they’ve just created an interrupt. I’ve started being explicit: “Not urgent, respond when you have a break.” That one sentence protects someone’s flow.
The last one is the hardest to fix because it’s cultural: rewarding responsiveness over output. If the developer who answers every message immediately gets praised while the one who goes heads-down for three hours and ships a feature gets asked “where were you?”, you’ve built a culture that punishes focus.
What I’ve Changed
I don’t have a seven-step framework for this. I have a few things I’ve tried that helped.
I protect mornings. On my teams, we batch meetings into the afternoon when possible and keep mornings clear for focused work. It doesn’t work every day, but when it does, the difference in output is noticeable.
I stopped splitting developers across projects. When I have to assign someone to a second initiative, I treat it as a real cost, not a free resource allocation. I ask myself whether the second project is worth the 20% tax on both.
I got comfortable with slower responses. Not everything needs an answer in ten minutes. When I model that behavior, the team follows. People start batching their messages, checking IMs at natural break points instead of reacting to every notification.
I talk about it openly. I tell my teams that I expect them to protect their focus time, and I mean it. I wrote about related ideas in my posts on soft skills and the transition to management. The common thread is that leadership is about creating the conditions for other people to do their best work, and context-switching destroys those conditions.
What You Can Do as an Individual
If you’re not in a leadership role, you still have some control.
Block focus time on your calendar. Literally put a two-hour block called “Deep Work” on there and decline meetings that overlap it. Some people will push back. Most will respect it once they see the results.
Batch your communication. Check IMs and email at set intervals (I’ve heard developers use every 45 minutes, every hour, or after completing a Pomodoro cycle) instead of leaving notifications on.
Write yourself a breadcrumb trail. Before you step away from a task, leave a comment in the code or a note to yourself about exactly where you stopped and what you planned to do next. Chris Parnin’s research found that developers who left environmental cues recovered from interruptions significantly faster.
Say no more often. Not every meeting needs you. Not every instant messaging thread requires your input. Protecting your time isn’t selfish; it’s how you do your best work. I’ve written about the skill of saying no in my post on what surprised me about management.
Resources
- Maker’s Schedule, Manager’s Schedule by Paul Graham (2009) — the essential essay on why meetings destroy creative work
- Deep Work by Cal Newport — a full framework for protecting focus in a distracted world
- Quality Software Management, Vol. 1 by Gerald Weinberg — the source of the context-switching cost model
- The Pomodoro Technique — a simple time-boxing method that works well for developers
- Chris Parnin and Spencer Rugaber, “Resumption Strategies for Interrupted Programming Tasks” (2011) — the academic research on how developers recover from interruptions
Leave a Reply