This is a review of John Willis’ session at DevOps Connect: DevSecOps at RSAC 2017

Definition: Equilibrium - when all competing influences in a system are balanced.

In everyday life, we often refer to it as balance - achieving a work-life balance, balancing risk and reward or debt and income. However we say it, achieving equilibrium is key to success in your personal and professional life.

Balancing Act

In DevOps, we have to have equilibrium in how we cooperate, what risks we take for the project, our workload, our staff resources, etc. John Willis, a DevOps evangelist, talked about how to break bad equilibrium in any DevOps practice during his keynote address at RSAC DevOps Connect 2017.

Rather that discussing textbook technical manager tactics and solutions, John took a step back, looking at the bigger picture and applying theories used in other professions. Enter game theory.

Insights from the Game

Yes, game theory - using math to model conflict and cooperation between rational people. You can use what you discover to build or improve organizations by understanding what is motivating everyone involved.

Of course, before you can analyze a system and determine what needs to change, if anything, you have to ensure you understand the system and there isn’t a false equilibrium or aspects missing or misunderstood. These false analytics doom improvements before they start because you will base decisions on inaccurate information.

 John used an example of a civilization in the future finding chess pieces but no chessboard. Soon “experts” teach everyone how to play chess, but, alas, there was a missing piece - the chess board. But, they didn’t know that, and, when someone finds a chess board, suddenly, they dominate the game because they are the only one who knows how to play the game. The missing chessboard - key to the game - represents false analytics.

Diving into the theoretical, John looks at the Pareto efficiency model, which is, “a state of allocation of resources in which it is impossible to make one individual better off without making at least one individual worse off.” That is, if you improve something for one person, it will negatively impact someone else. This signifies the resources, processes, etc. are in equilibrium. On the flip side, it is inefficient if someone can still improve themselves without harming anyone else. 

When DevOps is Off-Balance

Looking at other theories, John introduced the Nash Equilibrium, proposed by John Nash, the subject of A Beautiful Mind, which states, “the optimal outcome of a game is one where no player has an incentive to deviate from his chosen strategy after considering an opponent’s choice.” The foundation of this idea is that you cannot predict outcomes by analyzing decision makers in insolation - you must analyze them as a whole.

These are interesting theories - but how do they apply to DevOps? Let’s start with asking some questions to uncover bad equilibrium in DevOps:

• Do we have undesirable outcomes?
• Are their opportunities for people to be better off -- without making anyone worse off -- while no one changes their strategy (what John refers to as Pareto Inefficient Nash Equilibrium)?
• Are there any false analytics (i.e., missing chess boards)?
• Are people making irrational decisions (this does not mean ones you disagree with, but irrational based on game theory, economic choices, etc.)?
• Is there cognitive bias within the system?
• Are people over-confident? 

Once you find imbalance, or you know it exists but haven’t found the root cause, what can you do? Here are some steps John outlined:

• Make work visible
• Manage work-in-progress
• Manage flow
• Create high trust between team members
• Embrace failure

Rethinking our Approaches

In some cases, the steps above might be difficult, but many are straightforward. To get at the culture of the organization or broaching adjustments to core principles or rethinking the resource allocation of the organization, John throws out a few suggestions, which he admits are really difficult:

• Addressing psychological safety
• Instituting blamelessness
• Rethinking software licensing agreements
• Increasing headcount
• Increasing buffers 

All-in-all, John Willis sought to encourage all of us in the DevOps community to not be burdened by the way we have always done it. Look outside at models and systems that industry uses to analyze and improve, evaluate your organization, and improve where you can -- even when it is difficult.

He left us with a quote from Andrew Clay Shafer, one of the earliest DevOps pioneers, “You are either building a learning organization. . . or you will be losing to someone who is.”

Want all of the details? You can view John Willis’ entire 30 minutes session here.