How Technical Silos Create Invisible Bottlenecks

In this episode, Gino Marckx and Wayne Hetherington explore why organizing teams around technical components creates dependencies that slow down your entire organization.

Discover:

• Why component teams introduce crippling dependencies
• How "islands of knowledge" become serious bottlenecks
• The hidden costs of teams protecting "their territory"
• Practical steps to break down silos without reorganizing everything
• Why self-service platforms and cross-team collaboration work

Perfect for technical leaders, project managers, and architects struggling with cross-team dependencies!

#ComponentTeams #OrganizationalDesign #TeamStructure #ConwaysLaw

Contact us at feedback@goodintentionsbadoutcomes.org

Chapters

• 0:00 Introduction
• 0:37 Component team organization pattern
• 1:25 Good intentions behind component teams
• 2:18 Conway's Law and organizational structure
• 3:46 Evolution from functional to component teams
• 4:27 The dependency problem
• 6:01 Knowledge isolation and bottlenecks
• 7:21 Priority conflicts between teams
• 8:39 Value stream teams as an alternative
• 9:11 Practical steps without reorganizing
• 10:06 Platform teams and self-service
• 10:35 Knowledge-sharing sessions
• 11:42 Visualization and planning
• 12:41 Leadership perspective
• 12:51 Feature-based planning

Transcript

0:00

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

0:14

I am Gino, and I'm Wayne.

0:17

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:29

So let's get started.

0:31

Today's topic is about a situation that we've seen quite often where organizations organize their teams around technical components. All of their teams are in charge of delivering a specific technical component, and all those components together will eventually make up the product and help their customers.

0:54

So Wayne, tell me what you see in that particular situation. What's going on there?

0:59

Well, it's an interesting way to organize a bigger project, and I think it maybe comes from the idea of a work breakdown structure or maybe an architecture breakdown of some sort. It seems like a good idea and has good intentions to assign groups of people to work on a piece of a larger thing.

1:19

If we divide up the bigger project by functional area, by technology, or sometimes by a system—a particular piece of software that we're working with, maybe it comes from a vendor—we set up a team to handle that particular thing. Then we think, well, we've enabled a team to work on a specific thing that they know well. They can build domain knowledge around it, they can build up technical skill with it, and they just worry about that one part.

1:54

It seems like a great idea, and when it's done right, it might actually work not too badly. But there are often some unintended consequences to that.

2:05

Before we get into those, I want to add a few other reasons why teams might end up being structured that way. One of them I see in large organizations is the fact that oftentimes products or large solutions span multiple departments within the organization. It's just the structure—the department structure—that is kind of mimicked in the way that it's going to be delivered.

2:31

In fact, it's Conway's Law altogether, right? Conway's Law is about how the structure of your organizations is reflected in your products and the services that you offer. And that indeed has consequences, as we'll talk about no doubt in a second.

2:48

For instance, there is a payment part of a solution. Well, that's the payment department that will take care of that. Sometimes it's related to all the pieces that you mentioned. It's a technology, it's a vendor product that they need to support, and all of the knowledge around how to deal with that vendor product is sitting together in that team. Nobody else needs to learn about this.

3:21

So it seems like a great idea, right? Put the people with the knowledge where they can contribute most, and the rest can then focus on the other work.

3:32

There's one other thing that I was thinking of too, and it's kind of a development—maybe an evolution—of the teams. I've seen a lot of companies that had functional teams: here's your team of developers over here, here's your team of testers over here, and they're separated out. Somebody wants to do something better, so what they do is they take a developer and a tester, put them together on a team, and then assign them to a component.

3:58

We'll talk maybe about functional teams and the pros and cons of those at some other time, but a component team could be seen as an evolution from functional teams. So it is a good idea in some cases, right?

4:14

Yeah.

4:15

So what are some of the consequences that you're seeing as a result of this setup, Wayne?

4:21

Well, I think probably the biggest immediately seen consequence is the fact that when we split something up across multiple teams, we're by design introducing dependencies between them. And I think that's probably the biggest thing.

4:37

You've got all these—you don't have a complete car until you have all the components of the car put together so you can drive it. If one of the components is a little bit slower or doesn't come through the line just at the right time, then you cannot have a fully functioning whole.

4:55

Same kind of thing with component teams. It's tricky to make them work together when there are dependencies between them.

5:02

Yeah, that's true. Those dependencies—I grew up in a place where not far away from us, there was a huge metal factory. Just because of how this place has organically grown, it's a big campus. It has different parts of the metal processing—the steel processing—in various places around the campus. There are actually train tracks and so on in between.

5:31

You can imagine all of this is organized in such a way that there's a limited amount of waste—as limited as possible in those circumstances. If any of those factories, if any of those buildings would no longer produce its output, then suddenly the entire system is slowing down. It's one of those dependencies as well that you're referring to, right? It's kind of the same situation.

5:57

I see some other consequences too. When you indeed completely isolate the knowledge related to a certain topic or a component into a certain team, and suddenly there is help required because that component needs more work, or we have figured out that this is indeed a bottleneck and we need to work through it, then nobody else has that knowledge. Nobody can do anything about it.

6:22

Every small detail that needs to change around this particular component is again put on the shoulders of that team that is already stretched thin, if you will, right? So that's definitely another consequence that I see.

6:38

