Skip to content

A lesson from a DevOps client that may apply to you

A client approached me with a typical request: they wanted to transform their IT organization to leverage all the latest and greatest DevOps technologies. They weren’t expecting me to ask “why will this help you?” They assumed the objective was self-evident, and hadn't given much thought to their answer.

But it turns out that the “why?” question is critical, and leads to other discoveries. In our conversation, I learned that they had assumed that modernizing DevOps would allow them to get work done faster, take better care of their customers, and make them a more attractive employer for digital talent.

And they’re right. DevOps tools, technology and skills can do these outcomes and may even be necessary investments for your business. But they were also wrong about what they needed to change to get to their objectives. Because DevOps ALONE won’t accomplish this. But if your goal is implement DevOps, you won’t realize you aren’t moving the needle on your business “why’s” until its way too late in your transformation to realign effort and expectations.

As I worked with this client to nail down why they needed change, we could then identify the total changes needed. In one exercise, we mapped the way that decisions get made in their organization. It looked like this:

public.jpeg
 

Typical flow

Information moves up to where decisions are made; decisions flow down to workers; decisions are made slowly by a few

In their current state, leaders high on the org chart make most decisions, and middle managers and individual contributors (who actually execute the work) were responsible for defining the problem and awaiting instruction on what they could or should do about a problem. To make sure they were making the right decisions at the right time, executives ask for more and more status reports, estimates, and project reports - some formally and some back channeled. All this preparation, routing and communicating information up and down the organization kept a LOT of people very busy and inevitably things were lost in translation or by the time a decision was made, the situation had changed. Or worse, nothing could change until a decision was made and idle time put performance metrics in the tank. To protect themselves from decision delays they can’t control, teams focused extra hard on activity metrics to show effort, not results. Executives then started asking for reports in these metrics too, so they could better manage performance. It was a vicious cycle that once created became incredibly difficult for any one part of the organization to change. It becomes “the way we do things.”

Organizations and teams that spend too much time in this state learn that information is a precious commodity, to be guarded and controlled. With good intentions, energy is focused on managing the message not managing the problems. A common symptom of this is very little trust between IT and the business, and among IT teams or divisions. Everyone doubts the other understands the real issue or will engage in solutions that are best for the business as a whole.

To get the results they wanted from DevOps tools adoption, they needed to reverse this model to look more like this one:

public.jpeg
 

Empowered flow

Information moves down to where a decision can be made; decisions are made quickly by those with the information

In this environment, leaders are focused on higher level strategic decisions and are expected to communicate the strategic environment everyone is in. They then empower/rely on individuals and team to manage the impact of those decisions on their work. Key decision-making is done by those closest to the problem or work to be done at the tactical level. When there are choices between scope, schedule and budget, teams check in with their leaders to make sure they have the correct understanding of priorities so they know how to make those decisions. They communicate the results of those decisions, not the activity. When there are changes to the business climate, direction or exceptions to be made, leaders communicate that down so teams can respond.

This culture change can happen with or without DevOps updates of course, but in this clients case understanding the why helped them gain shared understanding of what the tools would do for the organization AND helped refocus attention away from control and governance and toward cooperation and speed.

Changing this behavior in an organization is difficult, but achievable. It requires vision, commitment from leaders, and a desire to truly achieve the benefits that technologies like DevOps can give an organization. But without changing the model, the inefficiencies of the top-down decision-making model will prevail.