By Pierre Moncassin
Every customer’s journey to Cloud, DevOps or other transformative initiatives is unique to an extent. Yet all those journeys will come across a similar set of challenges. With the exception of truly green-field projects, each transformation to Cloud/DevOps involves dealing with the weight of legacy – organizational and technical silos that hamper their momentum towards change.
This is why I often hear from customer teams: “We know that we need to break down those silos – but exactly how do you break them?”
Whilst I do not advocate a one-size-fit-all answer, I want to share some recommendations I promote on how to go about breaking those silos – and some mistakes to avoid along the way.
From where do silos come?
As discussed in earlier blogs, silos usually come into existence for valid reasons – at the origin. For example, when infrastructure administration relies on manual and highly specialized skills, it appears to make sense to group the skills together into clusters of deep expertise. Unix gurus, for example, might cluster together, as might Microsoft Windows experts, SQL database specialists and so on. These are examples of silos teams build around infrastructure skills – experts of all those areas need to align their mode of operation to support cloud infrastructure services.
Other examples of commonly found silos include:
- Application Development to Operations: DevOps emerged precisely as a way to break down one of the ‘last great silos’ of IT – the persistent gap between the Development teams and Operations teams.
- Business to IT: When IT becomes so reliant on a specialist set of skills (think mainframe programming) significant inefficiencies arise in cross-training IT staff to business or vice-versa. In transitioning to Cloud/DevOps, this is another of the ‘great silo risks’ that the transformation will mitigate and ultimately break down completely as Business, Application Development and Operations function as an integrated team.
Common mistakes when attempting to break down silos.
a) Toolset-only approach.
A frequent temptation for project teams is to install software-based tools and assume (or rather, hope) that the silos will just vanish by themselves. In Cloud transitions, teams might install automated provisioning, but forget to work across the business/IT silos. Result – adoption by the business generally ends up minimal. In DevOps transition attempts, the technology approach might consist of deploying, for example, Jenkins, Code Stream etc. – tools meant for continuous delivery efforts, but failing to bridge the gap fully with day two operations management, for example without governance around incident-handling or idempotent configuration management. Without a clear path to resolution that cuts across the silos, it is easy to see when issues are not resolved satisfactorily. The impact on customer satisfaction is predictably less than optimal.
b) Overlook the value of ‘traditional’ skills
During the transition to Cloud/DevOps, especially when considering a toolset-only approach, it can appear at first sight that many of the legacy skills have become irrelevant. But this is often a mistaken perception. Legacy skills are likely still relevant, they simply need to be applied differently.
For example, traditional operating systems skills are almost always relevant for Cloud, however they will be applied differently. Instead of manually configuring servers, the administrators will develop blueprints to provision servers automatically. They will use their knowledge to define standardized operating system builds.
Traditional skills become all the more critical when we look into soft skills. The ability to manage stakeholder relationships, communicate across teams, organizational and business specific knowledge – are all essential to running an effective Cloud/DevOps organization.
c) Focus on problem not solution
This is a well-known principle of change management – focusing on the problem will not solve it. Rather than present the teams with a problem, for example existence of a silo, it is often far more effective to work on the solution – cross-silo organization and processes.
Does it work? I can certainly relate the experience of ‘seeing light bulb’ moments with highly specialized teams. Once they see the value of a cross-silo solution, the response is far more often “we can do this” as opposed to defending the status quo of individual silos.
In sum, focus on the vision, the end-state and the value of the end-to-end solutions.
Five recommendations to help break down silos.
- Shift from silo mindset to Systems Thinking. Conceptually, all the ‘common mistakes’ that I mentioned above can be traced back to the persistence of a silo mindset – whether focusing on traditional (versus leading-edge skills), new toolsets (versus legacy ones), or isolated ‘problem’ areas. The better approach is Systems Thinking. Systems thinking implies an understanding that the overall organization is more than the sum of the parts. It means looking for ways not just to improve the efficiency of individual elements (skillsets, tools, process steps) but optimize the way these elements interact.
- Create vision. As mentioned earlier, creating the vision is a vital step to get the team’s buy-in and to overcome silos. This can entail an initial catalog of services and outline workflows to fulfill these services. Potentially, it may be worth setting up a pilot platform to showcase some examples.
- Build momentum. Building the vision is important but not enough. One the initial acceptance is reached, the transformation team will need to build the momentum. For example by recruiting ‘champions’ in each of the former silos.
- Proceed in incremental steps, building up a track record of ‘small wins’ and gradually increasing the pace of change.
- Establish the permanent structure. One the change in motion, it will be necessary to define the long-term roles that operate the Cloud/ DevOps operations. These roles are detailed in ‘Organizing for the Cloud’: https://www.vmware.com/files/pdf/services/VMware-Organizing-for-the-Cloud-Whitepaper.pdf.
Take-aways
- Breaking silos is a result rather than the end. Start by building the vision to engage teams and motivate them to break the silos themselves.
- Do not rely on technology alone. Toolsets augment processes, but do by themselves overcome silos (e.g. vRealize Code Stream, vRealize Cloud Automation and other VMware Cloud automation tooling) as long at they are leveraged to sustain the vision and constantly build momentum.
- Leverage existing skills. Many of the legacy, previously silo’ed skills can be adapted to the future cloud/DevOps organization.
=======
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in the UK.
