The context switching myth

A head of engineering once told me, with a straight face, that his team couldn’t make faster progress because of excessive context switching. When I asked him to elaborate, he explained that about once every ten days, an engineer would have to stop what they were doing to fix a bug in code they’d written previously.

Once every ten days.

I pushed back. Hard. And after a bit of probing, he admitted something interesting: the engineers actually welcomed these interruptions. They used the bug-fixing sessions as a mental reset, a break from the monotony of their main task. It wasn’t a burden at all. It was a palate cleanser.

So why was he telling me it was a problem?

The Language Problem

Here’s what I’ve come to believe: when people in tech complain about context switching, they almost never mean actual context switching. What they mean, or what they should mean, is that they’re trying to do too many things at once, with no clear priority. That’s a legitimate problem. But it’s not context switching. It’s a lack of focus, or more often, a shifting landscape of competing demands.

The distinction matters because the solutions are completely different.

We All Context Switch, All The Time

Let’s be honest about what context switching actually is. It’s moving your attention from one thing to another. And every single one of us does it dozens, if not hundreds, of times a day.

You answer a text from a friend. You fetch a glass of water. You read a news headline that caught your eye. You scroll through LinkedIn for a few minutes. You choose what to have for lunch, then eat it. You reply to an email that’s been nagging at you. You brush your teeth, commute to the office and home again. Every one of these is a context switch.

Nobody works for a whole day without any interruption and nor should they. The human brain doesn’t operate that way, and it never has.

As a CTO, I context switch constantly. I might be reviewing a pull request, then jump to a call with a client, then respond to a Slack message, then check the status of three different AI agents I set running earlier, then review a contract, then return to that pull request. That’s not a bug in my day; that’s the job.

AI Actually Encourages Context Switching

Here’s the thing that makes the traditional complaint even more outdated: modern AI tools actively reward context switching.

I routinely set several AI agents running on different tasks, then write some emails, take a call, interact with another LLM on something unrelated, then circle back to see what the agents have produced. I review their output, give them new directions, and switch to something else while they work.

This isn’t inefficient. It’s leverage. I’m getting more done precisely because I’m not sitting watching a single task crawl to completion.

The engineers who thrive in this new world are the ones who can manage multiple threads of work, checking in on AI-assisted tasks while progressing others. The ones who insist they need four uninterrupted hours to write a function are going to find themselves outpaced.

The Real Problem

When engineering velocity is genuinely suffering, the cause is rarely context switching. It’s usually one of these:

Shifting priorities. When the goalposts move every week, nothing gets finished. That’s not a context switching problem; it’s a leadership problem.

Too many concurrent projects. If an engineer is assigned to five different initiatives simultaneously, they’re not context switching between them. They’re being set up to fail by having no clear primary focus.

Poor tooling and process. If every task requires navigating bureaucracy, waiting for approvals, or fighting with broken development environments, that’s friction, not switching.

Lack of clarity. If engineers don’t know what “done” looks like, they’ll spin in circles regardless of how few interruptions they have.

What To Do About It

If your tech team is complaining about context switching, don’t dismiss it, but don’t accept it at face value either. Ask what they actually mean.

Are they trying to do too many things? Then prioritise ruthlessly. Make it clear what the one thing is that matters most.

Are priorities shifting constantly? That’s on leadership to fix. Engineers can’t hit a moving target.

Are they genuinely struggling with normal workplace interruptions? Then perhaps the conversation needs to be about resilience and modern tooling, not about building a protective bubble around them.

The best engineers I know aren’t the ones who need perfect conditions. They’re the ones who can hold multiple threads in their head, switch between them fluidly, and use every tool at their disposal to maintain momentum.

Context switching isn’t the enemy. A lack of clear priorities is. Don’t let lazy language obscure the real problem.

---

Enjoy this article? Why not try Remote teams: what actually works after five years of data or When good metrics go bad. Or find out how I can work with you on solving your tech challenges.