Why Constant Switching Destroys Team Productivity

In this episode of "Good Intentions, Bad Outcomes," Gino Marckx and Wayne Hetherington expose the hidden costs of constantly shifting priorities before completing work. Discover why this well-intentioned practice secretly destroys team productivity and morale, and learn practical strategies to break the cycle of never finishing work.

Learn why two-thirds of work often sits permanently "in progress," how constant switching creates codebase complexity, and the devastating impact on team motivation. Perfect for product managers, team leads, executives, and anyone struggling with the "shiny new feature" syndrome that prevents teams from delivering real value.

SUBSCRIBE for new episodes that reveal the workplace practices secretly sabotaging your success!

Contact us at feedback@goodintentionsbadoutcomes.org

Chapters

• 0:00 Introduction
• 0:36 The changing focus problem
• 1:06 Why organizations constantly shift priorities
• 2:15 Consequences of stopping work in progress
• 3:00 The growing backlog challenge
• 3:40 Code complexity consequences
• 4:24 Psychological impact on teams and management
• 5:19 Impact on client relationships
• 6:23 Strategies to solve the changing focus problem
• 6:37 Setting and respecting WIP limits
• 7:59 Replacing items instead of adding them
• 9:25 Salvaging partial value from in-progress work
• 11:06 Reducing work item size
• 12:22 Creating a culture that can say "no"
• 12:56 Summary: Stop starting, start finishing

Transcript

0:01

Welcome to Good Intentions, Bad Outcomes, the podcast about challenges and practices you might encounter in the workplace, where good intentions have unintended and often unnoticed consequences.

I am Gino.

0:14

And I'm Wayne.

0:16

Every episode, we share a situation that we or one of our listeners have seen in the workplace that is challenging in some way. We discuss the what and the why, and we try to come up with alternatives on the spot.

0:28

So, let's get started.

0:30

Today's topic is going to be about changing focus. An organization is delivering certain products and is focusing on certain features, but suddenly realizes that other features might be more meaningful for their clients, and they shift focus.

0:48

That means that all the work that was actually in progress stops, and new work is started.

0:56

So Wayne, tell me a little bit about what you see there.

1:00

Yeah, I've seen this happen a lot in almost every company I've ever been in. I think it's a result of good intentions on the part of the company. Maybe one way that it manifests is when a customer asks for a feature or somebody comes in with a good idea and everybody rallies around it.

1:26

They think it's great, so they want to give this new feature a try. It gets written up and put into the backlog, and then people start working on it because they're excited about this new idea.

1:37

Yeah, and that's one reason. I've seen other reasons as well, just because it takes too long for certain features to reach the market, and they say, "OK, let's focus on something that is meaningful that we can deliver sooner and that our customers will benefit from."

1:58

But it doesn't really matter what drives the change. What I really want to call out is the challenges that are created as a result of having all that work that was in progress be stopped, sitting there for I don't know how long, and new work being added to the list.

2:18

So, what are the consequences of this approach?

2:24

Well, you always end up with a growing list of things that need to be done. Unfortunately, if you haven't finished anything on your list, it doesn't disappear. You just get this growing list. It gets bigger and bigger with more things to do, and you end up not really finishing any of them, which is a big problem.

2:48

Yeah, and I want to call out some of the real challenges that are associated with this. I've seen, for instance, a situation where about two-thirds of all the functionality that this initiative was supposed to deliver over time—two-thirds was in progress, consistently—and the team just had a challenge to deliver any of it.

3:16

All the time, the executives were focusing on something new, because it's like, "Yeah, I mean, this doesn't work. OK, let's try something new. Well, this doesn't work, let's try something new," and it kept on adding more work in progress.

3:27

The challenges that I saw there: first, the code base became very complex. There's an awful lot of stuff that was in there, and you can manage that complexity in several ways. One is by hiding them in branches, but depending on how long it takes before those branches get integrated, that will add to the complexity of integrating them.

3:49

That is costly as well. It's quite expensive, right? And it's prone to introducing additional problems and mistakes.

3:58

So that's one challenge. Another challenge was that because the people on the team were consistently changing the focus, they kind of were losing momentum and they were losing motivation related to the product itself.

4:13

Do you see some other consequences of this, Wayne?

4:18

Yeah, I was thinking of two things similar to what you were talking about there—the psychological effects of having all of these things to do. There's a complexity factor where a team may feel overburdened with many, many things to worry about and look at, and they just get depressed because of it.

4:38

Also related to that is the fact that they can't seem to finish anything. You don't get completion or closure on anything, and that's distressing. And then perhaps another psychological factor is from the management point of view—they get frustrated when nothing seems to be finished.

4:56

So there's all this tension that builds when you have too much work in progress.

5:01

Right, and it feels after a while that the management is losing faith and losing trust in their team to be able to deliver anything at all. And then we haven't even talked about the clients yet, right? Because they are waiting for that functionality to be released too.

5:18

So all good intentions—you want to focus on things that are easy to deliver—but all the other stuff that is not delivered yet remains somewhere in progress, and it's just impeding delivery and fast delivery in the future as well.

5:38

