As I said in response to another comment in this thread, I don't often share my slides without the context of the recording of the talk that went with it. That recording isn't available yet, but these slides have more words than most of the ones I present usually do so I thought I'd share them.
In my talk, each of the main points was accompanied with an anecdote to give some background on the experiences that led me to believe them, as well as some expand on the content of the slide.
The talk was specifically built for an audience of attendees of the DevOps Enterprise Summit. It's a fantastic event with one of the most thoughtful and engaged group of attendees I've experienced, and I've been to a lot of conferences. These folks are, generally speaking, development or operations leaders at enterprise companies who are in the midst of a transition to a style of work that's a significant departure from traditional enterprise IT. Since much of what we call DevOps now is built on the way that many of us in the world of startups and Internet companies have been doing things for a long time, Gene Kim asked me to share some ideas that I think are universal.
It was one of the most fun talks I can remember since I was given the license to tell stories. ;)
And yet, from a short list of a dozen or so aphorisms (and not clichés), the same mistakes are made over and over again, which is why you hear them over and over again.
Everyone's heard "practice makes perfect" until it's become tired and overused, yet when's the last time you practiced restoring from backups from scratch onto a fresh machine? How sure are you, that there isn't a setting in `/etc` before it's usable in production and isn't in puppet/chef/ansible?
Or practiced failing over by firing up a entirely new cluster in a new AZ (and a new set of AWS keys), and failed over to that?
From this slide deck in particular, "Fight Hero Culture" (slide 6) isn't one that I've managed to take to heart (but I'm working on it), and I still don't like apologizing, especially when I was wrong (slide 11).
You might think about the "cliche" "Empathy is a core value" (slide 13) and think about how you might apply that to your comment.
I hope a video of stories from the actual talk is posted soon!
I don't tend to recite my slides, so your prediction that the talk was more insightful was ... insightful.
Each of the slides was accompanied with an anecdote that attempted to both illustrate the point and to provide more background about why I think it is important.
If there was something specific you disagree with, I'd be happy to talk more about it.
- Slide 10 "Make it safe to learn", we all know that a blame culture still plays a big part of many organizations, and we all need to work against that to enable honest discussions about failures.
- Slide 13 "Empathy is a core value", if you cannot understand why the other guy is pissed off about some issue, you will struggle to care about fixing it. Put yourself in someone else shoes for a change.
- Slide 18 "Build a culture of shipping", focus on deliveries not dates.
- Slide 20 "Do the simplest thing that could work", most engineers will jump to the complex solutions first (myself included), learn to test the obvious first.
- Slide 21 "Beware the illusion of agreement and be explicit", just because someone is silent in a discussion does not mean that they are in agreement. They might work against the consensus as soon as the discussion is over.
The part about "hero culture" that needs to be said more often is that you need to reward the teams that have boring and predictable production environments rather than the ones who put in heroic efforts to keep unpredictable and blowup-prone production environments working.
I've seen way too many orgs be appreciative of employees that give over-the-top efforts without appreciating those that plan, test and deliver in a fashion that makes over-the-top efforts unnecessary.
Not sure if that was part of his spoken presentation, but it didn't make into his slide.
I generally don't like to post decks without the recording of the talk and I was kind of surprised this one got shared as widely as it seems to have been. I'm glad you enjoyed it.
As I said in response to another comment in this thread, I don't often share my slides without the context of the recording of the talk that went with it. That recording isn't available yet, but these slides have more words than most of the ones I present usually do so I thought I'd share them.
In my talk, each of the main points was accompanied with an anecdote to give some background on the experiences that led me to believe them, as well as some expand on the content of the slide.
The talk was specifically built for an audience of attendees of the DevOps Enterprise Summit. It's a fantastic event with one of the most thoughtful and engaged group of attendees I've experienced, and I've been to a lot of conferences. These folks are, generally speaking, development or operations leaders at enterprise companies who are in the midst of a transition to a style of work that's a significant departure from traditional enterprise IT. Since much of what we call DevOps now is built on the way that many of us in the world of startups and Internet companies have been doing things for a long time, Gene Kim asked me to share some ideas that I think are universal.
It was one of the most fun talks I can remember since I was given the license to tell stories. ;)