[Reading time: 1 minutes 52 seconds]
One of the goals of DevOps is to create autonomous teams. Autonomy comes from being entitled to making your own decisions, and having the necessary tools and knowledge to execute these decisions: not depending on anyone else.
The antithesis to this integrated structure is a specialist/function-based department structure: “silos”, in DevOps lingo.
To give an example of what I mean: in a siloed organisation you might have separate (say) database, sysadmin, frontend and backend departments, all working together to build a product.
Or you might have a cross-functional DevOps team including (among others, presumably) database, sysadmin, frontend and backend specialists all grouped together, working in this one team.
Where, some people argue, is the difference? Isn’t such a cross-functional DevOps team just a different type of silo?
At face value, they seem to have a point. Of course there are still boundaries, of course there’s still a bunch of people who form an entity.
But consider why silos are considered so problematic: because they disrupt development flow. They require lots of handovers, coordination, alignment with other groups. This makes work slow, error-prone and frustrating.
On the other hand, creating a team with the goal of autonomy would mean that the necessity for coordination etc. is minimised, at least outside the team. Of course a lot of communication goes on within the team, but that should be relatively painless.
Autonomy in that sense means that it’s just very rarely necessary to align with far-away others. Instead everybody can do their own thing with a minimum of friction, allowing for maximum speed and flexibility.
So while boundaries are a disadvantage in a siloed organisation (because they’re in the wrong places and create a hindrance), they turn into an advantage in an autonomy-focused organisation, because the well-placed boundaries there are exactly what makes autonomy possible in the first place.
(Image by Tomasz Mikołajczyk from Pixabay)