IT departments are nearly always organised along functional lines. It makes good sense, you’re working towards shared goals, talk a common language and perhaps even share similar interests outside work. The business also benefits by having a focused team. These siloes can be highly productive but taking a broader view it nearly always leads to some duplication of effort, multiple similar tools and prioritisation of internal rather than cross-functional initiatives. The tool duplication, as an example is particularly acute regarding Automation, often there are multiple similar tools within a company within different teams. The tools will generally differ across; technology requirements, UI’s, automation philosophy, support, integrations, costs, training and monitoring.
In addressing the so-called Silo Effect, a common management technique is to move to a product focused structure rather than a functional grouping. Unfortunately the problems don’t disappear as new siloes are formed around these product lines. They might be broader or bigger, but they’re still siloes and are likely internally focused. What managers and executives really want to achieve is better collaboration and communication between and across teams that are focused on their own functional goals jointly with cross-functional initiatives. Re-engineering, centralising, decentralising, productizing, there’s a dozen names but practically speaking the goal is the same and I liken it to throwing a pack of cards into the air and hoping that they fall in perfect suits – possible but unlikely.
So, re-engineer if you must but you could save your money and invest in your existing teams. A better approach is to devise a strategy that benefits all teams, protects and advances their individual goals but has common shared goals. This technique naturally gets teams talking and removes perceived or real barriers to progress. A great example of this is DevOps, which offers a new and subtly different approach across important teams (traditionally very siloed) because it doesn’t seek to redraw the functional lines. Hold that thought let’s take a step back.
DevOps was a revolution to many in the noughties. The term itself is a portmanteau of the words, development (Dev) and operations (Ops). It is literally a philosophy that challenges teams to build a continuous delivery pipeline of application changes. While simultaneously respecting Operations desire for a stable operating environment and Developments desire for more change. Arguably also the businesses desire for faster innovation as well. DevOps has been extremely successful at fostering closer bonds between Dev and Ops teams and DevOps is now mainstream. Companies and people talk about a culture of DevOps meaning continuous delivery and hence continuous change or innovation. Some companies, such as Netflix deliver as much as a hundred changes a day.
The real power of DevOps is that it reduces the silo effect and challenges teams to cooperate for the greater good on broader initiatives, things that really help drive the business forward and not just protect the status-quo. Automation has a similar effect on siloed teams, but I will explore that in a follow up post.
The philosophy of DevOps is the mechanism that can connect teams in new ways that keeps all the good parts of siloes but promotes a culture of networking, collaboration and shared success. It is equally applicable to business as well as IT teams and could very well be the foundation of large scale transformational projects.
Please contact us if you would like to understand more about how DevOps approach could benefits your operational transformation.
This post remains the property of Paul Wade and is reproduced with his consent.