Why DevOps is Driving the Ship

Some current trends in process

This edition driven by Steppin’ Out - Joe Jackson

Our exploration today starts to pull process ideas for shipping software out of DevOps, and what we can learn from it, since I’m not sure we’re all up to speed on how fundamental these concepts are.

DevOps has been around for a long time. I’ve seen the role in different companies, DevOps tasked both with the “developer experience” and also managing deployments and the act (especially in cloud applications) of managing and protecting the overall system, as many changes get shipped through tactics like Continuous Delivery.

Photo by Austin Neill on Unsplash

Fans of Lean will see lots of analogues, since we’re dealing with another system responsible for “customer value” at the end. Folks familiar with Agile methodologies will see consistency with smaller batch sizes, faster iteration and the connection to the end user and delivery. It’s all connected.

Because DevOps is ultimately in the position of shipping the software, it’s very concerned with the rate of shipping, the quality of shipping and the productivity of the teams pushing changes. For that reason, the DevOps influence extends across the entire system and the processes everyone uses.

DevOps isn’t strictly a technical discipline, it involves all of us and how we lead our organizations.

So what are the main takeaways for us and where am I digging?

I’m reading:

  1. Accelerate: The Science of Lean Software and DevOps
  2. Team Topologies: Organizing Business and Technology

And chasing some specific topics:

  1. I’m starting to learn about a process from Lean called Value Stream Mapping, and the implication on organizations and leadership. Rather than focusing on groups of duties or roles, let’s focus around the events that need to take place to ship the software.
  2. From this perspective, job satisfaction, development, and the effort leaders put into motivating and sharing a vision with a team is crucial. It’s part of the process.
  3. I’m also investigating a tactic called Wardley Mapping around mapping our systems and how they can deliver on user needs, and what that means for how we do work. That, and it’s conceptually rooted in The Art of War!

All of these topics could be a post on their own, and I might do that in the coming weeks. Yell at me if you have thoughts on these, or have used these tactics previously.

General Miscellany

Other books I bought this week:

Other books I’m reading:

  • One River - rich account of exploration in Columbia, pulling in botany, history, culture. Amazing.


Colin Dickey took Malcom Gladwell apart with style. For those aspiring to be senior engineers and leaders, a great list on needed skills and a glimpse into how Rands makes decisions.

I enjoyed how Youtube scaled, and stop saying it’s simple.

Knowing mental models can only help us all think better.

Subscribe to High Leverage Engineering

Sign up now to get access to the library of members-only issues.
Jamie Larson