DevOps Is About Habits, Not Outcomes

It’s a Friday; a good time to reflect and think a little about what I’m grateful for, and what I’ve learned. I wanted to share with you a little story and what it taught me about myself and how to create lasting change.

In November of 2018 I went in for a routine checkup to my doctor. It had been a while – like five years – since my last visit. A few days later I got the news: I had full-blown Type 2 Diabetes. I go into this more in my book, but this was shocking to me, and I went through all the stages of denial, anger, and guilt. Guilt especially – diabetes is a lifestyle disease. I had done this to myself, with too much pizza and beer, too much time on the couch.

While I was struggling with coming to grips with my new limitations, I found two amazing resources: “Tiny Habits” by Dr BJ Fogg, and the book “The Power of Habit” by Charles Duhigg. Both are game changers. Finally, I realized why all the grand resolutions and big pushes I’d made to change my lifestyle had ended up in failure, and how to create change that sticks.

Basically, I was trying for a “Big J” – an all out effort, based on a big New Years Day type resolution. “I am going to lose 30 lbs in 3 months!” To do this, I’d embark on all-out ‘personal transformations’ – radical diets, 2-hour gym torture exercises. You know the deal! Well, guess what – maybe a few weeks later, or a month at most, I’d be back on the couch – discouraged, depressed. What had happened?

Interestingly, a friend of mine had a similar “now what?” moment – when a doctor told him he needed to change or he’d be dead in ten years. My friend went home and decided to try something he liked – getting on a bike. So every day when he got home, he’d bike 3 miles from his home. This was an easy, low-effort habit to start with. After a month or so, he started going for 5 miles… then as far as 10, on weekends. Then he joined a riding group. Three years later, he’s dropped thirty pounds – all by doing something he likes, starting small, and gradually ramping up his positive habit.

Too much change, too fast, is a sure recipe for failure. It takes a significant amount of energy to get up and go to the gym for 2 hours, for example. I’ll bet, after a week or so, you’ll hit snooze on your alarm clock and go back to bed – or a friend will come to visit – and that speed bump will leave you right back where you started, frustrated and discouraged.

Both Charles Duhigg and Dr Fogg point out that like any other chemical reaction, it requires energy to start anything new and overcome inertia – something called “activation energy”. Lowering that activation energy is the key for success. So, you might do something simple – like lay out your clothes the night before, so its easy to get to the gym. Or you could start with a 10 minute a day goal in the gym. The point is patience. It took you years to get to this point; it’ll take you years to dig your way out.

I’ll repeat those three common factors in failing to create change:

  • Trying too much change too fast.
  • Not planning for failure. (Something is going to break your routine. What then?)
  • Thinking in terms of big outcomes and aggressive goals.

But the point is, what you are trying to do is not based on an outcome. You aren’t thinking about losing 30 lbs for example. You’re trying to establish a habit, one that sticks. Dr Fogg for example started with doing a single pushup every time he went to the bathroom. Five or 10 pushups would have been too much – a single pushup was just right for that low activation energy target. And a year later – lo and behold, he’s doing 50 pushups a day, easily and without much effort.

So to create lasting change, we want to change that big “J” shape to a bunch of little J’s. Something like this:

Change means risk, and risk means… well, you know. A lot of companies attempt the “big push” like this – calling it a “DevOps transformation”, or a Digital Transformation, or a Cloud Migration. Most will end up in failure, and the reason why is simple: too much change is happening too fast, and often their measures of success are targeting outcomes. They’re not thinking about habits, and they’re not taking into account the constraints of the enterprise. Put simply, change means risk – and most enterprises have a long successful history of operating in a certain way. A company like that simply does not pivot on a dime.

That’s why you’ll see many of the people presenting at DevOps events working elsewhere a few years later. Change is risky. If we fail in financial goals, we end up in debt to credit cards, discouraged. If we fail in health goals, end up on the couch, frustrated, apathetic, risk health. And if we fail in managing change for our company, make promises we can’t deliver on, that’s a career ending decision.

Here I have to give a shout out to my favorite local gym, 3 Peaks Crossfit. About 8 months ago, I started going, and I hated every day. Some weeks I could only go a few times – but I told myself I’d give it a year to see if I could make this one habit stick. They do a few interesting things:

  1. They are all about building habits. So it’s encouraged to sign up for classes, so you’re accountable – and to come in as often as possible. Daily is best.
  2. They have a whiteboard on the wall, where you write down what you lifted, or your time. It changes every day, but over time you can clearly see progress.
  3. The workouts can be tuned so that anyone at any fitness level can participate. Some people do full-on pullups – others stay on the ground and swing their legs. But, everyone is moving, and no one is stretched too much beyond their limits.


Think about how to make your goals small and achievable. Remember the three keys for success with lasting change:

  • Small and achievable
  • Simple and clear
  • Habit oriented, not about outcomes.

What does that look like in DevOps? It could look something like the following:

