As in any human social network, we in the software world collect this bank of common wisdom that we can begin to believe and follow without question. One of the biggest, partially true, but mostly wrong bits of common wisdom in our space is the sense that “silos” are always a bad thing.
First – let’s start with a bit of a working definition, so we have a reference. And so that we have something to question if we don’t agree on the conclusions that we reach here. A silo is simply a group – a limited set of social connections that we leverage to complete work.
The “limited” nature of the set of social connections is the first part of this that people tend to find implicitly disagreeable. It feels exclusionary. Isn’t inclusiveness an absolute good? No – it’s not. For two reasons.
Firstly, opening a working group to the wrong individual can lower the output of the other individuals in the group. This can happen for a number of reasons – the wrong skill set, the wrong attitude, the wrong vision.
Secondly, no matter how aligned an individual is to the values of the group…no matter how skilled they are….no matter how much of a positive, team player they are….at a point social connections – that is, communication network nodes, slow progress more than they help. It’s the reason we have the beautiful idiom; and why we understand so painfully well what it means to design software “by committee”. Committees are good for vetting all the angles of a thing. But as a group grows in size, its ability to execute diminishes rapidly, because its communication paths multiply. And this is particularly problematic in software where the things we are communicating are so detail rich, context sensitive, and highly technically sophisticated.
So it’s important to build silos…..the right kind of silos. Silos that have just enough people to accomplish what we want to accomplish and no more. We should have the skills and authority to design, build, test and put to use the software that we intend to create embodied in as few people as we can get away with.
And we shouldn’t feel guilty about it. Limiting communication networks to the minimum possible to deliver well and rapidly is the utmost that we can do to add value to our organizations and its customers. This is the foundational piece of our work.
We can’t let “common wisdom” keep us from this.
Now there is a bad type of silo – and if it isn’t obvious what that is at this point, it’s the kind of silo that creates hard separation between the people and skills necessary to deliver our software from top to bottom. That is – if we create organizational units out of those that build a database for the system, from those that build the application code, and also from the people who put the software into operational use – if we do that, we are creating the bad kind of silos that should rightly be frowned upon, and more importantly – avoided.
So we should recognize the importance of structuring our organizations properly. And we should avoid fear of an abstract notion (the silo) that is only bad if it is poorly implemented.
Here’s to building amazing software!