Or, The Seven Habits of Highly Effective DevOps.
You may have heard that the goal of DevOps is to rapidly deliver and reliably operate high quality software-based services. But that is only partially true. True, that is the desired result. But fostering the habits that produce that result consistently is integral to the goal.
In my work with clients I have found several cornerstone habits essential to creating DevOps results, and I have helped software organizations embrace these habits and earn the payoffs. Let’s explore the cornerstone DevOps habits and why these habits are as much a goal as the results they promote.
Habits come in two flavors, and the first flavor of habits is practical.
Habits of Practice
Habits of practice are the behaviors we routinely engage in, often without thinking about it. We buckle our seatbelt when sitting in a vehicle, or we stash our wallet in the same pocket or the same place in our purse. What today is an unconscious habit once began as a conscious choice to behave in a certain manner. Perhaps we were reminded by our parent to fasten our seatbelt, and we complied, consciously, until repetition forged an unconscious habit. Perhaps we were alarmed at the thought that we would forget our wallet or keys someplace, so we patted down our pockets, consciously, like Peter Falk in the final scene of The Princess Bride, until that, too, through repetition, became an unconscious habit. Whether conscious or unconscious, these habits of practice create the results that we are safer while sitting in the car, and that we do not forget our wallet.
Habits of practice create results. In DevOps, we want to deliver high quality software-based service rapidly. The habits of practice that create these results include, generally, automation, measurement, and sharing.
The particular practices of these general categories vary with each organization, as each has its own business situation to contend with. But it is impossible to deliver high quality, reliable service without these practices, especially as the scale of the operation grows to significant size.
We want to foster these habits of practice. In order to successfully develop them we need the other flavor of habits.
Habits of Mind
Habits of mind are the manners of thinking and the internal monologue we conduct inside our own heads. Just as our behavior can be habitual, so can our thought patterns. Habits of mind are important because they can create and change habits of practice. For example, we all know the feeling of frustration when something in our lives isn’t working for us. It grates at us, it taunts, and it refuses to budge. Frustration is a sign that we need to change something about our lives. Our internal monologue upon encountering frustration influences whether we will change and what kind of change we will make in response. When our thoughts reflect passivity, I always have bad luck, we are not motivated to change. When our thoughts are empowering, this is an unfortunate but temporary setback, we are moved to change something about our situation—to try again, to try in a different way, or perhaps to let off steam and simply get over it.
In order to consciously create a new habit of practice, you need to have certain essential habits of mind. The essential habits of mind drive you to change your behavior over time, until you have improved your habits of practice. Without the supporting habits of mind, habits of practice are created by default, without our awareness, and these default practices seldom are the most effective at reaching our desired goal. Even once you have changed your practice, you can only improve by honing those practices, and the drive to improve your practice stems from your habits of mind.
In short, habits of mind create habits of practice create results.
In the DevOps field the factors that influence practice have been collectively termed “culture.”
But culture is an opaque term that does not lend itself to scrutiny. It is more useful to consider the habits of mind that foster habits of practice.
Shlomo’s Four Cornerstone Habits of Mind for DevOps Practices
The four cornerstone habits of mind necessary to foster DevOps practices and DevOps results are agency, awareness, respect, and healthy selfishness. Read on for more details on each of these habits of mind.
Agency
Agency means thinking that you can change things, that you can improve your lot through your actions, that you are an agent in your own life. If you believe you are able to change things then you can summon the motivation to try to change your behavior. On the flip side, if you lack agency—if you believe nothing you do will change anything—then you will be disheartened and won’t bother taking any of the steps necessary to change behavior. The more agency is ingrained as a habit of mind, the more you will feel in control and able to change your behavior.
This is a cornerstone habit of mind for DevOps because DevOps habits of practice require constant refinement, and you must believe that you can change and improve the current situation in order to do so. In an organizational setting agency is sometimes called “empowerment.” Organizations, too, cannot improve their practices unless members believe that they can change the way things are done. This is why agency as a habit of mind is so important for cultivating DevOps habits of practice.
Awareness
Awareness is the mental habit of perceiving what is around you. We are not aware of everything that transpires in our lives, and often we do not recognize that our practices can be improved. We cannot change our habits of practice if we aren’t aware that they need changing. This is true in life in general and with DevOps in particular.
Respect
Respect means acknowledging the feelings and opinions of others. Organizations consist of, and exist to serve, individuals with varied feelings and opinions. If you want to change habits of practice you must acknowledge the feelings and opinions of others who are involved. This doesn’t mean you need to feel those feelings yourself; it only means you need to believe that those feelings exist and are valid.
Healthy Selfishness
Healthy selfishness is thinking of your interests so that you can help others. It means thinking about how to overcome your obstacles to success and enabling yourself to do the same for your teammates. It means wanting to make your world better so you can make the world at large better. It is the driving force behind economic and technological progress. And healthy selfishness is essential for DevOps because it is the motivating force behind improving habits of practice.
What About Empathy?
Empathy is the ability to understand and share the emotions of others. It requires lowering your emotional defenses and allowing yourself to be vulnerable to the stirrings of another’s heart. Within the context of a supportive friendship or life partnership, empathy is vital. Understanding and sharing your partner’s emotions is essential to support them through pain and adversity and to grow together with them—in fact it is the essence of such a long-term relationship.
But empathy’s importance for DevOps has been drastically overstated. At our jobs we do not need to open our hearts to feel pain. Demanding that someone exhibit empathy evokes alarm and raises their defenses. Even professionals who do directly confront emotional pain, the psychologists, counselors, and ministers, do not allow themselves to be moved by the emotions they are exposed to in the course of their work. They maintain their emotional defenses. For the rest of us who do not deal directly with pain at work, which includes everyone in the IT and software industry, respect—acknowledging feelings and opinions of others—is enough for the professional setting. Insisting on empathy at work is irresponsible.
The Habits Are the Goal
DevOps is the continuous improvement of practices to rapidly deliver and reliably operate high quality software-based systems. Continuous improvement means regularly, consciously, and intentionally developing and honing those skills. In other words, DevOps is more than just the goal of delivery and operations. It is also the habits—of mind and of practice—leading to continuous improvement.
Fostering the three DevOps habits of practice—automation, measurement, and sharing—requires the four cornerstone habits of mind: agency, awareness, respect, and healthy selfishness. In all, those are the Seven Habits of Highly Effective DevOps.
The classic formulation of DevOps, Culture, Automation, Measurement, Sharing—”CAMS”—is an expression of habits of mind and habits of practice: culture is a habit of mind, automation, measurement, and sharing are habits of practice. To succeed at a DevOps initiative, you and your team members must exhibit these four habits of mind. They are the keys to forming productive habits of practice and, ultimately, the results you want to achieve: rapidly delivering and reliably operating high quality software-based services.
8 replies on “Habits: The Essence and the Goal of DevOps”
I think you’re overthinking it with respect to empathy. When we say that dev should have empathy for ops, we’re not talking about empathizing with your sysadmin’s experience of growing up with an alcoholic father. We’re just talking about empathizing with their experience of trying to keep a site running with crappy, hard to deploy code that hasn’t been tested for performance or resilience.
Systems thinking is about creating larger wholes from the relationships between components. Relationships require conversations. Conversations require the ability to open oneself to another’s perspective. In the context of DevOps, we’re talking about work perspectives, not deeply personal ones. On the one hand, we have to connect with each other as human beings trying to do decent jobs. On the other hand, we don’t need to plumb the depths of each other’s psyches in order to do that.
@Jeff Sussna,
You’re saying DevOps requires the ability to open oneself to another’s (work) perspective. I agree completely. That’s called “respect”: acknowledging the feelings and opinions of others.
“Empathy” is much deeper: experiencing the feelings and emotions of others. Dev does not need to feel Ops’ pain at trying to keep the site up and running; acknowledgement that Ops’ experience is valid and important is all that is required. In environments where that acknowledgement is hindered by organizational structure (think silos), changing the structure is the only way to foster respect for the counterpart. Eliminating barriers to respect does not require lowering psychological defenses and experiencing vulnerability. Empathy does.
And we agree that empathy is not about psychoanalysis. As you say, “we don’t need to plumb the depths of each other’s psyches in order to do that.”
Shlomo,
I think we’re all talking about more or less the same thing. However, I believe that Jeff and I may be coming to this from a bit more of a UX perspective. Here’s, for example, one point of view (from http://www.paulolyslager.com/empathy-in-ux-design/):
“Empathy – the capacity to recognize emotions that are being experienced by another person – is one of the many ‘soft’ skills a great UX designer should possess. Empathizing with users leads to a genuine understanding of how to solve their problem and ultimately building better products.”
Similarly in devops, empathy can be used to gain a genuine understanding of what and how to solve organizational problems that ultimately allow a group of people to rapidly deliver and reliably operate high quality software-based services.
@Dave Zwieback,
Thanks for that very valuable insight: @Jeff Sussna and I may be coming at this from different points of view.
If I understand your comment about UX, empathy is required in order to solve UX problems. That may very well be true, and I have no issue with that.
But, extrapolating from the UX field into DevOps and organizations is a lot farther than I’m prepared to go. Empathy has its place, but it is not required for solving organizational problems between Dev and Ops. Acknowledgement of each others’ feelings and opinions, i.e., respect, is.
[By the way, “the capacity to recognize emotions that are being experienced by another person” is not the definition of empathy. It might be termed “mindsight,” and it is a gateway to empathy, but it’s not “experiencing the feelings of another.”]
From dictionary.com:
Respect: esteem for or a sense of the worth or excellence of a person, a personal quality or ability.
Empathy: the intellectual identification with or vicarious experiencing of the feelings, thoughts, or attitudes of another.
@Jeff Sussna,
Perhaps with those definitions we are agreeing more than disagreeing.
What are your thoughts on the main message of this article, that DevOps is as much about habits as it is about achieving a particular result?
Overall I like it. I think the question for me is how do you change habits of mind? Many legacy IT organizations lack things like a sense of agency. They respond to new ideas with “we can’t do that” or “we’ve always done this”. They fear uncertainty and experimentation. Before they can adopt desirable habits of practice, they need to change their habits of mind.
@Jeff Sussna,
One key to changing habits of mind is developing the ability to hold two conflicting thoughts in your mind at the same time. I call this The Fitzgerald Quality, for F. Scott Fitzgerald’s quote, “The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.” As you practice The Fitzgerald Quality more and more, it becomes easier to consider both your current, undesirable, thought pattern (whatever it is) and the desired thought pattern (agency, awareness, etc.) at the same time, and make a conscious choice about which thought pattern to pursue. Over time, with repeated conscious choice of the desired thought pattern, a new habit of mind is formed. That’s one aspect of changing habits of mind in a very small nutshell.
I intend to write and speak a lot more about my work with this approach. It is strongly influenced by the work of developmental psychiatrist Dr. Gordon Neufeld and somewhat by Dr. Stephen R. Covey.