Dividing up work is a natural and proven way to solve most problems faster. Specialization is also common, especially in areas that demand a range of skills too broad for anyone to master fully. Both of these approaches can be useful, but just like ammonia and bleach, if you aren’t careful to keep them separate, bad things can happen. I’m talking about the dreaded silo, the bane of engineering projects.
Just like their agricultural namesake, engineering silos seem innocent and efficient. They provide a way to organize the knowledge and expertise of your engineering team neatly on paper: Amy is the expert on X, Bill and Ted own everything about System Y. At first glance, silos seem to make ownership and responsibility simple and clear. But in my experience, they’re overwhelmingly negative, leading to slower, more fragmented projects and working against good team dynamics.
Two Types of Silos
When you think of engineering silos, you probably think of vertical ones: a single person or team owning an entire feature or subsystem. But unlike their farmland counterparts, engineering silos can extend horizontally as well as vertically. Have you ever worked on a project that had a strict division between backend and frontend developers, or a devops team that was totally divorced from the developers? Those are great examples of horizontal silos.
Why Silos are Bad For Your Team
Why am I so against silos? In my experience, they’re a poisonous idea. I’ve never seen any positive benefits from siloing knowledge. On the contrary, I’ve seen them cause a number of specific problems.
Silos bottleneck your team.
This is an obvious one. When one person holds all of the knowledge about a particular part of a project, then everything related to that part can be bottlenecked by that person. Even if you assume the best-case scenario–an individual who’s open to sharing what they know with the rest of the team–you have to deal with ramp-up time and other inefficiencies when it might hurt you most.
Silos make your project more vulnerable.
This is the natural follow-up to the point above. If one person owns all of your team’s knowledge of some part of your code base, your bus factor is dangerously low. Everything from an innocuous vacation to something more serious like that person leaving for a new job has the potential to tank your entire project, or at least slow it down considerably.
Silos reduce team cohesion.
This problem is particularly noticeable on horizontally siloed teams. Segregating individuals or teams working on the code can really hurt the cohesion of a product. I’ve seen teams that are too heavily separated start to form entirely different (and often incompatible) visions on a product or feature. This can lead to team conflicts and engineering inefficiencies.
Silos promote mistrust and us/them dichotomies.
This is the biggest problem I see with silos. The more separation there is between individuals and teams, the more likely it is that each unit will feel like it’s working on a different project with its own goals and objectives. If those objectives start to fall out of line with any other unit, you get into the realm of blaming, conflicts, and deadlocked products.
A Smarter Way to Specialize
Agile enthusiasts often like to promote the ideal of the full-stack developer and the idea that “anyone can work on any story at any time.” I don’t entirely disagree with this idea. I have seen it succeed, particularly on smaller-scale projects at Atomic. However, I think it’s idealistic and unrealistic for larger organizations and projects.
I can’t stress this enough: Just because you’re avoiding silos doesn’t mean you need to avoid specialization. It can be very important, and sometimes even critical for the success of a team. It is possible to be the most knowledgeable person on a particular subsystem, while still sharing and building it with other engineers. And it is possible to specialize in backend and database development while still knowing enough about UI code to hack on it and empathize with your frontend people. (They’re doing the same thing with your code, right?)
So remember: You can divide and conquer. You can specialize. But do your team a favor and don’t build silos!