Episode 242: Why Context Switching Slows You Down
In this episode of the Product Thinking Podcast, Melissa Perri tackles the common challenge faced by smaller companies and rapidly growing businesses: multiple product managers accessing the same development team.
Melissa explores the pitfalls of context switching among developers, which can lead to productivity losses and delayed project delivery. She emphasizes the importance of clear ownership and accountability within teams to improve efficiency and product quality. By measuring cycle time, bug rates, and delivery delays, teams can present a case for hiring additional resources or rescoping projects.
Are you navigating the complexities of team management and resource allocation? Tune in to learn how to optimize your development processes and ensure your teams are set up for success.
Resources:
Follow/Subscribe Now:
Facebook | Instagram | LinkedIn
Episode Transcript:
[00:00:00] PreRoll: Creating great products isn't just about product managers and their day to day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes, and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you find your way.
[00:00:28] Think like a great product leader. This is the product thinking podcast. Here's your host, Melissa Perri.
[00:00:37] Melissa Perri: Hello and welcome to another episode of the Product Thinking Podcast. It's time for this week's. Dear Melissa, every Friday I answer all of your product management questions right here on the podcast. If you have a question for me, go to dear melissa.com and let me know what it is. This week's question is all about how do we navigate multiple product managers accessing the same development team?
[00:00:59] I think it's an interesting one, a very big problem I've seen in smaller companies. Let's dive in.
[00:01:05] Your dev team is shipping faster than ever, but your tools, they're still stuck in 2012. Monday dot com's dev platform changes that With Monday Dev, you get fully customizable workflows, real-time visibility across your development lifecycle, and seamless GitHub integration without admin bottlenecks slowing you down.
[00:01:21] Whether you're working in the platform or straight from your IDE Monday Dev keeps your teams aligned, focused, and moving fast with AI powered context builtin. Go to monday.com/dev and see how your team can build without limits.
[00:01:34] Dear Melissa, do you have any advice for a situation where there are multiple product managers accessing the same developer team? We each have our own focus, but are expected to share a developer team of seven. From sprint to sprint, they rotate between our three areas. Is this common? My thinking is that the lack of consistency will slow down delivery. Many thanks in advance.
[00:01:53] This setup is unfortunately more common than it should be, especially in these smaller companies or during rapid growth phases. So sometimes we've got all of these things we know we need to be working on, but we haven't hired enough developers to actually work on it.
[00:02:06] You are absolutely right to be concerned. Your instinct about delivery slowdown. Completely spot on. And this isn't just a product management problem, it's an organizational efficiency problem that's going to affect everyone. 'cause what's going to happen is that work's gonna get delayed. You're not gonna have it out for customers and this is going to make it look like you can't deliver.
[00:02:26] So what happens there? A lot of times people come back and blame the product manager because you're seen as owning that work. In this case though, it is a classic case of context switching, and that is what is dragging us down. So context switching is one of the biggest productivity killers for anybody, and especially for development teams.
[00:02:44] So every time a developer rotates between these different areas, they're essentially rebooting or re-understanding the domain, the code base, the requirements. They're going into different parts of code, they have to get back up to speed on it. Maybe somebody added a whole feature over there and now they have to go learn what that feature is about.
[00:03:00] This is going to make them start and stop so much that you're losing all of this time to context switching. So again, yes, is making you slow down. It's not just about the technical context too. We have to make sure that it's like the product context, right? Developers have to understand the product context.
[00:03:18] They have to understand the users, they have to understand strategic reasoning, it's behind things so they can go out and make decisions. In the moment when they're coding. You don't wanna make it so that a developer comes back to you and asks you every tiny little nitty gritty thing because they don't have wider context.
[00:03:34] So making the context this huge makes it really hard. Think of it as asking a writer to like switch between writing a romance novel and then a technical manual, and then a legal brief every like few weeks. That cognitive load is just really enormous. We've seen in research as well that it could take 15 to 25 minutes to fully refocus after switching tasks.
[00:03:55] So then think about that with development work, it could take hours or even days to get back up to speed on a different domain. So you're probably losing like 20 to 30% of your team's productivity on just overhead here. This is where quality will start to suffer too, because there's no ownership over the different areas.
[00:04:13] And when you lack that ownership, you're not really looking at, can I make this better? Can I make this more streamlined? Can I make it simpler? Can I fix these bugs? There's more miscommunication too. So what happens when you have a team of seven and you've got three product managers? You ideally want dedicated teams focused on these specific areas for extended periods.
[00:04:32] Now you've got this team of seven. But that doesn't mean that specific developers can't be dedicated to your different areas. And this is why where a great engineering leader really comes in, right? So what an engineering leader should be doing is looking at the team and saying, Hey, I'm gonna have these two people right over here.
[00:04:53] Focused on this work because it requires this much effort. They're really good at these areas. They can get up to speed. Maybe their skills are a little more front end, let's say, and it's a front end thing. These two developers over here might be working on this.
[00:05:04] And they're proportionately supposed to be looking at how much effort it's gonna be, how strategically important these different areas are because not everything is created equal. I'm sure out of the three PMs that you have in your company, some are working on it, super critical stuff. Some might be slightly less critical. That's what a great engineering leader should be looking at is how do I distribute the team appropriately that way?
[00:05:26] And that's okay. Even if you have two people fully dedicated, maybe there's something where like somebody floats, I don't know. To spike on something that's gonna be way better than somebody, everybody's switching everything all the time, right? You don't want that. You don't want that. So with the clear ownership, it creates accountability and makes sure that they have deeper product thinking.
[00:05:47] There. They'll be able to make decisions on their own a lot better. So that'll free your time up there. All of those things are gonna make you go a lot faster. It's gonna be a lot smoother. So even with just seven engineers, you can probably work this out. Now I wanna say this as well. You've got three product managers and seven engineers.
[00:06:06] First of all, like a bigger issue here is that ratio is just way off, right? That is not a typical ratio. We typically would see one product manager to every, I'd say five to seven engineers. Sometimes I see nine. Those, we would typically split out into two teams, but they would be highly related to one more complex project or area.
[00:06:29] That's highly related. So maybe you have one product manager over those two teams, but typically they're gonna be working like that. Three to seven is like that's an insane ratio. That's just, you have way too many product managers for the amount of developers you have. You should be, if you have that much work that the product managers could be working on, you should hire more developers.
[00:06:49] In the absence of that, you should be splitting out the developers so that we have ownership there. So I would take that back. There is literature out there about the good ratio of product managers to developers. I would take that back to leadership too. If you want all of these things done, we really need more people to be able to work on it.
[00:07:06] That's a great way to put it too.
[00:07:08] PMs make great investors. If you're a product leader, curious about angel investing, check out Angel Squad. It's where over 2000 operators from Google, Meta and Apple learn to invest in high growth startups alongside Hustle Fund. I've been a member for years and highly recommend it. They've given me a few 30 day guest passes to share
[00:07:25] so head over to go.angelsquad.co/melissa and make sure to act fast as the passes are limited.
[00:07:32] You can do all of this with your development lead as well. I have worked with companies where we have tracked out. How much time things wait in queues or how much time we lose to context switching as well. And we've gone back to management and we've shown it to them and we tell like a CEO of a startup, like you need at least five more people if you wanna accomplish these things on your list.
[00:07:51] Otherwise we have to draw a line, right? And I need them to be dedicated to one thing, or I need them split to these two things. But you can't have 'em all. That's where you push back and that's where you have to use your product management sense and your negotiation tactics and your influence there to get them to see that not all of this can be accomplished with the size team that you have.
[00:08:10] So I would really heavily lean on your development lead. I'm sure they're not happy about you context switching like crazy. And I'm not saying too that your developers have to be completely dedicated to certain areas for the rest of their lives but at least a year. That would be good, right? They might rotate a little bit on things that are adjacent, but usually you want teams around certain areas for at least a year to make meaningful progress.
[00:08:33] In a startup, maybe it's a couple months to six months quarter that they'd be working on those areas, but you want 'em to be able to go deep, right? Without that, you're gonna lose a lot of things to waste, right? That's the cost of handoffs, transitions, getting back up to speed, and if you are in a small company, you cannot afford that.
[00:08:53] Startups win on speed, right? That's what we're doing. So track that cycle time, track your bug rates, track your delivery delays, start measuring the real cost of how you're operating right now. Your development leads should be able to help you with that. Document as well how long it takes the teams to get productive every time they switch.
[00:09:10] Ask your developers if they even like it, have a conversation with them about this, right? Look at velocity differences, like if you have an area where you know people are focused versus where they're switching, you can use that as well, but recruit these developers to work with you, to build this case for the leadership team to say, Hey, this is not how we should be working.
[00:09:30] We either need to hire or we need to re-scope down. And it sounds like if you have two other product managers, you've got a lot of stuff in the pipeline. It sounds like it's time to hire. It sounds like it's time to bring more people in there, but present these options to leadership so that they can make the informed choice.
[00:09:46] Present the trade offs, present all of this stuff so that you can get the buy-in that you need. Because you are correct, this context switching is definitely slowing you down. So I hope that helps. And again, if people are listening to this and you say, Hey, I got a question I would love Melissa to answer, go to dearmelissa.com.
[00:10:02] Let me know what it is. We will be back next Wednesday with another amazing guest on the Product Thinking Podcast. Make sure that you like and subscribe to this podcast so you never miss an episode. We will see you next time.