I'm still catching up from 2023.

It was a Wednesday morning, day two of the 2023 DevOps Enterprise Summit in Las Vegas. It was my first time at the conference, and I had already experienced a full day of thought-provoking talks, workshops, and conversations.

And I had been immersed in more of the same since meeting a colleague for coffee at 6 a.m. that morning.

I was carrying a notebook with pages and pages of scrawled notes, diagrams, quotes, contact information, must-read book recommendations, and topics to research.

My brain was so full, and the conference wasn't even half over.

Between sessions, that morning, I just stopped at the edge of the conference space for a moment to watch people go by. Hundreds of people. They all seemed to have an understanding of things I was only just starting to learn.

I had been a developer for 20 years, and yet I felt like the new kid. How did these people learn all this stuff? Where was all this information when I was starting out as a developer?

I wished that someone could just point me to a definitive guide, a central place where all the ideas came together. A quick way to get up to speed on what the crowd around me seemed to know.

What is DevOps?

Let's back up a bit. What is "DevOps"?

Ask folks in tech, and you'll get a variety of answers.

• Software developers ("Dev") supporting their own code in production instead of handing it off to Operations ("Ops"). So, Dev doing Ops work.
• Ops using code and automation to get their work done instead of tedious manual processes. So, Ops doing Dev work.
• A job title, specifically the person who manages the automation. "The deployment failed, our DevOps is taking a look." A third role, somewhere in between Dev and Ops?

When I say DevOps, I usually mean Dev and Ops working together.

What is it about Dev and Ops that makes cooperation so hard?

Dev has a mandate to deliver features fast. Naturally, they want nothing standing in their way.

Ops has a mandate to keep the system stable. And stability is easiest if you don't allow anything to change.

Dev changes things, which threatens stability. Ops locks everything down, which impedes progress. They are doomed to conflict.

Or so it would seem.

Can they cooperate?

In 2009, John Allspaw and Paul Hammond gave a now legendary talk at the Velocity conference called "10+ Deploys per Day: Dev and Ops Cooperation at Flickr."

Now, "deploy" here means the process of making software changes available to users. At that time, it was not uncommon for software to be deployed once or twice per year.

Dev would "throw code over the wall" to Ops to deploy and support. Ops would endure a tedious manual process that was different every time. It never went according to plan. A nightmare for everyone involved.

So, people thought it was ridiculous, maybe even irresponsible, to suggest deploying code to production ten times per day. And yet Allspaw and Hammond reported that their Dev and Ops teams worked together to do just that.

—Allspaw and Hammond

Their insight: Change has to happen as often as needed to support business goals. We need to use tools (automation, version control, logs, etc.) and culture (respect, trust, etc.) to manage the risks of change.

Catching up

The 2014 book The Phoenix Project is a fictional tale about an IT organization in trouble, but the conflict it describes is painfully real.

And The Phoenix Project showed how Dev and Ops can collaborate for the benefit of the organization. When I read this book in 2022, I blew off an afternoon of work because I couldn't put the book down.

DevOps Enterprise Summit (now called Enterprise Technology Leadership Summit) is hosted by Gene Kim, one of the authors of The Phoenix Project.

That's where I found a whole community of people who had been thinking deeply for years about how technology teams can work better.

In the past few months, as preparation for writing my own book, I have been reading (or rereading) the books that have been recommended to me by others at the conference.

I'd love for my book to be the guide I wished for in 2023, the introduction to better ways of working.

Where I get stuck

Here's where I get stuck, though: I can only speak with authority about my own experience. And I only have experience with a few of these better ways of working.

Even worse, I have no experience with actually getting my organization to change how we worked.

A lot of what I have learned was exciting because we were not doing it! I heard other companies' experience reports, read the research, and saw the potential for us. Things could be so much better...

But I never got to see many of these practices implemented.

I'd love to be able to say, "We were doing x, we started doing y, we were able to realize benefits a, b, and c..."

I have very few such stories to tell.

On one hand, I want developers to be aware of all these better ways of working. On the other hand, am I just setting them up for disappointment if they, too, are in organizations that won't budge?

Drop me a note

I would love to hear from you. Hit reply and let me know what's on your mind.

By the way, in my search for DevOps, Unsplash also provided me with a photo of a shirtless person with green hair holding a hand palm-out towards the camera, a computer-generated image of a car about to plunge into a lake, and another image of a pink rocket hovering over a bunch of pink blocks that were marked $.

None of these were tagged "Devops." Unsplash just figured they were close enough.

This newsletter is approximately weekly. In addition, I post to my blog on my website, which also appears on Medium and Substack.

Know someone else who would enjoy this? They can subscribe here: https://www.beyondwritingcode.com/connect/​

Thanks for reading!

​Beyond Writing Code is a newsletter from Leaf (Jessica Roy).

You are subscribed as Reader.

​Unsubscribe | Preferences | 113 Cherry St #92768, Seattle, WA 98104-2205