🚨 SPINNING WHEELS: The Hidden Cost of Working on Multiple Teams

Is your organization spreading people too thin across multiple teams? In this revealing episode, Hino and Wayne expose how the well-intentioned practice of assigning people to multiple teams is DESTROYING productivity and team ownership! 😱

🔥 You'll discover:

• Why your team members are stuck in ENDLESS standups with nothing to report
• The shocking productivity loss from constant context switching between teams
• How assigning scarce resources across multiple teams actually REINFORCES knowledge silos
• The real reason your "resource optimization" is causing project delays
• Why team members assigned to multiple projects feel like "fifth wheels" instead of valued contributors

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

Contact us at feedback@goodintentionsbadoutcomes.org

Transcript

[0:03-0:15] Welcome to Good Intentions, Bad Outcomes, a podcast about challenges and practices you might encounter in the workplace, where good intentions have unintended and often unnoticed consequences.

[0:15-0:17] I am Gino.

[0:17-0:20] And I'm Wayne.

[0:20-0:36] Welcome, Wayne, and every time we share a situation where we or one of our listeners have seen in the workplace that is challenging in some way. We discussed the what and the why, and we try to come up with alternatives on the spot.

[0:36-0:38] Let's get started.

[0:38-0:56] So today, Wayne, we're going to talk about a situation where people are assigned to multiple teams and, oftentimes in those kinds of environments, these people then need to work in different meetings all the time, right? So have you seen those situations?

[0:56-1:04] Yeah, you know, I was thinking about this, you know, and I, yeah, I have seen this before.

[1:04-1:18] I think it's a structure issue and it fits in well with our portfolio design, blog series that we're talking about right now where companies and people end up spinning their wheels because of inefficient structures.

[1:18-1:32] So, yeah, here we have a person or maybe it's multiple people who are asked to work on multiple different teams at the same time. And it seems like a good idea, but it often has a bad outcome.

[1:32-1:38] It does, it does. I've seen it a couple of times as well, more than a couple really.

[1:38-1:55] Oftentimes really it's not necessarily, it definitely isn't with bad intentions. People do not intentionally spread other people's time thin, but I've seen situations in which it's so bad where individuals were in standups like...

[1:55-2:14] 3 hours of the day, several standups took longer as well already than the 15 minutes that they're kind of trying to be limited to, and people barely had any time left to do the work that they really needed to do, and then the day afterwards was the same kind of game, right?

[2:14-2:21] So, running from one stand up to another with nothing to report, and nothing to discuss, nothing to collaborate on.

[2:21-2:27] So, where does that come from, Wayne? What is your take on this?

[2:27-2:37] Well, I was thinking about it because I had a conversation. I saw the same thing happening in one organization I was at for a while, and, so I, we had that discussion.

[2:37-2:48] Why is this person being asked to be at so many different meetings with so many different teams? And it came down to this structure issue and I think it boils down to two possible problems that we're trying to solve for...

[2:48-3:03] It's one when there's a person who has a particular skill and, you know, maybe it's he's the main architect or something like that and his skill is required across multiple teams.

[3:03-3:14] And so instead of hiring many highly skilled architects, they just have the one person servicing many teams, which seems like a good idea, right? It's a good intention to make use of that skill.

[3:14-3:25] The other problem that I've seen is, on the other side of it is a demand. So for instance, like a DBA, we might have a lady who's a DBA on the team.

[3:25-3:40] The team really doesn't need a DBA full time on every single sprint every single day, so they just call her in when they, they need her. So it's a demand thing. We don't need an expert all the time, so we'll just, we'll just take them when we need them.

[3:40-3:55] So two structure problems I think give rise to this, this, solution, which is intended to do good.

[3:55-4:00] Yeah, have you seen... I've definitely seen similar things.

[4:00-4:10] I can add a few as well. So the first one you called out was really a skill scarcity, of a certain skill. Skill is to be interpreted broad, I'm assuming as well, right?

[4:10-4:21] It's not just, do you have any technical skills, do you have any particular, but also particular knowledge or domain, right? So, hey, this person has been involved in in building application A to Z.

[4:21-4:38] So now they need to be involved in almost every single, every single one of those meetings, because they're the only ones who really understand how things work and they have recognized in the past that if that person is not available or does not participate in those meetings, that decisions are made that need to be reverted afterwards.

[4:38-4:46] So the intent is good. I mean, people try to include the ones who have the information and prevent a rework or decision making that does not take all the context that is available into account.

[4:46-5:02] So that intent is definitely, is definitely there. The other one where indeed, you don't need all the skills or all the time that is available of this person, and as a result, you're saying like, OK, we're going to assign this person 20% to this team or squad and then 40% to another one.

[5:02-5:30] I've seen it go so bad that people were assigned 5% of the time. And I thought, how is this even possible? I mean, you're spending 5%. What does that even amount to during the week? How much time is that? What can you really get done? By the time that you've done your context switching, you already, your 5% is already used, right?

