Internal friction due to cloud transformation
Throughout my career withing cloud technology a common obstacle found within organisations wanting to adopt a cloud strategy is internal friction from certain departments alongside office politics and the difficulty in change management.
As an example some people think they will lose their job or value within an organisation as workloads they used to manage are moved to the cloud changing their future within the organisation.
Another would be a financial director preferring a capital expenditure model and does not want to swap to opex so fights back the change.
What do you consider to be the key reasons people object to these strategic changes based on personal reasoning? Rather than the typical security, cost, compliance, time arguments you would see surrounding business reasoning.
Alan Arnett "The mistake we make is to think that explaining our own perspective better will convince other people. That's not the issue. If they don't immediately jump up and down with glee, it could just be that your version of the truth is not what they need to hear. "
Totally agree - I really like the TTM model here (the "trans-theoretical model of behaviour change" - the name sounds a bit pretentious but it's quite useful).
tl;dr people's willingness to change broadly follows a predictable pattern as show in the diagram BUT the key message for me is that many "transformation programmes" dive straight into the "preparation" phase ('this is what we are going to do') and even the "action" phase ('start doing this').
If you've for a lot of people in the org who are still in the "pre-contemplation" phase ('there isn't a problem') you'll get immediate resistance to preparation/action phase messages because THEY DON'T THINK THERE IS A PROBLEM.
So you need to have appropriate messaging for each step on the journey, also keeping in mind that there are different people in different phases SIMULTANEOUSLY and that people might regress (and probably will) depending on circumstances.
Note that getting people to "tip over" from preparation to action actually requires people to think the Pros outweigh the Cons by 2 to 1 before it tips the balance.
You can read a bit more in my deck from IP Expo 2017 here - https://www.slideshare.net/devopsguys/why-devops-transformation-has-to-start-with-you
Great contributions by Alan Arnett and Stephen Thair.
Let me put a different spin on it since I have been in both middle management roles and leadership roles driving transition to e.g. the cloud, blockchain and other disruptive processes and technologies.
A key enabler for transition is to create cross functional teams which can also address the sandwich problem Stephen was talking about. By doing that you are making sure that the digital transformation technology is not driven from your own viewpoint, but challenged and adjusted by objective feedback and viewing things from a different angle that you might have not thought about. It is also key not only to include the folks that are early adopters, but also to give a voice to the doubters, influenzers, connectors and salesmen in your organization.
The other tried and true approach is that starting small and proving out new capabilities, speed, agility - and yes savings will create ambassadors across the organization. Seeing is believing and seeing what you did with a legacy application and wrapped it in a container via Kubernetes or Docker and brought it to the cloud opens up the discussion and can inspire thoughts across all levels of the organization.
Then there is of course the tried and true model of managing by objectives so if you align targets and cascade down to middle management and their reports that often can make a big difference also. That implies that you have a good model and management tools in place to make that happen, but in the end there need to be top down alignment for this to happen and executive sponsorship is important.
Ultimately, the pilot, the building of cross departmental teams, the alignment of targets is preceded by a comprehensiv business case and the KPIs of cost savings, topline growth and soft benefits of agility, risk reductions etc need to be addressed.
Of course if you throw organizational changes in the middle and in fighting across different business units that can be stumbling blocks in your cloud transformation...
I think the first roadblock comes from platform and infrastructure team ( IT) because of multiple reasons. Sometimes the reasons are valid though. Few reasons are -
- Legacy apps transformation
- Lift and shift challenges
- Lack of orchestration model
And usually in meetings these teams directly align with the business impact. However that is true in someways.
Other pushback comes from Technology and Operations such that
- Transformation of apps
- Vendor selection ( AWS or Azure or IBM etc etc)
I think here the role of business owners and technology leadership is very imporatnt. These transformations require a slow shift, pilot projects and training.
Only working model can help.
We often refer to this as "the frozen middle" problem (the name courtesy of a senior person at AWS actually).
What we see is that there are generally two groups of people where at least some of them can clearly see "what's in it for them":
- The C-Suite who are facing massive pressure to respond to "digital disruption" via "digital transformation" and who see cloud & devops as part of the solution
- The Engineering people at the coal face who see their careers going down the toilet unless they modernise and learn the these new skills. And they are geeks (like me) who love this stuff anyway :-) )
So the two groups that see the "burning platform" are motivated to change.
But sandwiched between them is the "frozen middle" of middle management whose roles are being flatten out of the organisation, automated away and, more importantly, being transformed from "command&control" management roles (where hierarchy is power) to more autonomous leadership roles where creativity, vision, emotional intelligence etc are more important.
A huge transformation that sadly terrifies many people into paralysis.
The key fear for them is, to me, "I don't know what it means to succeed in this new model".
The clearer you can spell out "this is what success looks like", "these are the behaviours we want to see and will reward" and, most importantly, by the senior leadership creating a culture of "psychological safety" by letting people know "we've got your back".
Of course, if your senior management have the emotional intelligence of a rock and are borderline psychopaths only interesting their own career and cutting costs to drive their bonuses creating an authentic place of psychological safety may be problematic...
I'd take it even further than Stephen Thair. It's not just being able to spell out what success looks like etc. With such a fundamental shift to the cloud, no-one, not even the best technicians, knows what the organisation could look and feel like if this gets implemented. You know what's happened elsewhere, but that's not certainty for the next organisation. And by the way, if it is. If all you do is repeat the last project at the next client, how client focused is that? Tech can fundamentally change all kinds of things, but only if people engage in co-creating the change, and that requires facing up to the uncertainty.
The problem with the frozen middle analogy, is that even the 'wafers' are not completely on board yet. They are just OK so long as their comfort zone is not disturbed further along the way. The C Suite may say 'go ahead', but wait until it gets executed and one of the implications is that one of their budgets gets reduced, or headcount drops or even their function gets merged with another. Ditto for the technologists.
The mistake we make is to think that explaining our own perspective better will convince other people. That's not the issue. If they don't immediately jump up and down with glee, it could just be that your version of the truth is not what they need to hear. And if they do, it could be they haven't understood the implications fully yet. There's another version somewhere which, if they could see that, would create real engagement, but the job becomes tougher. It's not to do the comfortable thing - come up with a new pitch. It's to do the often uncomfortable thing - sit down and help them work through through their challenges and come up with their own story. As Stephen said - the issue is emotional, but if the people on the project team don't get that, C Suite or not, they'll spend years mopping up the consequences, including wasting a lot of time and money as the project disrupts the business, but not in a good way.
If you haven't come across it, this is a really useful book
16 months ago
Re your comment Chris Allen With respect to "And by the way, if it is. If all you do is repeat the last project at the next client, how client focused is that?" How do you ensure the solution is completely bespoke for the client whilst still providing evidence from previous deployments to ease their concerns of said change? Surely their will always be overlap unless the client is truly open to evolving?
There is always some overlap - you're not inventing new technology for them for example - but you ensure it is bespoke by helping them tailor the solution for themselves. In the end, the 'solution' is their business working differently. They may choose to repeat some things, and change some things, but those have to be well thought through decisions which have explored options, not just picking from a menu and hoping.
If the client tries to insist you do essentially the same solution as last time, be prepared for problems. They might be holding on to that for security, and it seems an easy sell, but the reality will turn out to be different to what they actually want. You pitch a standard solution and price accordingly because it seems simple, and they constantly ask for changes. It becomes a battle.
What you have to do is show them the previous successes, and then show them the process that led to those successes, which starts with helping them experiment and play with what might be possible with a shift to the cloud. In this model, selling is not a thing which leads up to a signed contract - it's a process which continues way after the contract as you help them evolve their thinking.
The initial urgency may come from pressure from elsewhere, but they still need to create their own vision to work towards which, as we've said before, won't be locked in stone. It will end up being some version of the points Stephen Thair made - more flexible, collaborative, creative, adaptable etc, etc. But they have to work that out for themselves, especially if its a long way from where they are now.
In the book I referenced, they talk about three things happening in parallel: Letting go of old assumptions/realities; starting to create new futures; and living with the uncertainty in the middle. These transitions take time - you are managing peoples' transitions, as well as change.
Does that help at all?
16 months ago
There are many issues braided together in this discussion. One thing I am sensitive to is the difference between WHAT and HOW. Cloud, or any technology really, is a HOW. Business strategy is WHAT. If you attempt to change HOW things are done without meticulously defining WHAT you are trying to achieve, you set yourself up for failure.
I am not particularly sure that migration to the Cloud is terribly different than one to any new HOW. Manufacturing automation, outsourced services and any of a million other things are pretty much the same, as I see it. Any significant change in HOW is probably related to increasing productivity, creating cost savings or implementing or evolving capabilities. All of these have impact on the people in, and maybe adjacent to, the enterprise.
Of all the areas in the enterprise that are susceptible to change, IT is probably at the top of the list. Technologies, processes and the business models they enable change at an ever increasing rate. Many of the disciplines associated with implementing technology are being undermined by the diminishing lifespans of the solutions we build. Why spend a lot of time, effort and money performing detailed Enterprise Architecture when the business can change so quickly and the suitability of infrastructure can be invalidated in a trice?
It has been axiomatic that technology is among the most political of disciplines in any enterprise for reasons that we all probably understand. Historically, business and department managers viewed having projects built for their areas as a sign of importance and they competed among themselves to obtain funding. Often, the perceived prestige was more important than the results and I have seen way too many situations in which projects were implemented successfully but no real business benefit was realized. Sad, but true.
Given my experience, then, I have the following observations and suggestions to offer:
1. The future state, including changes to operating processes, organization structure, individual roles and performance KPIs must be clearly articulated, documented and communicated before embarking on changes such as Cloud migrations. If the people involved can participate in helping to define WHAT, all the better.
2. Once WHAT is defined, then HOW can be. A clear project plan with a work breakdown structure, milestones and all the other elements of a professionally-built plan are required.
3. There WILL be impact on peoples' roles and maybe even their jobs. Without them, there may well be no justification for the changes the enterprise is contemplating. No one will be helped by trying to pretend that there won't.
4. The enterprise must reach a balance between retraining existing staff to operate in the new environment and bringing in people that are already capable of it. This is an unavoidable facet of the process of change. Undoubtedly, there will be opportunities for learning and advancement for some in the organization and diminished or extinguished opportunities for others.
My bottom line is this--change is change. There's not all that much difference between technological evolution and other types of change. There are reasonably well-understood approaches to dealing with change and failing to apply established wisdom because of the nature of the change is malpractice.
16 months ago