The Zen in DevOps

In a workshop I ran, a customer asked a great question that I didn’t have a good answer for until hours later.

Surfing the web, I stumbled upon a video from a Shaolin monk on a completely different topic.

You might wonder: What does a Shaolin monk have to do with DevOps? Maybe more than you think! Buddhism and DevOps both teach us to examine rules, and then detach ourselves from them.

I run a lot of workshops, and if you ever had the luck/misfortune to attend one, you know that I spend a lot of time thinking about the bigger questions, such as:

• Why do we do things the way we do them?
• Why do rules exist in the first place?

Asking such questions, I’ve come to believe that rules exist to help us stay on track as beginners. But once we have a firm grip on things, we need to learn to let go. Why?

Because if we only know how to follow rules, we’ll fall the second they no longer apply. In this blog post, I’ll demonstrate how Buddhism and DevOps can help us look past rules, to discover greater truths and successes, and apply common principles to any situation.

What is at the core of DevOps

One of the central aspects of DevOps is the concept of short feedback loops.

Instead of lengthy reviews and retrospectives, DevOps favors proactive and regular check-ins to examine what we’ve done and whether it’s in line with where we want to be or should be.

When we stop to ask why we’re doing things in a certain way, we can prevent ourselves from wasting time implementing a solution that won’t work, since our requirements will likely change after one of these feedback loops.

Why have they changed?

Because it’s nearly impossible to know exactly where we will be in a year. Purely assuming what a customer wants or guessing what we’ll be able to build by a certain time will only create setbacks and losses in resources.

To avoid this, it’s better to work with detailed plans on where we want to be in the next two weeks. The further away we get from the present moment, the vaguer the plans will get.

I was right in the middle of explaining this exact concept when a customer stopped me short and asked “Why shouldn’t I plan ahead in as much detail as possible? We don’t tend to work on the cutting edge of technology, so we usually know what we can do in a year. Is it not better to have a detailed picture that you only fulfill 80% of, than to have only a subset of the picture at all?”

Little did I know that the answer would appear before me later that day, when I was watching a video from a Shaolin monk who said “If you want to achieve things in life, don’t have a detailed picture of the future, just focus on the priorities.”

Oh! Now that sounded suspiciously like DevOps and it got me thinking…

What is at the core of Zen

One of the key tenets of Buddhism is the concept of being untethered. Of having “no attachments”.

Let go of things and do not be attached to them, lest they keep you back.

The famous Zen parable recalls a general who risked his life in battle a hundred times, but was afraid of seeing his favourite teacup fall and break. Once he realized how this fear was holding him back, he dropped the cup himself and consciously freed himself from his worries.

Attachments keep us back. Anything we have an attachment to, slows us down.

I can identify two types of attachments.

1. Attachment that’s imposed on us by the outside world. The world is overflowing with products to consume, creating attachments to things we otherwise wouldn’t care about.
2. Attachment that comes from within. These are things worth attaching ourselves to, such as our wellbeing and that of others.

The more we invest in a person or endeavour, the more attached to it we become. Although Buddhism tells us to let go of attachment, it’s important to realize that attachment can create beautiful results. The more time and energy we spend, the better the outcome will likely be. Some of the best work is the result of deep attachment.

It’s knowing when to let go of those attachments that’s key, which we’ll come to soon.

What we become attached to at work

We spend about a third of our days at work. It only makes sense that we become attached to what we do, how we do it, and the results we expect from our work.

Start looking for attachment in the realm of work and you’ll start seeing it everywhere.

• Engineers' attachment to their work is easy to identify. Especially when you consider the arguments they may get into over the right programming languages and the right way to code, among others.
• Product Managers are rarely without passion for their product – they pour their souls into their work and, tada, they’re attached.
• Security personnel are also known to obsess over little details that wouldn’t even make the rest of the company flinch. But they know those details matter. What keeps security personnel going, despite the pushback they get, is their attachment to making the company more secure.
• Let’s not forget upper management. They expect long-term plans with clear targets and they do not like being disappointed. Why? Because they, too, are attached.

The list goes on, but I think you understand what I’m trying to say.

Waterfall enhances attachment

In a waterfall-ish development model, attachment strengthens because we make long-term plans. We pour all of our ideas and efforts into a picture of the future, further intensifying our attachment.

But when reality doesn’t match the picture we had in mind, our hopes and dreams shatter. And because we were so invested in the original idea, we’ll fight even the smallest changes that don’t align with our vision. We’ll cling to our original intentions and prevent ourselves from creating a better solution.

What’s more is that we’re not the only ones doing this…

The whole company has been working towards this goal together. When the desired outcome doesn’t happen, every team suffers, from product and graphic design to marketing, infrastructure, and more.

It is possible that an individual can let go of the attachment. However, more likely than not, most will be disappointed. After all, group psychology ensures that when a group agrees on a target, it’s unlikely to change.

DevOps reduces attachment

It’s at this point that we can start to detect the Zen in DevOps.

DevOps, as a framework, restrains us from creating predefined expectations. In fact, it eliminates the whole concept of cogs and ensures that group psychology doesn’t go down a path that doesn’t serve the product or the teams.

DevOps has a built-in mechanism that deters us from getting overly attached to our creations as it requires us to publicly inspect the work done so far and compare it to what we know to be useful.

These are the short feedback loops built into the DevOps methodology.

When we measure and record our findings, we’ll quickly analyze our work to see if it needs tweaking. Because these check-ins occur regularly and more frequently, DevOps will pave the way for minimum friction and resistance.

Let’s say our work doesn’t turn out to be useful at all… The less attached we are to the outcome, the easier it’ll be to let go and come up with a new method. That’s why a detailed plan of where the project should be in a year doesn’t make sense. There should be requirements, ideas, case studies, yes, but a detailed plan will likely hold us back.

Avoiding the sunk cost fallacy

If you follow the DevOps philosophy, either by process or mindset, you shouldn’t encounter the sunk cost fallacy because DevOps creates a framework that limits attachment. What meditation and contemplation do for our lives, the DevOps framework does for product development.

At first, the processes from the DevOps framework need to be followed. Once people understand how helpful it can be, they’ll continue to stay detached from their creations even in the absence of a detailed plan…

That, in a nutshell, is the Zen of DevOps.

So the next time someone asks you “What is DevOps?” you can say:

“Seven pounds of hemp”.