[5:30-5:48] So there's definitely a couple of challenges with this. So, there's a few other ones that I see as well, and that is, just a simple necessity to build squads, to build teams, because there are requests and there is this belief that, hey, if we need to satisfy this particular request, we need to build a new team around this.

[5:48-6:09] And we can't just go to the market and hire new folks. So we just take a little bit of time of each and every one that we know that will contribute to this team and build a new team. That's only 10% extra on these people's time. That should be possible.

[6:09-6:21] So that's a third one that I see. It's just the necessity of bringing new work in and then it's also a combination of the two, of course, right? With specific skills, and we don't need them full time. So that's added too.

[6:21-6:42] I think those are definitely reasons that caused this problem. Yeah, and I can see there's some good intentions here too. So like you're saying, you know, we've got a piece of work, we're going to bring people to the work.

[6:42-7:02] So work needs to be done and we are, you know, intending well enough to get that piece of work done and bring the right people to it. So it's a good intention. There's also the idea that you don't want a person who may not be needed all the time to sit there idle, waiting when they're not needed.

[7:02-7:15] So if we put them fully dedicated on a team and they're only needed for half the time, what are they going to do with the other half of the time? Is a person gonna get bored? You know, so it is a good intention, you know, to keep them busy.

[7:15-7:26] There's also the idea maybe of avoiding cost. We can't hire a dedicated DBA for every single team. It's just going to cost too much. So it's a good intention to try to, you know, spread out the cost, reduce the cost of running things.

[7:26-7:48] So, these are good intentions, but I think they might result in some bad outcomes. I don't think that any business leader is making decisions and knowingly that are bad, right? So they always, they always come from some good place.

[7:48-8:04] Now, what is the downside of assigning people to multiple squads? Can you call out a few, Wayne?

[8:04-8:13] Yeah, well, let me see. I think the first one you've kind of touched on already is where you have a person who kind of rotates around through teams and they've got fractional assignments to each team, maybe 5 or 10% to multiple teams.

[8:13-8:27] It sounds like a good idea, but the bad outcome is now that they are split across multiple teams and so the very first thing that you noticed there was the person is expected to participate in the meetings of all of those teams.

[8:27-8:42] And so I saw the same thing. One UX designer spent all morning long just going to stand-up meetings, which should have been 15 minutes, but we're more like about 30 by the time they were done, and they had 5 of them to go to.

[8:42-8:56] So by lunchtime he was just finishing the stand up and That was it. He had, you know, half his days gone already. And he was very, very frustrated at that.

[8:56-9:00] Yeah. And so there's other things as well, right?

[9:00-9:19] So the context switching, we kind of touched on that as well, every single time that you, you go from one, let me call them projects because those environments typically work around projects. You go from one project context to another project context before we even get into the meeting, you're going to, you're going to have to empty your mind with the things that you talked about the last 15 minutes to half an hour, and I need to load that context, if you will, to, yeah, to, to fully participate and to actually know what this meeting is going to be about.

[9:19-9:43] So that takes time and that takes productivity away. So that's a big big hit as well that the team is taking. There are some other things too though, and that is that, people really do not feel, as part of a team.

[9:43-10:00] There's less sense of ownership. There's more like, yeah, should I say the word, they feels more like they're treated as resources, right, and not so much as as a valuable parts of the team, even though that sounds counterintuitive to what you said earlier...

[10:00-10:17] One of the reasons why this, this problem really occurs, and that is that their skills are really wanted and needed on the squad. Yet because of the way that they work, they, they almost like feel like, like 1/5 wheel, if you will, right?

[10:17-10:27] Not, not really, fully participating and, and as a result, owning the outcomes. Do you see any other results?

[10:27-10:40] There was one more I was thinking of, and it kind of flips it around instead of from the viewpoint of the person who's being asked to attend multiple teams. It's from the team's perspective.

[10:40-10:58] So this is where we have the, you know, trying to keep somebody busy because they're an expert. We don't need them right now, but we'll need them later. So they can go do something else. Well, we don't need them, and then we'll call them in.

[10:58-11:09] So the team now has a need. They call somebody in, but that person that they need is off on a different team doing their thing. Because they're needed over there and it's, it's a great big scheduling conflict that happens.

[11:09-11:24] And now we've got this shared resource that has to do multiple things and we got to wait. It ends up jamming up everybody's work and work slows down.

[11:24-11:27] Yeah, absolutely. So you have those dependencies.

[11:27-11:34] I want to build on top of the the lack of ownership as well, because I've seen this explicitly play out in Teams too...

[11:34-11:51] That people and contributors to teams in that way, when they don't fully participate when they're part of multiple teams, there's simply no motivation to improve, because they know like, well, I mean, I'm gonna be out of this team in two months anyways and I'm start on something else.