I just pulled out a few sample limiting factors, and what might help address that pain point. But making this even simpler – if we treat the delivery pipeline like a garden hose, the problem COULD BE in the middle somewhere. Say it’s not using version control for our environments (DevOps has been defined as ‘coding for Operations’), or infrastructure as code. Or maybe it’s a worthless or missing test layer, so our deployments constantly fail. But quite often we find it’s the beginning or the end of the hose that’s the problem. Maybe we’re making guesses on what features will be valuable, so 75% of our development is being wasted. (Imagine being able to multiply your dev staff by 4x! That’s what HDD can offer.) Or we have no blameless postmortem process, so bugs keep getting swept under the rug and problems keep getting repeated. Or there’s no telemetry or monitoring to knock down problems quickly and keep our availability up.

Enough with the nerd stuff though. Getting back to that gym, and what makes it special – they’ve got a list of values on the wall. It calls out specifically that negative talk, about ourselves or others, is not allowed. Crossfit recognizes that out of our thoughts come our abilities. So let’s be careful about labels. If we think and say things like:

  • “I’m stuck in a rut.”
  • “I never get ahead.”
  • “I’m lazy.”
  • “I’m incompetent.”
  • “My boss hates me.”
  • “I can’t because…”

We are creating a negative feedback loop, reinforced by the language and labels we give ourselves. But if we say:

  • “I love learning.”
  • “I’m capable of anything.”
  • “I always do my best.”
  • “I’m a great teammate.”
  • “In this one area I can…”

Whoa, that’s a different story! That’s a self-reinforcing, virtuous cycle. The fact is, ANYTHING is possible with enough practice and consistent effort.

Anyway, that’s my positive thought for this Friday. You can do ANYTHING if you set yourself up for success, one habit at a time.

Want video or audio of this? Check out our podcast using Apple, Google, or the podcast host of your choice – and also on my Youtube channel. And, of course, there’s more like this in my book. Enjoy!


Interview with Abel Wang – Part 3!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it! (Click the links here for Part 1, Part 2, and Part 3)

Check out Part 1 and Part 2 for more… but this discussion is muy caliente! We talk about testing, the power of feature flags (Abel’s a tireless advocate for LaunchDarkly, one of our faves), how eliminating flaky tests is key, and Dynatrace.

  • [1:00] – The power of feature flags
  • [3:03] – Capability matrixes
  • [6:00] – “Quality used to be something we just worried about at the end of the project… You just can’t move at speed without unit testing!”
  • [9:41] – Unit tests are for regression errors.
  • [12:08] – killing flaky tests – is a “red” build really red?
  • [15:00] – Azure DevOps’ unique advantage in dogfooding – we can be our own guinea pigs with release rings!
  • [19:10] – Dynatrace and the unbreakable release pipeline – using AI to catch and roll back on issues quickly
  • [20:55] – What does the future hold? We look into a crystal ball and think about where we’ll be in 10 years.
  • [22:50] – Is lift and shift an antipattern?


Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.


Links to live by:

Interview with Abel Wang, Part 1!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it!

(Click the links here for Part 1, Part 2, and Part 3)

I love the energy Abel brings to the table, and his background as a serious coder makes his advice both pragmatic and spot on. He’s a fantastic speaker as well, if you’ve ever had the chance to catch him at a conference. (Check out his latest from Build 2018!) He wrote the foreword to my book, and with our conversation we got a chance to revisit some of the things we love most about DevOps and where we see the movement going in the future.

A little bit about Abel – he’s a Senior Cloud Developer Advocate specializing in DevOps and Azure with a background in application development. He is currently part of Donovan Brown’s League of Extraordinary Cloud DevOps Advocates. Before joining Microsoft, Abel spent seven years as a Process Consultant and a Certified Scrum Master helping customers globally develop solutions using agile practices and Team Foundation Server. Prior to that, Abel founded and sold his own software company. Abel’s a lifelong coder and I think you’ll find this conversation very interesting… We cover a lot of ground in this episode, so much so that I split our talk into three parts.

Part 1 includes the question that got Abel first thinking about DevOps, how to get CXO buyin, the power of one success story, the #1 pitfall he sees with change efforts, and do we really need QA?

  • [1:00] – How little habits build up to success
  • [2:24] – The question that got Abel thinking about DevOps (why do some projects succeed and others fail?)
  • [6:30] – Getting CXO/director buy-in
  • [10:20] – All you need is one team, one success – it catches on like wildfire!
  • [13:20] – Start with what hurts the most! And Abel’s #1 rule for success
  • [17:55] – Do we really still need that QA department?
  • [19:26] – Knowing what we don’t know, and experimenting.


Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.


Links to live by:

Interview with Abel Wang, part 2!

On our podcast this week, we get a chance to chat with one of my good friends Abel Wang from Microsoft. This one was so GOOD we had to stretch it out into three parts to make it fit our podcast. You’re gonna love it!

(Click the links here for Part 1, Part 2, and Part 3)