So lots of consequences.

5:40

OK, we've kind of talked about where that comes from. It's good intentions indeed, as you mentioned. We want to focus on things that we can deliver fast. Also, it's the result, of course, of work that is too big, right?

5:56

Features that are too big that we want to tackle in the first place—things that are features that take too long to deliver. As a result, they are not done or not done to a degree that parts of it can be delivered and be beneficial to the clients.

6:14

So all of these things kind of play a role. But what are some of the strategies that we can apply to do something about this? Let's say you're ending up in a situation where two-thirds of the functionality is in progress.

6:31

Well, I think the first thing that comes to mind is setting a WIP limit. So, from the world of Kanban, if you realize that you've got too many things in progress, then you want to actively start counting them and then try to reduce the number of things in progress—consciously reduce that by setting a limit for yourself of how many things you're going to work on at the same time.

6:54

And just be consciously aware of that and force yourself to say no to something. That is a way to control how much is happening. That would be my first recommendation.

7:07

I want to add something to that, just for our listeners and to ensure this is really well understood. A WIP limit does not mean that we're actively working on only a few things, right?

7:18

When you, let's say that you have a WIP limit of three, and there are three things in progress right now, if you park one to the side and not work on it, but keep it in an unfinished state, and then start a fourth thing, that is not satisfying your WIP limit. That is not complying with this.

7:38

You need to drop it altogether or finish something before you start something new, right? So don't make that mistake. WIP limit does not talk about the active things. It talks about everything that is in progress, right?

7:53

If you're stopping it now, stop it entirely. Throw it away. Don't allow it to add complexity to the code base that you already have for the product that you already have in its unfinished state.

8:06

So that's one. Adding a WIP limit. What else would you advise, Wayne?

8:15

Well, you alluded to it in your previous comment there—that another strategy may be to replace a new item for an old item. I've seen this happen in a sprint sometimes. An emergency will come along. We need to do some kind of work.

8:32

So instead of just adding it into the sprint and doubling up your points or your stories that you're working on, you actually actively drop one. You take one out to put the new one in.

8:44

You're saying no to a piece of existing work. You're going to park that and not worry about it. Similar to what you're saying there about stopping the work, you're going to have to stop that. Let it go. Don't worry about it because you've got a higher priority.

9:02

Yeah, I see this as a variation of maintaining WIP limits as well. There are a couple of others that I want to call out.

9:10

One is looking at the things that are in progress and figuring out, "OK, hang on. Is there something that we can salvage? Is there something here where we could say, 'You know what, that entire feature is not complete, but we kind of can close it off in a place where we end up in a place that is meaningful, that is valuable for our end users, and that we can completely finish as a result'?"

9:40

Is it entirely the way that we would like it to be? Do we have a couple of features that we can't edit, or we can't delete that are not available? Well, sure, but at least it's in a place, and we can then cut this other piece of functionality—like the deletion or the editing of certain fields—as new functionality that we can deliver later.

10:05

So what we have, we can finish up in a good way, so more space becomes available, and all of these things are not suddenly in production. That doesn't always work, but I believe that with a little bit of creativity, we can oftentimes find value in parts of the features that are in progress that we can deliver in a way that makes sense for our clients and for our teams as well.

10:32

And again, it adds to the motivation and all that kind of stuff.

10:38

So basically what you're saying is you can stop the never-ending feature by deciding how much is good enough.

10:47

Right, that's a way to look at it, yeah.

10:54

Well, which reminds me of one of your earlier statements there about stopping work. It's much easier to stop smaller pieces of work, and it's much easier for smaller pieces of work to flow quickly.

11:07

So maybe one more solution to the work in progress problem is to try to reduce the size of the pieces of work that you're working on so that any one piece is small and quick and fast, and you can finish it before you move on to the next one.

11:25

Yeah, absolutely. I think that's a great strategy. It takes some experience, it takes some practice to make it all happen. But I've seen teams that are very successful not allowing work that is exceeding a certain size or would require them too long to deliver—not allowing that into the sprint or into their work stream at all.

11:48

They require things to be cut down into pieces that are maximum two weeks or maximum one week of work. So it's always easier to just let that go or indeed completely finish it, right, if it indeed is still the most valuable piece.

12:06

Can you think of anything else, Wayne? I'm thinking in the back of my mind as well, maybe one more.

12:16

I think you need a culture in your organization in which you can prioritize and are free to say no to lower priority things. I think sometimes just because somebody asked for it means we have to do it and we can't say no, but if it's a really low priority thing, it should wait. It's probably not that important to worry about.

12:43

That's right. To summarize this all, I think we can conclude this. Those are a couple of good suggestions.

12:53

To summarize this all, we have, with Xodiac, we have the deck of culture nudges, and this one is exactly the right one that you need to address this particular topic: stop starting and start finishing your work.

13:07

So that's it for today. I hope that you enjoyed the conversation. I certainly did. If you have a situation at work—in the past or right now—that you feel has unintended bad outcomes, let us know, and we might discuss it in one of our future sessions.

13:22

Thank you, Wayne.

13:26

Bye bye.

13:27

Thank you, Gino.