[11:51-12:05] There's no incentive for me to improve, to put the effort in to look at what doesn't work. Let's just, power through this and make sure that we get it, out of the way so that we can move on with something else.

[12:05-12:11] So that's yet an additional thing. There's so many downsides. So we can probably continue going on the downsides.

[12:11-12:19] But I wanna offer some pieces of advice as well to our listeners, of what to do instead, right?

[12:19-12:31] Let me actually call out one more downside to by having this system of pulling people in because that knowledge is scarce.

[12:31-12:39] By continuing to do this, you're building a habit to prevent other people from picking up those skills.

[12:39-12:49] And you're actually cementing this scarcity of that knowledge of that skill, you're cementing it into fabric.

[12:49-12:53] Well, cementing and fabric maybe don't go together, but you get what I mean.

[12:53-13:00] You're gonna make sure that it, that it remains, right? That you're not resolving it in any way.

[13:00-13:03] You're reinforcing the silo.

[13:03-13:07] Reinforcing, that's the word that I was looking for. Always good to have you here to help me out.

[13:07-13:09] No problem.

[13:09-13:17] What are some of the things that we could do to solve this issue or at least address it to some degree?

[13:17-13:35] Well, you know, the original problems are still good problems to solve and there may not be an excellent solution that solves all of them, but I thought, from the page of Team Topologies, there were two principles that might help, make a decision in these types of cases.

[13:35-13:41] One was to organize your teams for maximum flow.

[13:41-13:48] So that's the dependency problem. You're gonna want to make sure that work is flowing regardless of who's doing it.

[13:48-13:53] You wanna make sure that work is flowing. And then the other principle was to minimize the cognitive load.

[13:53-14:00] So this has a little bit about, you know, distributing the knowledge across teams being multi multifunctional, those types of things.

[14:00-14:09] So you want to make sure that no one person or no one team has to do too much stuff or remember too many things or be responsible for too many systems.

[14:09-14:13] You want to minimize the cognitive load, but maximize the flow of work.

[14:13-14:20] Yeah, so both of those principles really roll off your tongue, but I'm not so sure if every listener really understands what those things mean.

[14:20-14:26] Can you say this in a slightly different way, in a way that that a 5 year old would understand it?

[14:26-14:30] OK, so, yeah, good point. Thanks, Hino.

[14:30-14:48] So for instance, the first principle about maximizing flow, if we have one person who is doing a job for say 5 teams and all 5 teams need that person at the same time, there's contention for that person's time, then we are limiting the flow of work.

[14:48-14:51] Somebody's got to wait. So we're looking at wait times.

[14:51-15:05] Who's waiting for this person and why are they waiting, It may not be a bad idea to have that person work with multiple teams, but you're going to want to minimize the wait times there.

[15:05-15:11] So can you schedule better? Do we really need to have that person across multiple teams?

[15:11-15:20] Could they, for instance, start training some of the people on the team to do that job so they don't have to be there and the team can continue self-sufficient after they're gone.

[15:20-15:24] So things like that, right, will help the work flow along.

[15:24-15:46] Yeah, so what you're actually calling out is to turn the role or to change the role of a person who, whose knowledge or skills are scarce into more of a guiding role and not really being a member of those teams that would block progress or would stifle progress in those teams.

[15:46-16:05] So the teams can independently move forward, but the person is there for them to rely on to them for them to get support on and then actually having this person be a floating, yeah, wealth of information and support across the organization, across multiple teams.

[16:05-16:09] Yes, that's a big one, and that that really might help.

[16:09-16:19] Other ones also are if you have people on your teams, move the work to the teams instead of creating new teams around new work.

[16:19-16:26] So that's another big one. We can call out an awful lot more, but I see that we're actually hitting our time.

[16:26-16:37] So maybe you want to add a third one, Wayne, and then, or the last one, and then we can wrap it up for today because we have more episodes coming.

[16:37-16:48] Right, OK, so, yeah, one last suggestion, if you're attempted to have somebody work on multiple teams, just try to reduce that as much as possible.

[16:48-16:53] Maybe only have them work on two teams instead of 10 or 5.

[16:53-17:07] If you can't, if you absolutely can't embed them and have them fully dedicated per team, which is the optimum situations, but if you can't, you know, at least try to minimize that and, and then have them pass on their knowledge as as they go.

[17:07-17:09] Sounds great.

[17:09-17:12] So that's it for today, folks. I hope you enjoyed the conversation.

[17:12-17:28] If you have a situation at work, whether it's in the past or even now, that you feel has has some kind of fishy smell to it, that, that even though it's intended well, but it really doesn't work out, all out all that well, then just let us know.

[17:28-17:36] And we might discuss it in one of our future episodes. Thank you for listening and thank you, Wayne, for being here and see you next time.

[17:36] Thank you, Gino.