Cloud to Culture

If you want to change technology that requires a change in process or, more seriously, culture, then you need to change the culture first. Get your people on board and then make the changes.

Right?

Perhaps not. Or at least not always.

If your culture is flexible and open, people collaborate across groups and you are staying competitive, then, yes, change some of the culture to new ways of working, then adopt new technology that requires the different mindset.

On the other hand, sometimes you realize how far behind your culture has fallen, how slowly things are moving, and how much of an advantage competitors are gaining while your team plods forward at its own pace.

In such times, you don't want to make a change; you have to make a change. Yet the team either does not sense the urgency or does not understand how much better things could be. What you need is a catalyst, a change so radical and widespread and touches so many parts of the organization that it forces people to adapt how they work.

Recently, I was talking with a very smart colleague who mentioned a CIO who was switching to Amazon Web Services (AWS) to force his organization to DevOps. In general, I think Amazon has excellent services. All of Netflix (and many other companies) are built upon it, the economics are excellent, and the flexibility and pay-as-you-go is the lifeblood of many a growing company. Often (not always), AWS works from a purely economic or operational speed perspective.

Yet AWS is a radical change. Along with the benefits of no more servers, switches, cables, data centres, firewalls, storage arrays, racks, smarthands, or installations, come far fewer guarantees about availability, and many operating models you used and assumptions you made when you controlled everything simply don't work in the cloud.

The upside, of course, is that the shift forces you to think in much better, reliable and cost-effective ways.

And there's the key. Even if AWS is not the right move at a given company based on the economics of capex vs. opex, new opex vs. sunk costs, and other factors, being forced to evolve operating models and architectures may be sufficient reason to shift into AWS. This is precisely the point that executive was making. I do not know if Amazon worked for his organization economically, but the radical change forced the necessary mindset shift to leap them ahead.

Containers provide a similar benefit. Sure, they are more efficient, easier to manage and far more lightweight, along with a great guaranteed replication model and better distribution model.

But more than anything, containers force you to think about ephemerality. Containers are made to run from seconds to days or weeks... and then disappear. Completely. If your container really is going to go away, you are forced to reason far more intelligently about immutable parts of your application, configuration (persistent but infrequently changed) and data (persistent and live).

So how do you know when you should adopt a change in culture and design to enable a move to better technologies vs. when you should leverage a radical change in technology to force a change in design, behaviours and culture?

If your entire team - software engineers and testing engineers and product managers and operations and IT - is nimble and flexible, then you can lead them to the better designs with their cooperation. Soon enough, they will be asking you when you can deploy technologies that better reflect their nimble practices.

On the other hand, if your team is slower to move, more fragmented (this side of the house vs. that side of the house) and regularly reverting back to existing patterns, you are unlikely to get them to change in a reasonable amount of time without a catalyst.

Actually, if some part of your organization isn't already trying to adopt new technologies and modes of operation beyond your current needs, perhaps has a small skunkworks project or proof-of-concept in the works, your culture is missing it.

One crucial point, though, is that a catalyst never works from within one group. Bring in or assign someone to own the change across the teams, while working collaboratively. Have them report outside the usual structures, so they cannot benefit one group or another or be caught in politics.

Summary

Great technologies, like cloud and containers, both can be valuable on their own as well as act as catalysts to force necessary cultural change in companies. In order to do so, you need to understand your existing culture, how forceful you need to be, and how to bring people on board and how to succeed at catalyst-driven change.

Does your culture move quickly enough to be a competitive advantage? Or is it held back? What needs to improve, and how can you leverage newer technologies to move your team to the next level?

Ask us; we love leveraging technology to change your business.