How to Properly Break Down Silos in Software Development

Why is it so important to break knowledge silos inside Software Development, and why probably you are doing it wrong.

You may have heard that knowledge silos between Software Development teams are bad, and you most likely already have some kind opinion about that. Or even worse, you may have been forced to break some of those silos through some unnatural cooperations, and you feel that it hurts your productivity. You might be right, you might be wrong. How can we know? Yet, what’s most strange is that when we think about breaking silos, we always think of breaking them in the same direction. But, what if we should break silos differently?

The mainstream kind of silo.

So, let’s start with the typical case. Imagine a software development company, with a large project, and several development teams working on it. If you let the developers follow the path in which they feel more comfortable, they will inevitably specialize in the parts of the project in which they have more expertise. And with time, that specialization will grow, and one day, one developer of one team, will have a hard time working on another team.

We can argue that we have created a silo of knowledge. Although two teams are working on the same project, each team has reached a very different set of knowledge. Each one probably works in a different part of the project, and if the code is decoupled correctly, most likely each one has a little effect on the other. So, somehow, each team has become isolated from the others.

Knowledge Silos between developer teams.

As a matter of fact, this is the kind of silo that we often think about when we listen that we have to break knowledge silos. And it seems obvious, right?

So, for example, if we are talking about an ecommerce application, one silo could be the Catalog, another the Cart, and the other Shipping.

We should break those silos, right?

Well, before making any judgement. Let’s think, what's going on. Each team of…