In my first blog on this topic, I covered the root causes of siloing. This time around, I am going to provide a few positive and negative effects that siloing can produce, starting with productivity.
Positive effects of siloing
-
Productivity boost by not being a part of as many meetings, and less people wanting to interrupt the engineer, leading to an increase in heads down time
Since siloed engineers don’t have many obligations to other people, they can have more heads down time, which means they can stay focused longer, potentially accomplishing more than engineers who have many connections,obligations, or are involved with many meetings.
-
Lower risk of confidential information being revealed to restricted parties
Since siloed engineers and teams don’t have many interactions with others and their work is shared by fewer engineers, there are less people who would have access to confidential information, and therefore less chance of something accidentally being shared.
Additionally, if teams are siloed and not sharing any information with each other, they could both be creating products for two competitors without running the risk of intellectual property being shared between the two.
Negative effects of siloing
Siloing also has many negative effects:
-
Silos isolate knowledge
If engineers or teams are siloed, the information they have tends to be locked up within that silo. With this knowledge locked up, if the engineer goes on PTO, leaves the company, or if the team is disbanded, then that knowledge is lost from the company. The company is then forced to spend more resources to regain that knowledge, is faced with potentially having to redo costly procedures because everyone is having to learn everything over again.
-
Higher potential for no one to know what the engineer is doing
Similarly to information being isolated, a silo engineer may not have many people who knows what they are doing, which could lead to lower accountability for that engineer. This can lead to lower quality of work as well as potentially less work done overall.
-
Potential for much lower morale
Humans are social creatures and typically perform best with certain amounts of interactions with their fellow humans. Some engineers love sharing and talking about their work with others, being siloed can remove that option for those engineers, also potentially lowering morale.
-
Without collaboration, quality will likely be lower
Many of the tools in software engineering requires the feedback of other engineers. Siloed engineers who have no “peer” could end up in situations where they have no one to fill that role leading to:
- Code Reviews likely won’t happen
- Pair programming doesn’t happen
- Architecture review doesn’t happen
- Problems cannot be discussed with another engineer with the same background so less than ideal solutions may be developed
-
Engineer has much fewer opportunities to lead/mentor/be mentored
If an engineer is siloed, especially if it is because they are the only one who knows the technology or tools, will have reduced opportunities to lead and develop a mentorship relationship. Leadership and mentorship relationships are great opportunities for engineers to learn and grow. Without these, their careers and professional development will be stunted compared to those engineers who are working collaboratively with other engineers.
These negative effects and some of the signs of siloing, of both engineers and teams, have something critical in common. Communication channels break down when engineers or teams are siloed. Knowledge sharing stops happening which can lead to technical debt piling up from multiple approaches to the problems.
Should engineers or teams be siloed?
There are many more reasons not to silo engineers than there are reasons to silo engineers. Even the potential velocity increase is not worth the very real potential decrease in the quality of the final product or the technical debt that will one day need to be repaid. In reality, repaying that technical debt may take more time and resources than were saved by the siloing of the engineer working on the project.
Most of the situations for siloling engineers or teams are manageable. If you have to have a siloed team because of contract stipulations, I would recommend that you make sure there isn’t any engineer level siloing and that there are other ways that the team can be better connected with the company.
I recommend that everyone looks around at your teams to see if you recognize some of the types of siloing that have been explored. The first step in stopping siloing is being able recognize when it is happening or when events are gravitating towards situations where siloing can easily occur. The best thing to do about siloing is to recognize when it is happening. We need to keep an eye out for the types of siloing outlined in my first post. Then you can start opening the communication floodgates. Reach out to engineers who are siloed, find out what they’re doing(especially if they’re on your team). Companies who have siloed teams should make sure that there are avenues of communication between the teams. Some of the easier to implement methods are having regular project showcases where teams discuss some of the tasks they have been working on, as well as some details into the technologies they are using.