Check out Part 1 and Part 3 for more…

  • [1:00] – Painful! Dave finally pronounces “hypothetical” correctly…
  • [2:24] – How does Microsoft power their experiments with telemetry? Abel talks about “doubling down” on success.
  • [5:39] – Engineers, stop negotiating on quality! Abel covers how to deliver estimates so unit testing and telemetry aren’t always on the chopping block.
  • [12:16] – “Quality is nonnegotiable… Quality has a cost. You have to be willing to pay it.”
  • [14:40] – “Not enough people are adding security to their release pipelines.”
  • [16:00] – We talk about pipelines, and how to handle managing interdependencies with versioning. “The complexity is well worth the cost!”


Click below to check out the podcast. We’re on all the major platforms now, including Anchor, Apple, Google, Spotify, PocketCasts, and RadioPublic.


Links to live by:

Achieving DevOps!

Most of the companies we engage with are stuck in neutral when it comes to DevOps – and for good reason. DevOps involves change, and that carries with it a huge amount of risk. And most of the people we engage with are not directors or CEO’s, but can only control one part of the company.

There’s hundreds of books out there on the subject of Agile, DevOps, and improving the flow of value with software delivery. But the vast majority of them come with some assumptions: that our company is small, can pivot quickly, and has minimal legacy software to support; and secondly, that we have sweeping powers to create lasting change across an entire company. Following this advice blindly leads to overoptimism and defeated expectations, just like with a New Year’s resolution – we are trying too much, too fast, and thinking in terms of outcomes versus habits. The result, predictably, is disappointment and frustration, and a shortened career path.

This book helps answer those two big questions – “Where do I start?”, and “How can I improve the way things work around here without risking too much?” We follow one development team as it begins to build momentum with small, safe, progressive steps across a single year. Here’s some of the topics we discuss in the book:

  • What can we learn from Alcoholics Anonymous, and the power of using tiny habits to change behavior?
  • Taming the legacy monster with a truly effective test layer – without flaky or long-running tests
  • Using Hypothesis-Driven Development to multiply your development firepower 5x
  • Finding the pinch point with a few hours, a permanent marker and some sticky notes
  • What is the BTE ratio, and how has Microsoft been able to use that to control runaway technical debt?
  • Are cross functional teams really necessary? Do we really need to break up a successful, long-running organization to make DevOps work?
  • Building security into your development lifecycle
  • Runbooks, automation and livesite support – building the best possible triage system

Along the way, we feature interviews and case studies with thought leaders from Chef, Google, Humana, Micron, Microsoft, Puppet, Raygun, and others. The lessons and stories in this book can help you get unstuck and get your software delivery and support teams deliver more value with less waste!


Case studies and interviews with thought leaders make up a significant portion of the book. Here are some of their quotes:

  • “The saying we live by goes, ‘you can’t cheat shipping.’ If you deliver working software to your users at the end of every iteration, you’ll learn what it takes to do that and which pieces you need to automate.” – Aaron Bjork, Microsoft
  • “DevOps isn’t art, it’s just hard work. Focus that hard work on the things that really matter.” – Nigel Kersten, Microsoft
  • “DevOps is an emergent characteristic. It’s not something you buy. It’s something that emerges from a team when you are doing all the right things behind the scenes, and these practices all work together and support each other.” – Jon Cwiak, Humana
  • “There was no magical fairy dust for us. It required progressive change, some very conscious hard engineering changes, and walking the walk.” – Sam Guckenheimer, Microsoft
  • “Often times CTO’s and CIO’s catch fire and announce that they’re going to reorganize with cross functional teams. Don’t do that! Think about your DevOps or SRE transition in the same way that you’d release software.” – Seth Vargo, Google
  • “One of the biggest failure points I see is that people often don’t make their work visible enough. If you don’t know what people are working on across the team, that creates a natural siloization which reduces your ability to collaborate.” – Michael Goetz, Chef

Achieving DevOps In The News

Contact Information and Bio:

Bio: I’m a Senior Application Development Manager (ADM) working for Microsoft Premier. As a development lead and project manager, I’ve spearheaded cultural revolutions in several large retail and insurance organizations making the leap to Agile and Continuous Delivery. I’m an enthusiastic promoter of Azure DevOps, Chef, Puppet, Ansible, Docker, and all other tools – but I believe very firmly that, as with Agile, the exact tool selected is less important than having the people and processes in place and ready.

On a personal note, I’m the proud father of two beautiful girls and have been married to my lovely wife Jennifer for 24 years, and am based out of Portland, Oregon, USA. I enjoy fishing, reading history books, and in my spare time often wonder if I should be doing more around the house versus goofing off. I’m on LinkedIn, post to my blog semi-frequently, and am belatedly on Twitter too… 


Production Information:

  • Title: Achieving DevOps

  • Author: Dave Harrison and Knox Lively
  • Contributors: Ron Vincent, Abel Wang (foreword)
  • Publisher: Apress
  • Publication date: May 23, 2019
  • Available at:, Barnes and Noble
  • ISBN: 1484243870 ISBN-13: 978-1484243879 (include both your e-book and paperback)
  • Retail Price: $24.55 ($23.32 Kindle)
  • 532 pages
  • Genre/subgenre: Software engineering / Enteprise development