All about removing silos

Organisations are optimised in silos. This makes work efficient. Costs can be reduced by economise work done in a particular field. This has been the way of working since Taylor died. It does optimise work in factories for people working in a particular order on an assembly line. In a modern world where we build software, saving money on one silo can result in extra costs in the other. The taylorism way of working is therefor no longer rewarding. Taylor had some ideas of improving efficiency in production systems which we massively copied and still use. His idea was to improve the productivity by improving the efficiency of each process step; how would the world have looked if he had chosen effectively instead of efficiency?

What do we mean with silos? Silos are people of the same expertise put together. Put together in teams to build a small piece of the end product. Silos result in many handover moments. To reduce those moments factories implement assembly lines. Software development is a creative processes and it cannot be put into an assembly line model (no matter how hard we squeeze). How can we get rid of those silos and improve our effectiveness?

1. Product focus

Instead of focusing on process optimalisation we should focus on delivering a product that a customer is willing to buy. Our responsibility is to deliver that product with enough quality to satisfy the customer. A team should be focusing on the customer and only deliver what the customer needs.

2. Merge expertise

We merge expertise in a team, so one team is responsible for all the work done on a product. Including development, testing and maintenance. No single silo of experts remains, this is important. Of course there are experts, we just need to know where to find them. This will result in no handover and no waiting moments between teams, but it implies a lot! 

We need to know what work team members do, we need to learn, we don't have to ace it but we need an understanding how stuff works. In a DevOps team we need at least 10% time reserved to learn, just to keep up, learn and share.

3. Transparency

In order to find the right people for the job, we need to know from each other what we do. So instead of working silos, we have silos of knowledge sharing. We organise teams around products and customers, we gather to share knowledge.

4. Responsibility

With creating a team of mixed expertise around a product and its customers we are getting more responsibility. The teams makes promises, it needs to deliver, they are expected to keep up quality. Getting more responsibility means even more learning, the teams will be small companies inside the umbrella of a big one. The big one shares vision, mission and strategy. The team will follow the strategy, but gets its work from the customers. This also means that managers get less responsibility about the product, but more about developing team expertise.

5. Autonomy

All this results in autonomous teams that are capable of delivering quality and value to the customer through a product. 

By removing silos an organisation will change significantly. Work will shift and change. Teams will be in the lead to deliver customer value. DevOps has even a bigger impact on management comparing to teams. Teams know about software development, testing and operations. Management needs to learn to let go, to inspire, to share and to help removing impediments.

Do you still work in silos? What is the most difficult thing you are experiencing adopting DevOps?