How to build silos and decrease collaboration (on purpose)
“We need to break down silos between departments and get people to collaborate better” — almost every leader everywhere.
Most leaders reflexively think of silos as BAD and collaboration as GOOD. This manifesto defends silos and challenges the value of collaboration.
Increasing collaboration can do harm
In general, you should aim to maximize collaboration within teams, and minimize collaboration between teams.
Why maximize collaboration within teams?
A collaborative team works together on one or two goals. This maximizes shared state — everyone has a common understanding of goals, progress, and who is doing what. This gives team members a better ability to focus and coordinate their work with each other. Team members have overlapping areas of knowledge, so they can critique each other’s work and help each other grow. They are more innovative, because the interplay between people as they work on the same goal helps generate more diverse thinking and improve decision-making. When someone leaves the team, the fact that others have a shared understanding of the work means the team can survive and continue to work effectively. People can go on vacation or leave without as much disruption. And collaborative teams feel great to be a part of — everyone shares the same victories and accomplishments together. A team that doesn’t collaborate often really isn’t a team at all.
Why minimize collaboration between teams?
To the maximum extent possible, teams should have what they need to succeed within the borders of their team. And where that is not true, you need some structure to ensure the team can get what it needs in a way that will scale with the organization’s growth.
As companies grow, communication and dependencies proliferate. Companies start out with many-to-many communication. As they grow, the communication patterns within the company must necessarily switch to being segmented and defined. Otherwise, the communication burden on teams will grow at an exponential rate, and the increasing complexity will degrade the effectiveness of the company.
I observed an example of this at New Relic. As the engineering organization grew, we encouraged a collaborative culture and rewarded people for collaboration between teams (it was even part of our promotion criteria — you can blame that on me!). After a few years, the increasing number of teams made it more and more difficult to manage dependencies between teams, to the point that it eventually became impossible to accomplish any large project within the organization. I know, because I was one of the “best project managers”, so I got put on many of those large projects — and they were systematically impossible to execute on. We all tried heroically to make it work, but the system was rigged — there wasn’t a way to accomplish these larger projects. The solution to this was to eventually define the interaction models between teams, reduce dependencies, and add some structure to prioritization and communication. Looking back in retrospect, it was as obvious as math what happened, but I see organizations fall into this trap over and over. We’ll talk more about how to structure these solutions in the second blog post in this series.
Collaboration sounds great, but it’s something you want to actively be combating between teams. A little collaboration is fine, but excessive collaboration between teams is a sign your organization isn’t structured well. If you ever wonder why Bezos took such a hard line on his API mandate in 2002, this probably factored into it. Bezos structured Amazon so that teams were as independent as possible.
What are silos?
Silos are boundaries between groups of people, based on the organizational structure and teams they’re working on.
Why do silos exist?
Silos exist because humans have cognitive and communication limits:
- Humans can only handle a certain number of relationships
- Humans have a limit to how much communication they can handle.
- Humans are pre-wired to think in terms of teams and tribes. We work better in small groups.
- Humans have cognitive limits on the amount they can focus on.
It’s important to recognize that these limits are real limits, and not something you can wish away. Every company in the world (above a certain size) operates in teams that specialize. We organize into teams and have org structures generally because that is what human beings need to work in larger groups.
There are ways to flex certain aspects of this. For example, a company that is designed to be fully asynchronous can rely on process and tooling to change some of these constraints. But even then, you’re moving the constraints around, not eliminating them completely. You need to operate in a way that recognizes these limits.
Why do leaders want to break down silos?
Leaders start talking about breaking down silos when they see that individual parts of the company aren’t achieving larger business outcomes and are excessively focused on their own area. Alternatively, they talk about breaking down silos when parts of the company aren’t well coordinated with each other. Generally this happens once the organization has become complex enough that the structure is getting in the way.
Here are a couple of examples:
- Marketing is planning a major announcement of an upcoming launch, but can’t get a timing commitment from the product and engineering teams.
- Two teams in engineering are building the same service, but in slightly different ways.
Leaders see these things, and start blathering about “breaking down silos” and “increasing collaboration”. What’s wrong with that?
“Breaking down silos” represents incomplete thinking
“Breaking down silos” is an exhortation rather than a diagnosis or prescription of how to improve the situation. “Breaking down silos” blames individuals for not having a big enough vision and working across boundaries, instead of looking with curiosity at the system and asking why they are doing what they’re doing. It’s expecting people to have your level of perspective without figuring out why they don’t.
But the main problem is that it isn’t specific enough.
Communication != Collaboration != Coordination
When you hear someone say they want teams to collaborate more or break down silos, encourage them to look at the problem from three perspectives:
Coordination
Usually when people talk about collaboration, what they’re really looking for is better coordination.
Coordination is “the harmonious functioning of parts for effective results” (Merriam-Webster)
The US military found that the best way to coordinate groups of people quickly and effectively was to centralize coordination and decentralize decision-making and execution. This is still the state of the art for organizational design. You want local groups to be able to act independently and have what they need to be successful. You want centralized functions to set high level objectives and coordinate where necessary to produce the right outcomes.
We’ll talk in the second post in this series about a multitude of ways you can coordinate groups of people working together.
Communication
Communication is transferring information from one person or group to another.
When people talk about needing increased collaboration, you can often achieve this more effectively by looking at the flow of information between people, and redesigning it. Typically, you can do something like this:
- Ask people how they are getting information today.
- Find out what information people actually need.
- Design the lightest weight version of this you can imagine.
- Try it out
- Get feedback and act on that feedback.
One thing I’ve done over and over in many startups is set up weekly communication on projects in engineering. This helps the marketing organization understand how to coordinate their work with engineering, among other benefits.
Collaboration
Collaboration is when people work together to produce an outcome. When teams are collaborating, it means they’re working with other teams to achieve outcomes together. That’s often a sign the team isn’t set up well. Ideally, it should have what it needs to do what it needs without dependencies on other teams.
A team that has to collaborate to achieve its objectives is going to be less reliably successful. In general, teams shouldn’t be collaborating with more than a couple of teams, unless they’re explicitly set up to be that way. For example, in some organizations you might set up the design team as a “service” organization which provides design for a larger organization. For teams that are set up that way, it can be fine, but it usually should be very carefully thought through. What is the interaction model for the team, and how will it deal with the inevitable fact that there will be excess demands on it? We’ll cover some of these patterns and their tradeoffs in the second post in this series.
Of course, the world is messy, and you shouldn’t expect a complete lack of collaboration between teams. But when you see teams collaborate, that’s something to pay attention to.
Technical analogy
You might think of silos as “encapsulation”. Leaders want to dig into the internals of the classes holding the logic they need. But it’s a bad solution to just bolt that on — you really need to refactor things so that they are better structured.
How do you get teams to coordinate better?
In the next post in this series, I share concrete patterns that help teams and departments work across organizational boundaries.
What do you think?
I always appreciate hearing your thoughts and reactions to my posts.
You can subscribe to future blog posts, or contact me, at https://www.rubick.com
Thank you
Thank you to the many people who helped improve this post. Rebecca Campbell always makes my work better. She helped me tighten up many of my arguments and helped me realize that I needed to make the section on coordination more explicit. Brent Miller, always the purveyer of astute observations, offered structural feedback that made the post much stronger. Chris Haupt, always thoughtful, pointed out a few areas that he didn’t find convincing, and helped me see that I needed to go deeper on information flow. Aaron Erickson suggested the metaphor of encapsulation. Thanks to Neville Kuyt for suggesting I define silo. And additional thank you to Robert DiFalco and Darin Swanson for reviewing and commenting on the post. Always appreciate your insight!
Top comments (0)