Yesterday, Simon Wardley highlighted one of the biggest problems organizations face in transformations and improvement efforts: getting ‘trapped’ by their existing context.

Once an organization develops a solution that works, the solution establishes momentum. This momentum keeps the process in motion and delivering outputs that supports outcomes (good) as well as creating inertia to change (possibly bad!).

This inertia encourages organizations to optimize an existing process when the organization could be better off evolving that process to a better fundamental configuration. Another way to say this is that organizations can trap themselves in climbing up the hill they are on right now to get a better view instead of traveling down the road and camping on the hill where the really beautiful vistas are.

Example – Custom Racks

“Context Matters!”, Simon Wardley at DevOpsDays Atlanta 2019

Simon’s example map in the photo describes a situation where a datacenter operations team proposed investing in robotic automation to help them get servers to their users quicker. This makes sense from a certain perspective. Automation can help speed delivery, right?

The ‘automate with robots’ proposal is represented by the blue path that transits components in the Product and Custom regions of the landscape.

If you look closely, you may notice some components of the server value stream are in odd places. The ‘Rack’ and ‘Modify’ components are in the ‘Custom’ band of technology evolution. Hmmm.

It turns out this organization was purchasing standard rack mount servers and modifying them to fit into the organization’s existing, non-standard racks. The proposed robotic automation was to make this process happen quicker.

What they couldn’t or weren’t incentivized to see was that the non-standard racks were the problem. Optimizing this existing process is a waste of time and money when compared to alternatives.

A better move is to evolve the system to use standard racks, eliminating the work to modify the servers entirely (red arrow).

And mapping how the system delivers value to customers helped everyone see that.

That’s the way things are done around here

Take some time to consider where and how this is happening in your own organization.

Do you have ‘Transformation (TM)’ efforts that are making an existing process or system marginally more efficient, say 20-50%? Could you change those efforts so the outcomes improve by 2x, 5x, 10x?

If you’re making a major change (investment) that doesn’t give you a significant competitive advantage, why are you doing it? Will it be worth it in the end, even if you ‘succeed’?

I’m not saying making big changes is easy, but that is all the more reason to focus on the ones with big potential outcomes. Improving a process’s outcomes by 100% or more usually involves a ‘radical’ change that will encounter some resistance.

You’re going to encounter resistance like, “our policy says the security team has to review all of these changes” or “only the operations team can deploy releases” or “we have to run everything on-prem because we are regulated.”

Ask to see the policy and read it fully. Finding the policy is usually the hard part (because it is locked in a cabinet in the basement). Reading the policy usually takes about an hour. I have always found reading the policy and the quest hugely informative.

The ‘Cargo Cult’ Plane

Company-level policies rarely prescribe that a particular team be responsible for any given process. However, overtime a lore develops that in order to do X, you have to do Y and some amount of belief that this is one of the reasons the process is succeessful.

Once a team understands that the ‘policy says X’ is a canard for the system’s current inertia, people are usually much more comfortable with change.

So maybe you can automate security reviews and integrate them into delivery pipelines that deploy from dev through production. Maybe you can extract a function from your monolith and deploy it to a Serverless platform.

You don’t have to keep doing things the same way. Use mapping, retrospectives, and other learning techniques to discover the major evolutions that are possible in your technology landscape. If you limit your organization to incremental improvements, you’ll miss out on the really good stuff.