By Pierre Moncassin and Peter Stokolosa
Resistance to change can sideline any project. Customers who embark on the transformation journey towards VMware’s cloud platforms, increasingly often as a stepping stone towards DevOps, inevitably must confront the challenge of resistance to change, which manifests itself in many forms and behaviors.
Fostering a change in mindset towards transformation projects is key to a cloud/DevOps project’s success. No matter how much technical expertise the stakeholders bring to the project success remains elusive until they can be persuaded to adopt not only new tools, but to adapt new ways of working, thinking and participating in the advancement of the project.
We have found that the introduction of meaningful analogies to explain the character and necessity of change can help to unlock the key to motivational and behavioral changes in project teams.
Resistance to change usually boils down to two main factors:
- fear of loss – because change involves departing from the known environment (often perceived as a comfort zone);
- inability to develop a clear vision of the future state and the needed steps to arrive there engenders passive resistance and lack of motivation
Well-crafted analogies can help tackle both factors. Analogies are grounded in known, familiar environments. They are re-assuring because they build a cognitive bridge that begins with the known stage while offering a path to the future.
Next, let us share three frequently-used analogies that have been proven to resonate well with our audiences, when discussing cloud transformation.
Introducing a commercial electric power grid to replace local power generation (as an analogy for switching from physical IT to cloud).
The utility metaphor has been popular since the early days of the cloud – it was actually used well before the cloud era, first appearing in 1961 from John McCarty.
Early in the 20th century, the common approach to generating electricity was to own a private generator. Switching to the public utility model meant giving up ownership and control of the private power generator. It implied trusting a third party to provide electricity consistently and reliably, at a reasonable cost
The shift meant a radical change of focus from production to consumption. It meant that consumed resources are now commoditized, pervasive and always available.
It is worth noting that electricity consumption is also associated with simple metering – the ability to monitor consumption and therefore costs in real-time. This is a useful introduction to the cloud costing models
A retail shop versus a factory (as an analogy for the two teams in a cloud organization: one customer facing and one, infrastructure focused).
One of the tenets of the cloud organization, as recommended by VMware best practices, is to define two teams with complementary objectives.
The first team drives the communication and relationship with the business, we call this the Cloud Service Team. They work closely with business stakeholders and meet customer requirements with innovative solutions. They can be equated to the “retail shop” of the cloud organization – their main task is to provide compelling services (products) that are constantly adapted to customer demand.
The second team manages the overall infrastructure we call this the Cloud Service Infrastructure team. They can be equated to the “factory” of the cloud organization. Their objectives include standardization, efficiency and economies of scale in order to deliver cloud services with the best quality/cost ratio.
As with every analogy this one has its limitations. It understates the agility of the cloud infrastructure services. As this team progresses towards always-higher levels of automation, their day-to-day activities resemble more the engineering room (focused on design activities) than a traditional production chain (repetitive tasks are automated away).
From Farm to Fork. The modernization journey of agriculture (as an analogy for the evolution of IT roles from managing physical IT to operating a cloud).
(Note – this analogy will resonate best in countries with a strong rural tradition – think of France for example!).
Before the 1930’s, the farm ecosystem was largely run by local family businesses, with small units and limited mechanization. Farm professions were based close to the place of production: farmer, miller, carter (and many others). The path from farm to consumers (farm to fork) was relatively short and traceable: consumers could generally assume that their food was produced locally. Because production was limited there was a need for more families to farm for a livelihood.
Within a generation farming methods changed while mechanization brought significant increases in productivity, but it also meant that change to the métier of farming was inevitable. To respond to increasing customer demand, they standardized and consolidated to produce a greater quantity while implementing increased control and norms (quality).
Increases in both automation and market demand lead to sweeping changes in the farming “workplace”. Many traditional jobs and activities became less relevant or obsolete (eg laborers with horse and carts). New, specialized jobs developed , or became significantly more visible: traders, operations managers (for processing factories). In general, there was a shift from labor-intensive production to sales, marketing, distribution, quality control and standardized, automated production.
It’s worth noting, the path from production to consumers became considerably extended. Consumers have very little awareness of where their food is grown (unless specific labeling shows this sourcing information). Although the system required to deliver the product became more complex, the consumption aspects of the product were simplified.
Compare this to ‘traditional’ ways of running IT in technical silos. IT tends to be operated by silos of local expertise with numerous, labor-intensive tasks. As a correlation of silos (fragmentation of work), there is little standardization and the path from production to consumers tends to be short . IT tends to be “sourced locally,” so consumers may be familiar with the hardware and cabling as well as with the administrators who operate the platform. We have all heard stories of business users walking over to the IT administrators to resolve their problems (rather than raise a ticket with a remote service desk!).
As cloud automation is introduced, these tasks and roles will evolve along similar trends:
- Standardization of processes and architectures
- Leverage automation throughout
- Increased consumer expectations (measurable, formalized service levels, control over costs, agility)
- The path from production to consumers is significantly extended. In most instances cloud consumers are not aware of the location of their physical IT. There is a separation of accountabilities so that business lines do not usually communicate with systems operators – they would liaise via the service desk (for routine operations) and via the Cloud Service team (for more complex requests).
The technical transformation leads to new or transformed IT roles:
- Focus shifts from production (hardware, infrastructure) to consumption (cloud services). The new cloud organization requires increased effort on “marketing” of cloud services and “distribution” (teams focus on finding ways of making the services consumable e.g. publishing them on self-service catalog portal).
- There is growing demand for automation specialists who can translate the technical knowledge into workflows and scripts.
- New roles emerge: such as Service Blueprint Manager, a specialist with skills to leverage automation in tools such as VMware’s vRealize Automation.
- Traditional Computer Operations roles evolve, requiring more coding skills.
- The mission of IT teams changes from “maintenance” to value creation.
- Consumption is facilitated and simplified.
All in all – analogies are a powerful tool to help overcome resistance to change. One caveat though: do not over-use them as they risk becoming oversimplified, losing their pertinence and distracting from that main issue of how an organization must adapt to address inevitable change.
Take-aways:
- Start from the point of view that resistance to change is predictably human and normal. It is part of the change process cycle and it is not a problem. It can turn into one, however, if it is not dealt with correctly
- Leverage analogies in order bring a concrete dimension to abstract concepts such as cloud services; they can help to advance projects, but adapt your references with sensitivity to the audience’s culture, maturity and environment.
- Set clear remit for using your analogies. Keep in mind that all analogies have intrinsic limitations. Although they are useful tools to walk across the cognitive bridge, they have a limited shelf-life when it comes to get across a given message to an new audience – so their use should be focused.
=======
Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is based in Taiwan.
Peter Stokolosa is an operations architect with the VMware Operations Transformation Services and is based in France.
