I Watched Our Best Developer Accomplish Almost Nothing for an Entire Day
Last September, I shadowed one of our strongest developers for a full day. Not because I was worried about his performance. He's excellent. I was trying to understand why a project that should have taken three weeks was stretching into its fifth.
Here's what his day looked like.
9:00 AM: Started working on the API integration for Project A. Got into the code, pulled up the documentation, began writing the authentication flow.
9:23 AM: Slack notification from a designer on Project B asking about the image upload component specs. He answered, which took eight minutes because he had to look up the requirements document.
9:31 AM: Tried to get back into the API integration. Realized he'd lost his train of thought. Spent a few minutes re-reading the code he'd written before the interruption.
9:38 AM: Got back into flow. Made progress for about 20 minutes.
9:58 AM: Calendar reminder for a standup meeting on Project C. A project he was only peripherally involved in but was "kept in the loop" on.
10:00 AM: Standup meeting lasted 25 minutes. It was supposed to be 10.
10:25 AM: Back to the API integration. But now he had a question from the standup about Project C that he needed to follow up on. Spent 12 minutes on that.
10:37 AM: Finally back to the API code. Except now he couldn't remember exactly where he'd left off. Re-read the authentication flow. Noticed a bug he'd introduced in the last session. Spent 15 minutes fixing it.
10:52 AM: Client email from Project A needed a response about timeline. Replied.
11:03 AM: Back to coding.
11:20 AM: Slack message about a deployment issue on Project D. He was the only person who knew the deployment pipeline well enough to troubleshoot. Spent 30 minutes on it.
I'll spare you the rest of the day. The pattern repeated until 5:30 PM. When I tallied it up, he had about 2.5 hours of actual focused coding time on the project that was supposed to be his primary assignment. Out of an 8.5-hour day. That's a 29% productivity rate, and this was a good day by his own estimate.
The Research Is Worse Than You Think
The number most people cite is from Gloria Mark's research at UC Irvine: it takes an average of 23 minutes and 15 seconds to fully refocus after an interruption. That's bad enough. But the reality for service companies is even worse.
Dr. Mark's later research found that after an interruption, people don't immediately return to the original task. They work on an average of two intervening tasks before returning to what they were doing. So the 23-minute refocus time is the optimistic scenario. In practice, the chain of interruptions and intervening tasks can eat an hour or more.
There's also a quality cost. A study from the University of California found that interrupted workers made 20% more errors than those allowed to work without disruption. They also reported higher stress, frustration, and mental fatigue. This matches what I observe in our team. The bugs and oversights tend to cluster in the projects where people are spread the thinnest.
For service companies specifically, this problem is structural, not incidental. A marketing agency with 10 people and 20 active clients has at least two clients per person. A consulting firm with 8 people and 12 projects is juggling 1.5 projects each. And that's just the active projects. There are also proposals to write, maintenance clients to support, internal meetings to attend, and the constant drumbeat of client communication across all of those engagements.
Tool Sprawl Makes Everything Worse
In my experience, the average service company uses somewhere between 8 and 15 different tools daily. Email. Slack or Teams. A project management tool. A design tool. A development environment. A CRM. File storage. Time tracking. Video calls. Maybe a wiki. Maybe a client portal.
Every tool is another place where notifications live, another place to check, another context to switch into. I audited our own team's tool usage and found that people were switching between applications an average of 37 times per hour. Thirty-seven. Most of these switches were unconscious. A notification pops up, you glance at it, you're in a different context for 30 seconds, and then you're back. Except you're not really back. Your brain is still processing the notification.
We had a developer who kept four browser windows open across two monitors: the code editor, Slack, the project management tool, and email. All visible simultaneously. He thought this was efficient because he could "see everything at once." What actually happened is that his eyes were drawn to the newest notification every few minutes. He was essentially operating in a state of continuous partial attention.
The Client Expectation Problem
Here's the part that makes this uniquely hard for service companies. Your clients expect responsiveness. If a client sends an email at 10 AM and doesn't hear back until 3 PM, many of them feel ignored. Some will tell you directly. Others will just develop a vague sense that you're not paying attention to their project.
This creates a tension that doesn't exist in product companies. A software engineer at a product company can put on headphones, close Slack, and code for four hours. Nobody notices. A consultant at a service company who goes dark for four hours might get a concerned email from a client and a Slack message from their account manager asking "everything okay?"
I don't have a perfect solution for this. But I've found that setting explicit response-time expectations with clients helps enormously. At the start of every project, we tell the client: "You'll always hear back from us within four business hours. For urgent issues, call our direct line and someone will respond within 30 minutes. For non-urgent items, you might not get a response for a few hours, and that's by design, because our team is doing focused work on your project."
Most clients are fine with this. They don't actually need instant responses. They need to know they won't be forgotten. Setting the expectation upfront prevents the anxiety that drives them to send follow-up messages, which cause more interruptions, which slow down the work, which makes the client more anxious. It's a cycle, and clear communication breaks it.
What We Changed and What Happened
Over the past year, we made four changes to reduce context switching. Here's what worked and what the impact was.
We batched client communication. Instead of responding to emails and Slack messages throughout the day, we designated two communication windows: 9:30 to 10:00 AM and 2:30 to 3:00 PM. During those windows, everyone processes their client messages. Outside those windows, notifications are muted. Emergency calls still come through, but we defined "emergency" clearly: something that prevents the client from operating their business. Not "I have a question about the design."
This was the single biggest productivity improvement we've made. Our focused work time per person went from about 3 hours per day to about 5 hours per day. That's a 67% increase.
We reduced simultaneous project assignments. We used to assign people to three or four projects at once because it seemed efficient. Everyone was "available" for everything. Now, each person has a primary project (60 to 70% of their time) and at most one secondary project (20 to 30%). The remaining time is for communication, meetings, and small tasks. This wasn't easy because it sometimes means a project waits a day for someone to become available. But the quality improvement has been significant. Fewer bugs, fewer missed requirements, fewer "oh wait, I thought you meant..." moments.
We consolidated tools. We went from 12 tools to 7. We dropped our standalone time tracker (replaced with simple project-level logging). We moved client communication from Slack plus email to just email. We moved internal documents from Google Docs plus Notion to just one. Every tool we eliminated was one fewer source of notifications and context switches.
We instituted "maker schedules" on Tuesdays and Thursdays. No meetings on these days except genuine emergencies. People know they have two full days per week where they can plan for deep work. The psychological effect of this is almost as valuable as the practical effect. Just knowing that tomorrow is a maker day reduces the stress of today's interruptions.
The Measurable Impact
Three months after implementing these changes, I measured the results against our baseline.
Average project delivery time dropped by about 18%. Projects that used to take four weeks were finishing in just over three. Not because people were working harder or longer. Because they were working with fewer interruptions, which meant fewer errors, fewer rework cycles, and faster progress during focused time.
Client satisfaction scores went up slightly, which surprised me. I expected some pushback on the communication windows. Instead, clients noticed that when we did respond, our responses were more thoughtful and complete. Instead of quick, reactive answers throughout the day, they got considered, thorough answers twice a day. Several clients explicitly mentioned this improvement.
Our team reported lower stress levels. The biweekly pulse survey we run showed a meaningful improvement in "I feel I can focus on my work" and a decline in "I feel overwhelmed by competing priorities."
What I Got Wrong
I want to be honest about the things that didn't work.
I initially tried "no Slack after lunch." Complete moratorium on internal messaging for the afternoon. This backfired because people still needed to ask quick questions, and without Slack they resorted to walking over to someone's desk, which was an even bigger interruption. I learned that the goal isn't zero communication. It's intentional communication.
I also tried assigning people to only one project at a time. This was too rigid. In a service business, things come up. Clients have urgent needs. Proposals need input from someone who knows the domain. The single-project model created bottlenecks and frustrated both clients and team members. The primary-plus-one-secondary model was the right balance.
Context switching will never be zero at a service company. You're serving multiple clients, and that inherently means multiple contexts. But there's a massive difference between three context switches per day and thirty. The goal isn't elimination. It's reduction to a level where your team can actually do the work they were hired to do.
If your people are talented but projects keep taking longer than they should, the problem probably isn't talent or effort. Look at how many times per day they're being asked to shift their attention from one thing to another. That's almost always where the time is going.