You could call that a variation of dependencies—that's fair. But it is, I feel, still a very different kind of result, right? You're not only creating those dependencies, but you're creating significant bottlenecks and islands of knowledge.

7:02

So in addition to that, when you have that component team that has the island of knowledge, perhaps operating in a bit of a silo, then they tend to become protective of their component. And now we get into a priority issue, and I've seen this happen many times too.

7:21

We've got three or four people depending on this component. Each of them has things that are of priority to them, and they try to express those concerns to the component team. The component team says, "Well, your priorities are not my priorities. I don't really care about your priorities. I'm going to do whatever is best for my component first, and you're going to have to wait."

7:44

Even if that is not an issue, then that protectionism, if you will, might lead to additional processes as well that make it even slower for things to be updated, even if the priorities would be aligned across the organization.

8:01

OK, so what are some of the things that we can do to deal with that? What are some of the ways we can address those challenges?

8:12

Right. It would probably require a fairly big rethink of how your large projects are coordinated, but I kind of see the evolution from a functional team into a component team and then finally into a value stream team. So you're organizing your teams around the delivery of value regardless of what component they might be working on.

8:42

Right, yeah.

8:45

You might actually have a team that's delivering a stream of value that has to work with three or four components instead of just one at a time.

8:54

That's right. Eventually that's what you need to do, but I feel that there are a couple of smaller things that we can do that get us on the way.

9:05

Let's say that we are in a situation where we won't have time or the authority to overhaul the entire structure of the program delivery tomorrow, but what we can do is, for instance, say, "OK, hang on. If you are working with this other team or you have a dependency on this other team that needs to do something for you, you go and help them out."

9:28

You go and work with somebody on that team right now, either testing it or collaborating on defining an API between the two components, or actually just look over their shoulders so that you see what's going on. That way, you're building the capacity and the capability to, over time, make small changes by yourself, and you are trusted as well by the other team, right?

9:56

So that's definitely one thing that I see that you can do. If you take that idea and you crank it up to ten, I've seen some component teams become more like platform teams with a self-service mode of delivery. So they remove the dependency on themselves and place the responsibility back on whoever's using the component because now it's self-serve and it becomes super easy for almost anybody to use that component.

10:26

Yeah, there's definitely a good option there. I feel there are a couple of other ones as well, specifically related to brown bag sessions, essentially to deal with those dependencies. You kind of want some communication.

10:41

You might have brown bag sessions—this is typically what I call sessions that happen over lunch where people just share what they've done, how their component works, and every week it's somebody else. You bring your food, you bring your own lunch to the session, essentially. It gives an opportunity for people to share what they've built and to be proud of what they've built.

11:06

It gives an opportunity to teams to learn from one another and creates some consistency maybe as well—though consistency is oftentimes overrated.

11:18

All of those things—communication to shine some light on what those dependencies are and making sure that people build the right connections with other teams to be able to have the conversation when necessary—are good things to do.

11:36

I was just thinking, extending on that idea a little bit too, having good communication and good planning systems can sometimes alleviate the dependencies between those teams. I've seen planning boards with the "now, next, later" type of scheduling with swim lanes for each of the components.

11:57

Then as the work is being planned out, you know what we're going to work on immediately and what's going to wait for the next couple of months and then what can wait till the end of the year. As we plot these out, you can start to visualize the dependencies. Some boards even put red lines between the dependent components.

12:16

Then you can begin to adjust your scheduling based on priority and importance, and you might be able to reduce some of the wait times between the components as you communicate and plan out how you're going to work together.

12:29

Yeah, and then the next step is looking at, "OK, hang on, how can we now look at features throughout the entire system and determine which components or which teams would need to contribute to delivering that feature?" Look at the availability of the individual teams to actually say, "Are we ready as a larger program to take on this particular feature?"

12:56

Are the teams available, or is this team so busy with three other features before they can even start? Because if that is the case, we better look for a feature that does not require this team in order to be delivered, because otherwise, we're just going to add more work in progress and so on, right?

13:14

As soon as you have this visibility of what those dependencies are—which components would need to be adjusted in order to deliver a certain feature—you can start looking at the work in progress and the ability of the entire system to deliver the feature, not just that one component.

13:34

That's right. So you're raising everything to the same level. I think too, from a leader's perspective or a manager's perspective, if you're looking at your system of work and you've got your component teams and you can visualize them and you can see this component over here is really struggling because they've got huge demand and not enough capacity, I want to do something about that now.

13:54

I can help to alleviate that by adding some capacity. Maybe I want to hire another couple of developers, or maybe I want to add a second team because I can see that there's enough work there that the component team is swamped. So I'm going to alleviate that. I'm going to make the management decision to attack that constraint in the system.

14:14

Yeah. Maybe that's a topic for another time, but oftentimes adding capacity in exactly the way that you explain it—by hiring some additional folks—is definitely a good intention, but it doesn't always lead to the outcomes that you are hoping for.

14:32

But then again, this is for another time. I think we are at a good time to wrap this up, Wayne.

14:39

That's it for today, though. So I hope that you enjoyed the conversation. Wayne, thank you as always.

14:46

If you have a situation at work—or in the past, maybe it happened in the past—that you feel has unintended outcomes, let us know, and we might actually tackle it in one of our future sessions.

15:00

Thanks again, Wayne. See you next time.

15:02

Thanks, Gino. Bye.