Silos in Tech

What is siloing?

In order to better discuss how engineers and teams become siloed, as well as the positive and negative effects it can have on a team, I should define what I mean when I refer to a siloed engineer and a siloed team.  The best definition I have seen for siloing is the distinct separation between engineers and teams from the rest of the company. While siloing can take many forms, this particular definition includes having minimal interaction with other members of a team and company.

How do engineers get siloed?

At the simplest level, a siloed engineer is an engineer that has little to no interaction with the rest of the team or company.  

Some of the main reasons siloing occurs are:

1. The engineer is a solo engineer and has no other team members

Here the engineer is siloed because they simply do not have anyone else on the team that knows the particular technology that they are dealing with.  Additionally, this could occur when the engineer is working on a small project.

2. The engineer is not colocated with the rest of the team

While remote work can be great and rewarding for some, it does mean that the person working remotely can more easily miss out on a lot of the interactions that the rest of the team has.  This is exacerbated by a number of factors, and particularly when the engineer’s working hours are different than the rest of the team. In this case, the engineer is almost completely isolated from the rest of the team and is essentially a team of one working on whatever small aspect of the project they are working on.

3. The engineer is working on something that has no relation to the rest of the team

Sometimes a team will have many small projects that they’re working on, none of which have anything to do with each other.  For example, Engineer A could be working on a project for Client A, while Engineer B could be working on a project for Client B, and Engineer C could be working on yet another project for Client C.  This situation is a bit more unique than some of the other silo situations, and siloing can be mitigated here if the engineers make a conscious effort to share and collaborate among the different projects.

4. The engineer has a skill set that is not represented by other members of the team

This is an easy situation to get into with self-contained product teams, where you potentially have members who can make each part of an ecosystem, an API, a web client, an iOS app, and an Android app.  While beneficial to the engineering process, there is a great potential on these types of teams that the engineers could end up siloed based upon their proficiencies, simply because no one else on the team is familiar with their speciality.  The worst case in this scenario would be each member of the team taking a subsection of the project and never crossing over to the other subsections.

5. The engineer just doesn’t work well with others

Hopefully, with carefully crafted teams, this will not be an issue for engineers, but this is a reality that occurs every once in awhile.  One or more engineers on a team may not want anything to do with the other team members, and, despite their expertise, may truly believe that they are better off working on their own.

6. The engineer is too busy and has no time for collaboration

Similarly, an engineer could become siloed and isolated if the engineer is too busy and has too much work.  This can manifest in the engineer not attending meetings so they can have more heads down time to complete their tasks.  Additionally, the engineer could be turning down opportunity to pair with teammates because of the sheer depth of their workload.

How do teams get siloed?

Teams can also become siloed in which they have little interaction with the company as a whole including not working with other teams within that company.  This can come occur when:

1. The team is completely self-sufficient and self-organizing

A self-organizing team that is completely self-sufficient can easily become a silo in this case.  They can interact immensely within the confines of the team, but they have no need to reach out to other teams for collaboration, insight, or pairing.

2. The team may be working on the same project as another team, but they are working on two different platforms for the same project, developing each in isolation

This is similar to the situation of engineers being siloed because they are working on a tech stack that is different from the rest of their team.  This team may be working on their own feature or platform, which doesn’t have much direct integration with the rest of the projects. Teams in this situation run the risk of not knowing what the other team is doing, which could potentially affect their workflow and the product overall.

3. The team’s project is under a non-disclosure agreement, or other contractual agreement, and cannot talk about their project with anyone else in the company

This type of siloing happens more often with companies that have multiple clients, many of whom may be competitors of each other.  Sometimes, in order to reduce the possibility of accidental shared code, knowledge, or other items that could be considered intellectual property, companies may have to have completely isolated teams.*

*The recent incident between Bethesda and WB Games is a prime example.  Both companies hired a third party development agency to develop games for them.  Now, Bethesda is claiming that WB Games’ Westworld mobile game utilized some of Bethesda’s Fallout Shelter’s intellectual property.  More information about this can be found here.

Overall, the root cause of siloing is the same in all cases: lack of frequent collaboration, lack of shared insight, and lack of company-wide visibility.  In my next blog on siloing, I will explore the positive and negative effects that siloing can produce.

"silos" by Doc Searls is licensed under CC BY 2.0