The Context Switching Problem Every Dev Faces
Dev Leader Weekly 136
TL; DR:
Context switching is costly but never fully avoidable
Give your manager context before they re-prioritize
Limit work in progress to stay focused
Join me for the live stream (or watch the recording) on Monday, April 20 at 7:00 PM Pacific!
Context Switching -- The Tax Nobody Budgets For
I went into the ExperiencedDevs subreddit and found a discussion about task switching that I wanted to dig into. This is probably one of those topics where if you’ve been a software engineer for any length of time, you’ve felt the pain of being pulled in multiple directions. And if you’re an engineering manager, you’ve been on both sides of it -- getting randomized yourself AND being the person asking your team to switch gears.
I wanted to talk about this from a few different angles: as someone who was a software engineer constantly dealing with context switching, as an engineering manager who has had priorities shifted on my teams, and as the person who sometimes has to be the one delivering the new priority to my team. As usual, I’ll throw this disclaimer in -- anything I say comes from my own lived experience. It’s not the only way to look at it. Just my perspective to hopefully give you some different insights.
You can check out my full thoughts on this in the video below:
The Overhead Is Real -- And It’s Never Going Away
Here’s the thing about context switching: it’s not free. When you do a context switch, there’s mental overhead, there’s tooling overhead, there might be a completely different codebase or problem space you need to load into your brain. And the unfortunate reality? You’re never going to eliminate context switches entirely. That’s just not realistic.
The goal is twofold. First, minimize context switches. Second, when they do have to happen, make sure they’re understood. The person doing the work and the person injecting the new priority need to be on the same page about why the switch is happening.
Startup vs Big Company -- Context Matters A LOT
One thing I’ve noticed throughout my career is that context switching pressure varies dramatically based on where you work. The industry, the type of product, and even the company stage all play a role.
At a bigger, more established company with stable products and services, the disruptions tend to happen less frequently. That’s been my general experience, at least. But there’s a huge caveat -- live services change everything. A live service is this living, breathing thing where anything could go wrong at any given time. If you’re working on a service that’s running 24/7, you’re more likely to get pulled into an incident bridge or a security-related fire drill.
On my team at Microsoft, for example, we handle a lot of security-related work. If something security-related comes up where we can help, that’s going to randomize someone -- and it’s extremely high priority. As much as possible, I try to put myself into that situation to shelter my team from having to context switch. I’d rather that the people building things and moving the product forward can continue doing that. But there are absolutely cases where that’s just not realistic and I have to pull people in.
On the flip side, at a smaller company, I’ve noticed way more context switching. Even without a live service, if you’re actively talking with customers and always chasing the next opportunity, it feels like there’s always something new you have to go chase. Especially in the early stages of a company, that could be absolutely critical -- if you don’t chase those things, you might not have a company. I’ve talked about the differences between startup and big tech planning before, and it’s worth noting that the cost of context switching at a startup isn’t just one developer changing what they’re doing. As the company grows, it becomes the entire team -- engineering, UX, product, marketing, sales -- all having to pivot. That kind of context switching absolutely does not scale.
What You Can Actually Do About It
So what do you do when your manager keeps throwing new priorities at you? This is probably what most people want to hear, right?
Actionable Tip: Provide context back to the person giving you the new task.
This is one of the most helpful things I’ve ever learned. When someone comes to you with “Hey, got something new” -- instead of just quietly accepting it, provide them with visibility into what’s currently on your plate.
Here’s what that looks like in practice. In my startup days (and I’ll always put this disclaimer in -- loved working for the CTO and wouldn’t change a thing about it), the founder would frequently come to us with new ideas and new priorities. We needed to start pushing back, and what that looked like was:
“Hey, look -- we just talked about these three things that are all supposed to be top priority. We’re actively working on them right now. Now you’re giving us a fourth. There’s only so many people and so much time. Do you truly feel that this fourth thing is more important than making progress on these other ones? Because if so, understood -- we’ll do what needs to happen. But given what I just told you, is this really the most critical thing?”
Over time, these conversations became much more natural. And I want to be clear -- it wasn’t confrontational. It was just about awareness. I’ve found that a lot of the time, the person assigning work doesn’t have the same level of visibility into what you’re doing. That just makes sense -- they’re removed from the day-to-day details. When you raise that awareness and ask them to think through the priority, more often than not they’ll say, “Actually, no, you’re right. Those other things are more important.” It was more rare that they’d insist the new thing took precedence.
The key takeaway here is that even when the answer was still “yes, switch,” at least we were aligned on why. And that alignment makes all the difference. I’ve written before about how communication is the biggest gap between good and great developers, and this is a perfect example. Being able to clearly communicate what you’re working on and ask clarifying questions about priorities is a massive skill.
The Same Principle Works at Big Companies Too
I’ve seen the exact same dynamic play out at Microsoft. Using the security example again -- there are times when security teams bring things that are clearly “must fix now.” And we go fix them. But periodically, something comes up in the mix that isn’t really a “must fix now” -- it’s more of an enhancement or a feature request.
So we started having more conversations where we’d ask clarifying questions: “Hey, we just want to make sure we understand the severity and criticality of this. Is this a right-now thing, or is this something that can be planned for?” And a lot of the time, just asking those questions helped everyone realize that the new thing wasn’t as urgent as it initially seemed.
This ties into something I talked about in a recent issue about whether you should talk to your manager about burnout -- the foundation of these conversations is trust. If you have a good relationship with your manager and stakeholders, these priority-check conversations become natural rather than adversarial.
How I Manage WIP on My Teams
From the management side, I like to limit the number of items in progress for each team member. If you’re familiar with concepts from Kanban, this is basically about managing your WIP -- your work in progress. I’ve had really good experiences where limiting the number of things going on at once helps people maintain focus.
But here’s where it gets nuanced. At Microsoft, a lot of the changes we need to make don’t lend themselves well to a strict “one item at a time” cadence. When you deploy changes across the entire planet, we purposefully do it at a staged, controlled pace. That means it goes slower -- not because the technology can’t handle it, but because we consciously choose to roll things out carefully. The side effect? If I only gave someone one thing to work on, they’d be sitting idle waiting for their change to deploy.
So what I’ve found works across the teams I’ve managed -- from new hires to principal engineers -- is that people actually prefer to have a few things going on at once, as long as the priority is clear. A more junior engineer might have one or two things in flight. A more senior engineer might have three or four, including design documents and multiple features at different stages of rollout.
The critical part is making sure everyone is aligned on which thing takes precedence. And we also have to watch for the downside: when you have multiple things in progress, it’s easy for items to sit blocked and get forgotten. Someone context switches away from a feature that’s rolling out, and two weeks later nobody remembers it needs attention. So staying on top of awareness and tracking is essential.
Document It If Your Manager Isn’t Getting It
I briefly skimmed through the Reddit comments on this one, and some people made a point I wanted to echo. If you’re trying to convey the impact of context switching to your manager and not having a lot of success with conversations alone -- try documenting it.
Actionable Tip: Keep a record of what you’re working on over time. When context switches happen, write them down. Then, when you want to have the conversation, you can show a visual of you bouncing between tasks and never actually finishing anything.
It’s just more context and visibility for the person assigning the work. I think a lot of the time, managers aren’t being malicious -- they’re just missing context. And if you’re feeling like company alignment isn’t quite where it should be, providing that documented proof of constant task switching can be a powerful way to start the conversation.
Sheltering Your Team -- The Manager’s Role
If you’re in a leadership position, I think one of the most important things you can do is act as a buffer between your team and the constant stream of incoming priority changes. Your team’s ability to stay in flow and actually ship things depends on you filtering out noise before it reaches them.
Here’s how I think about it in practice:
1. Absorb the disruption yourself when possible. I mentioned the security example earlier -- when something high-priority comes in that’s going to randomize someone, I try to put myself into that situation first. Yes, it means I’m the one getting context switched, but I’d rather take that hit than pull an engineer out of the middle of a complex feature. My job as a manager is to enable my team to do their best work, and sometimes that means shielding them from the chaos even when it’s inconvenient for me.
2. Find natural transition points. One of the better examples I can think of is when someone was literally finishing up their current work and about to start the next thing. Right before they began, we were able to redirect them to a different work stream, and a new team member picked up what they would have originally started. That kind of timing worked really well because nobody was being ripped out of something mid-thought. The cost of switching at a natural boundary is dramatically lower than mid-task.
3. Batch and filter incoming requests. Not every “urgent” request that comes from stakeholders is actually urgent. Part of the manager’s role is to ask those clarifying questions on behalf of the team before the request ever reaches them. If I can resolve a priority question in a five-minute conversation with a stakeholder, that’s infinitely better than disrupting an engineer’s entire afternoon.
4. Be transparent about what you’re sheltering them from. I’ve found that teams appreciate knowing that you’re actively protecting their focus -- not because they need to be grateful, but because it builds trust and it helps them understand that when you do come to them with a context switch, it’s genuinely important. It changes the dynamic from “my manager keeps throwing random stuff at me” to “if my manager is asking me to switch, this must really matter.”
What I try to avoid at all costs is the “drop everything you’re doing” scenario. That’s just disruptive in every way. And as I mentioned in the recent issue about staying technically sharp when your role gets more strategic, sometimes that means I absorb the context switch myself so my team can keep their flow.
The Bottom Line
Context switching is never going away. The goal isn’t elimination -- it’s minimization and alignment. Whether you’re a developer being asked to switch tasks or a manager making those calls, the single most impactful thing you can do is provide and ask for context. Give your manager visibility into what you’re working on. Ask clarifying questions about the urgency and priority of the new thing. Document the impact when words aren’t enough.
And if you’re a manager, try to shelter your team when you can, find natural transition points for switches, and make sure everyone is on the same page about what matters most. A lot of frustration around context switching comes not from the switch itself, but from the feeling that nobody is aligned on why it’s happening.
Join me and other software engineers in the private Discord community!
Remember to check out my courses, including this awesome discounted bundle for C# developers:
As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.
Nick “Dev Leader” Cosentino
social@devleader.ca
Socials:
– Blog
– Dev Leader YouTube
– Follow on LinkedIn
– Dev Leader Instagram
P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!