Photo by noor Younis on Unsplash

DevOps Patterns Apply Everywhere

The most precious resource we have is time. Its most irritating aspect is not knowing exactly how much of it we’ve actually got. We can’t get any more of it. We can’t save it, we can only spend it. We expend a great deal of energy and effort trying to figure out how to spend it wisely, and on which things. It can be overwhelming.

What is DevOps, anyway?

Ask five people for a definition of “DevOps”, and you’ll likely hear five different answers. It’s a culture. It’s a job-title. It’s “development plus operations”, and people need to be able to do both (this is rare). I’ve even heard it used as a verb: “We have to DevOps that.”

Effective DevOps seeks to answer four questions

  1. How do we make our stuff?
  2. How do we know it works?
  3. How do we change it without losing our minds (or our customers)?
  4. How do we learn from our mistakes?
  1. Information overload
  2. Outside circle of competence/environment
  3. In the presence of a group
  4. In the presence of an authority (can be yourself)
  5. Stress — emotional, mental, physical
  6. Intense focus on a particular outcome

How Do We Make Our Stuff?

  1. Can we build and improve it efficiently? What does the development tool-chain look like?
  2. Did we pick a technology we can hire for, or did we choose an esoteric thing because we thought it was cool?
  3. How easy is it to reason about what we’ve built? How long does it take a new person to ramp up on our stuff?
  4. Can we scale it without burning through all of our operating capital? For instance (in software), does it require a giant machine to run on, or can we run it on a simple, cheap device?
  5. Do we invest in our resources? Do we invest in our people?

How Do We Know It Works?

  1. Are we monitoring it? What are we monitoring? Are we looking at the right things? Are we asking other people who have done this?
  2. How do we gather user feedback? How do we track it? Do we even pay attention to users?
  3. How can we tell when it breaks? Do we know the warning signs? What are the signposts to failure? Are our customers finding out what’s wrong before we do?

How Do We Change It (Without Losing Our Minds)?

  1. Did we design for change?
  2. Can we change it slowly, or do we have to change it all at once?
  3. Is our change easy to reason about?
  4. How fast can we go backwards?
  5. Are we recording what we did to change things?
  6. Is it simple, erasable, and audit-able?

How Do We Learn From Our Mistakes?

  1. Do we admit we make mistakes?
  2. How do we find out what happened? Do we even look?
  3. Look for the root cause. The reason something broke isn’t always on the surface. Have to dig for it.
  4. Can we tell who was affected?
  5. How do we spread our learning? Do we encourage our organization to hoard knowledge? Are teams in silos? How do we get them to talk to each other?
  6. How do we encourage experimentation? What is our tolerance for failure?
  7. How do we make it hard for ourselves?


So, Cycle of Awesome. It’s a feedback loop. You want it to be as short as possible. Tiny. Fast. The Cycle of Awesome should spin like a flywheel. If any part of this loop is failing, your trajectory will be flat. It might even go down. You want it to go up.

I write books and software. Opinions held loosely.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store