Welcome to my talk: the Five Love Languages of DevOps.

Who am I? My name is Matt Stratton. I'm a senior solutions architect at Chef Software. I live in Chicago; Chef is based in Seattle — we're all over the place. If you want to learn more about Chef, we have a fancy little table with lots of swag, so come see me. I am the co-host of the Arrested DevOps podcast, so if you're into podcasts and DevOps, you should listen to it. Come by the Chef table or just see me at some point and get a sticker for your laptop. We actually have an episode releasing in the next couple of days about seasonal scaling — we had Rob Cummings from Nordstrom and someone from PayPal, and they talked about things they've been doing for seasonal stuff and it was really cool. I'm one of the co-organizers of DevOps Days Chicago, so I know everything that the organizers have gone through to put this event on and I'm super impressed. I'm really proud and humbled to be one of your speakers today. And yeah, that's my license plate — if you see the Illinois DevOps license plate, that's me. My Twitter name is @MattStratton, and that's kind of where I am everywhere you want to find me.

So we're going to talk a little bit about what is this DevOps thing anyway. I kind of bring this up because I give this talk to lots of different kinds of people and I always find that — first of all, I'm just going to ask a question: how many people here is this your first DevOps Days event? First time at DevOps Days? This is actually super common even in places like Austin or Silicon Valley that have been doing them for five years. So many people, it's their first time, which is awesome. The point is, some of this may be a little bit repetitive for some people who've been jamming on the DevOps thing for a couple of years, read DevOps on Reddit, and listened to The Ship Show and DevOps Cafe. I'm just going to say that's okay because maybe not everybody knows all these things, but we're going to get some common vocabulary so at least we're speaking somewhat the same language.

A while ago when I was writing this talk — the first time I put it out there — I had people tweet with the hashtag "DevOps is not." These are just some examples of what DevOps is not. So DevOps is not copy-pasting answers from Stack Overflow. It's not just reading the Phoenix Project, although you should read the Phoenix Project. It's not a ten-times Rockstar engineer, and that goes back to something Cote was talking about as well. It's not just developers on-call. And it's not your effing khakis — that's my favorite one.

What I think DevOps is, and I happen to agree with the way it's been put out on the Chef side: DevOps is fundamentally a cultural and professional movement which is focused on building and operating high-velocity organizations, and it's born from the experience of the practitioners. That's what's in something called Chef Style DevOps. Adam Jacob, the guy on the right, is the founder of Chef. He gave a talk last year about it — you'll see the links, you can go watch it, it's super fun. But what does this mean? It's not just about culture, it's not just about automation, and it's really something that maybe was created by web practitioners and tech practitioners. Maybe this was born out of the unicorns, but it's really adopted by everybody. That's a lot of what Cote was talking about. At this point, equine metaphors aside, everybody's a sparkly horse is the way that I look at it.

There's a book out there by a guy named Gary Chapman called The Five Love Languages. I've read part of it, but the gist — and I think I'm going to get this right — is that everybody has a different way that they communicate love to different people. Those five are: words of affirmation, acts of service, receiving gifts, quality time, and physical touch. That's as much as you need to know about the specifics. The point is that there are different ways, and obviously if my girlfriend identified her language as acts of affirmation and mine is around receiving gifts, I'm going to say "the way that I show you I love you is I'm going to buy you an Apple Watch," and she's going to be like "I don't really care about that; you're not actually speaking the language I want." The gist of it is you can't expect other people to change their language to yours — you have to learn how to speak their language. Which is funny, I guess, if both you and your partner are reading the book at the same time — I don't know, maybe that's in the part of the book I didn't read.

How does this have anything to do with shipping software? One of the things you'll find is we talk a lot about this word called empathy in DevOps — in fact, to the point that some people who consider themselves the enterprise DevOps people will actually make fun of it. "Oh, DevOps Days is all about empathy, it's all hippy hug-ops." The thing is, empathy does matter. All empathy means is having an understanding of what someone else is going through — not sympathy, not "oh yeah, that must suck," but actually "I understand it." The reason that matters is not just so we can be great people who work great together — that's important — but it helps us design solutions and understand process, because I have to understand where my stuff begins and ends and where yours does and where they overlap.

The book The Five Love Languages is basically about being empathetic. But what's really important is that we need to talk about the how — how do we be more empathetic, rather than just saying "go make with the empathy." Kevin Behr, one of the authors of the Phoenix Project — I wish I had the exact quote — said something to the effect of "if I see one more DevOps talk about empathy without any science backing I'm going to table-flip." Well, I don't really have science, but at least I pretend. So that's better.

I'm going to use a definition or a way of talking about DevOps called CALMS. You may have also heard it referred to as CAMS. Basically where this comes from is after the first US-based DevOps Days, which was in Mountain View in 2010, Damon Edwards and John Willis kind of came up with this term CAMS. If you hear them tell the story, it was a thing they came up with at the bar writing on the back of a napkin — as all great things do. CAMS stands for Culture, Automation, Measurement, and Sharing. A little bit later, Jez Humble added an L standing for Lean, which makes it turn into CALMS. My friend Jason Hand at VictorOps thinks it stands for Learning — it's okay, we're still friends — but for purposes of my talk we're going to talk about it as meaning Lean.

So we'll start with the C, which is Culture. A lot of people are going to tell you that culture doesn't matter. In fact, there's a gentleman who I generally have a fair amount of respect for but not on this particular aspect — he's in that enterprise DevOps camp, spouting that there's a difference, and I don't think there is. I think DevOps is for everyone. But he is fond of saying "culture is for yogurt," and I don't care for the dismissive thing. Culture is important because culture is about people, and people are doing the work.

A fella named J. Paul Reed has talked about how it's not important to change your culture but mostly to ensure that your culture is consistent, and that's absolutely true. It's very difficult to change the culture of an organization no matter how big it is — this is not like a JPMorgan Chase versus a ten-person startup difference. Actually, JPMorgan Chase may be easier than a small startup sometimes. In order to make a massive change to culture, that can usually happen when you bring in brand new executive management that can come in and lay down edicts and things like that. The good thing is, it's not about making these 180-degree changes to our culture. The thing that's more important than anything else is making sure that culture is consistent and aligned with what's important to the organization, because culture can also have a lot to do with the personality of the organization.

Organizations have different personalities, and you can probably identify the one you're in. There's one for example — a common personality type of an organization is consensus. If you work for a company where you have meetings about meetings to decide if you have a meeting about a meeting, you work in a consensus-oriented organization. The tricky part is when organizations think their personality is one type but it's another — that's where that consistency comes in. I worked for a company like that where we believed we were a result-oriented organization. A result-oriented organization, as its name would imply, is one who's about: let's get a result, let's ship, let's sell, let's do all this stuff. But the reality was, when you deconstructed it, we were absolutely a consensus-based organization. We spent so much time making sure that everybody felt good about everything together, and we actually never had any results. So we kind of had this split-brain problem.

The first thing is: understand the personality of your organization and make sure you're aligned to that, and then figure out how you're going to enable the behaviors. Lloyd Taylor, VP of Infrastructure at Nextdoor, says you can't directly change culture — you can't just say "our culture is now this." What you can do is you can change behavior, and behavior is what drives culture and what becomes culture. How do we change behavior? We change behavior by changing incentives.

And I will give you an example of why you can't just dictate culture. I had a director at a job after I left Chase who happened to run in the same social circles as Jamie Dimon and was at a dinner talking to Jamie. He asked him "how do you attribute your success?" And he said "don't hire assholes." And I heard this story and I was like, yeah, that maybe is your direct hires, but I've worked with a lot of people at Chase. The point is, you can't dictate it. But what you can do is you can change behavior, and behavior is what drives culture.

Even those incentives may be counterintuitive. A good example of this is Etsy. Etsy has a type of behavior they like to reward. One example would be: we want to reward transparency. That's generally true of Etsy — if you've ever heard them talk about blameless post-mortems and how they're transparent at Etsy, that's an important behavior they want to reinforce. Let's say you're an Etsy employee and you get an email with a phishing link in it, you accidentally click on it, and you cause a security problem. You go to the security team and say "hey, I totally screwed up and I clicked on this link." What happens? The security team doesn't say "you idiot, why did you click on links?" They say "here's a $25 Etsy gift card, thank you for telling us," because it encourages transparency. It says: hey, it's going to happen, people are going to mess up, but if you don't tell me we have a much bigger problem. Similarly, they give out — I think it's monthly — what they call the Three-Arms Award, which is basically the person who screwed up production the worst. It's not a "haha, make fun of you" award; it's actually something you celebrate together, because we all win from it and we all look at that.

So talk a little bit about Automation. This is kind of self-explanatory — this could mean something like Chef, Puppet, Ansible, Salt, or whatever is the latest and greatest thing — letting robots do what robots are good at and humans do what humans are good at. You want to automate your process up to the point where direct human intervention is necessary, because humans are slow. The areas that actually truly require human intervention are a lot less than you think.

A great quote from the book Continuous Delivery, which is now showing its age a little bit but is still very accurate, boils down to: anytime you're asking experts to do boring and repetitive tasks that are technically demanding, it's the most certain way of introducing error short of sleep deprivation or inebriation. This is a problem with a lot of the manual stuff we have to do in technology — your ops folks are doing really boring things but you have to be really technically adept to do them, and you combine those two things and it's a recipe for screwups. So we let the robots do those things.

Automation is not a headcount reduction technique — at least it shouldn't be. It's never a headcount reduction play. Before I was at Chef, I was doing infrastructure consulting and continuous delivery consulting, going out and helping organizations. I would talk to different stakeholders — I'd sit down and talk to the QA people, the product people, the devs, the testers, ops. One of the questions I asked everybody was: "I've got a magic IT wand and you get one wish — what's your one wish?" The devs at company A would have different wishes than devs at company B, and the QA testers would have different ones too. But almost every single ops person had the exact same wish, which was "more people in ops." The thing is, you're not going to get more people in ops. But the reason they wanted more people in ops was because they didn't have any time to do the important stuff because they were doing all the crap. What you do is say: we can't throw people at it, but we can reduce the level of crap that a robot can do well, and that lets your already skilled people leverage their skills appropriately to drive value to the business.

Going back to Etsy — they're an incredibly automated shop, and people will ask John Allspaw, who's their SVP of ops over there, "John, why do you even have an ops team?" And he says, "Are you kidding? They have so much work to do." They're doing all this stuff around making their services more reliable and performant — all the things that an ops person would love to spend their time doing, rather than copying files around and editing templates.

Talk a little bit about Lean thinking. It's a business methodology that lets us think about how we organize our activities to deliver more value, coined by James P. Womack and Daniel T. Jones. It's basically the essence of what they found when they studied the Toyota Production System. When I think about it in terms of DevOps, it's really looking at waste and also looking at how it enables us to be more experiment-focused.

Measurement is what the M stands for, and this is important because it's how do we know that we've been successful. If we don't collect metrics, how do we know that we've moved the needle if we don't know what the needle looks like? You need to start measuring at the beginning of your transition because you can't go back in time and collect information you didn't know you wanted later. We need to know what the important things are, and that boils down to setting success criteria because your DevOps is going to look different than my DevOps. What does my cycle time look like? What's important to my business? What's my driver?

And finally, Sharing. Transparency is key. How many people have read the book The Phoenix Project? No Brents — no single point of failure, no one person who knows all the things. My friend and former colleague Sasha Rosenbaum actually just gave a talk at DevOps Days Silicon Valley called "Single Person of Failure" and it talks about this particular problem — I recommend it.

You also want to share the why behind what you're doing. Mandates are bad. If you're in a position to be dictating, explain why. This is a thing that happens quite a bit as we go up the echelon of management — we feel like "I can't tell you the why because it's protected" or "there's going to be all this argument." Just like the areas that require human intervention are fewer than you think, the areas where you have to keep your cards to your vest are much fewer too. Yeah, maybe there's an NDA — maybe there's an acquisition going on. But you really should be sharing the why, because people will buy into it a lot more if they understand. And a blameless post-mortem cannot happen in a culture without sharing.

So what does this actually have to do with anything? This is how it ties together. Each of those things — each part of CALMS — is each one of the DevOps love languages. That's a big part of the reason I included the L, by the way — so I have five. I usually just talk about CAMS, so there's a little secret for you.

What this means is that it's really important — again, like we talked about in the Five Love Languages — it's much more important for me to learn to talk to the people I'm communicating with and trying to convince, than for them to learn how to listen to me. Let's say I'm trying to drive a transformation in my organization. I've got a lot of people I have to convince to work this way. I've bought into it, I've come to DevOps Days, I've listened to the podcasts, I've read the books, I totally understand why this makes sense. And now I'm going to try to convince my VP of Development, or the DBAs over here, or the testers, or the security folks, and they don't get it. I'm pounding my head against a wall saying "it's crystal clear — why don't you get it?" The reality is, if you ever find yourself saying "this is crystal clear to me, why aren't they seeing it?", the problem is with you, not with them. Again, my DevOps love language might be different than yours. It's not enough to get someone to do it — they have to understand the value in their own language.

Patrick Dubois, who was one of the people who arguably coined the term DevOps — you could say it was Patrick or Andrew Clay Shafer — anyway, Patrick about a year or two ago said we should rename DevOps to "common sense." And I said no, you can't do that, because I would have to get new license plates. But that's sort of the problem, right? Once you get DevOps, you're like "yeah, this is just common sense." People say "I've been doing that all along, I just call it work." But common sense is usually in the eye of the beholder. It's a relative term. It all becomes common sense once you understand it.

So let's think about how we identify somebody's particular DevOps love language. How do we understand how we're going to talk to them? One of the things that helps is thinking about their communication style in general. A tool for doing that is something called DISC. If you're familiar with Myers-Briggs, it's similar to that. I like to talk about DISC because you can do a relatively quick assessment of someone. I can spend a little bit of time talking to someone and I'll understand where they fall. Basically you fall somewhere in a quadrant: D stands for either Dominant or Direct depending on how nice you want to be, I guess; I is Influencing; S is Steadiness; and C is Conscientiousness. What I've found is that depending upon your communication style, it actually influences which DevOps love language makes sense to you. Your quick assessment of someone on the DISC scale could be wrong, so keep that in mind.

For example, if someone is D — Direct — the things that resonate to them more are the Lean and the Measurement parts of CALMS, because a D is a results-driven person, a "we'll figure it out along the way, let's just get going" kind of person. I am a high D. Fortunately, when I managed a team, they were not Ds, and that's a really good balance because they help you not run off the cliff. Someone who's a D wants to see how the change you're doing is going to move the ball forward, and they're also likely to be more influenced by experimentation because they're like "okay, I just want to see the result, I don't really care how we get there, we'll figure it out as we go." You start preaching culture and automation to a D and they don't care as much, because they don't care how the sausage gets made — they're like "that's fine, automate whatever you have to do, but show me results. Show me on the graph that we did some stuff."

Influencing. People who are high I tend to be more social communicators — that doesn't necessarily mean they're more friendly or anything like that, but they interact more and they respond more on the culture and sharing side of CALMS. High Is tend to like consensus and they like collaboration. If you're someone in that kind of model, you're going to get a lot more out of "hey, we're doing this thing and we're sharing our information, that makes a lot of sense." You talk about lean or automation and the results-oriented stuff — especially automation — tends to not resonate to someone who's an I.

Steadiness. S types are folks who like stability. It doesn't mean that they fear change — I always think about Garth from Wayne's World with "fear change" — that's not an S. An S just likes to understand stability. They want to be sure about change and be comfortable about it rather than just do it. Automation resonates really well with S types because it gives a lot of safety, a lot of understanding of what's going to happen. Measurement is really resonant to an S because "I know what's going on, I can understand what happened." Lean is probably the antithesis of an S, because it's talking about making a lot of experimental change. The end result of Lean thinking is actually something S types will really like when it's done, but getting there that way can be kind of scary — or at least uncomfortable.

Conscientiousness. C types are what I call the "measure 15 times, cut once" folks. Not to make stereotypes or anything, but most operations people are high Cs, most data people are high Cs. That's why when I managed an ops team it was great that I was a high D and they were all high Cs. You get a whole bunch of Cs and no change gets made because we want to measure every single thing and be absolutely sure about all of our data before we do it, and the D goes "I don't care, let's just figure it out." So we help each other. Sharing and measurement help a lot with Cs because they want all the information — they love data. Culture is less of an impact. Automation is helpful but only as it drives measurement.

So if you're working with someone you're trying to get them to understand why this change is helpful and you know they're a data-driven person, don't go talk about "hey, we're going to be empathetic and hug-ops and all this stuff," because they don't give a damn. Talk about how we're going to be able to see the needle move, we're going to be able to see results, and we're going to make decisions based on results — and they will love it.

So we need to assess the drivers. You need to understand what makes a person tick. There's a great book by Daniel Pink called Drive: The Surprising Truth About What Motivates Us. Like we talked about with all business books, you could actually just watch the TED talk for free and get almost all the value out of it. The link will be at the end. It's about understanding what's important because what's important to me is going to be different than what's important to you — not just because of our communication style, but what makes us get out of bed in the morning, what makes us do things. Am I recognition-oriented — do I do things because I want to get lots of followers on Twitter and have everybody retweet me and call me a great expert? Yes. Or is money a motivator? Because it is to some people. To others it's not. And it can be a matter of: if you're not a money-motivated person, me saying "if you do this thing I'm going to give you a huge raise" — no one's going to say "do not give me money," but it's not really going to make me make a real change in how I work. Punishing me by taking money away may not have an impact either.

So you need to understand what drives a person. This is really tricky because we also need to think about conflicting incentives. Besides the personal drivers, think about the drivers that your organization has kind of influenced into that behavior. Traditionally you think about: how are development teams incentivized? They're incentivized by shipping features — you ship more features, the better you're doing. How are ops teams incentivized? Uptime — the more the system is up, the better you're doing. I had a colleague who was a director of ops whose bonus was a percentage of the site's uptime. What causes uptime to go down? Change. Do you think she was incentivized to allow any changes to her systems at all, even if she thought they were good ideas? No, because she was also a money-motivated individual, so that was money out of her pocket.

The problem is, if we think about it, our driver is really the same thing, which is "to sell shoes" — provided that's what our company does. The purpose of a developer is not to write code and ship features; the purpose of an ops person is not to keep the site up — only insofar as it services the greater goal of the organization, which is to make money. We need to figure out how that happens. If you've read the book The Goal, that helps you understand that. The thing is, changing these micro-incentives is not always the right thing to do, because incentivizing people appropriately can actually help. If you ship changes at a higher velocity, that actually does increase the stability of your system. And caring about uptime and stability does enable people to ship more features because they're not caught up in troubleshooting. So again, they're complementary incentives even though they may seem contradictory. Remember that people will always work towards the incentive you give them even if it will destroy their organization — that's the Nash equilibrium. So be cautious of that kind of thing.

The other thing is: if you want to make a change, you've got to be a salesperson. There's a book for salespeople called The Challenger Sale. The whole book can probably be condensed down to this one quote: someone who's a challenger has a deep understanding of their customer's business, uses that understanding to push the customer's thinking, and teaches them something new about their company. That's the same thing you need to do — you need to understand your company and your organization and be able to sell it to the decision-makers, the people who are your stakeholders. You might have to actually teach them something about their part of the business that they don't even know. This is hard if you don't like being a salesperson — find a buddy in your organization who does. Again, talk their language.

You want to look at your key influencer as a client rather than as your boss. If your client who happens to be your boss shoots down your ideas and offers a counter-plan, you have to be ready to channel some boldness and stand firm in your beliefs. You don't want to necessarily argue back and forth, or worse, just back down because of their position above you in the company. You could say something like "hey, I understand what you're saying, but if we go down this route, here's some statistical information, here's what is going to happen." Again, it depends upon the type of person they are how you respond to that, but you have to talk their language when you're selling.

One thing that's really important is this idea of compliance versus commitment. This is the problem with mandates. I can be the CIO or the CEO and I can come down and say "this is how we're going to do stuff, do it this way or you don't have a job." And you know what's going to happen? People will do what you say because they want to have a job — that's called being compliant. The compliant person is one who signs documents, puts their time in, does their TPS reports, punches the clock. And they might continue to do that even if it's something they don't believe in, because they need the job, they don't feel like they have other options, maybe they're too lazy to leave — whatever the reason. They'll make the changes but they won't really care about it.

Someone who's committed, on the other hand, simply believes in the TPS reports because they actually do believe this is the right thing. They're dedicated to the idea of change and they're committed to the success of the company. As you have more commitment, the success of the company grows exponentially. This is the one thing to me that goes back to the C in CALMS. When people talk about doing DevOps in the enterprise and say "culture doesn't matter, it's for yogurt" — they say it because they feel like you can't measure culture. This is how you measure culture. Unfortunately, you can't put a Nagios agent on your people to see how committed or compliant they are — you actually have to talk to them and evaluate them. But commitment versus compliance is a metric to evaluate.

The best change influencers are people who don't see other people as something you have to deal with. They're change agents who are actively interested in people and who enjoy the pursuit of the how more than the change itself. If this isn't you, then maybe you're not a change influencer — but you probably know somebody who is in your organization. They can help you. If you look at people as a blocker and an annoyance, it's really hard to be a change influencer.

Finally, bring people along for the ride. I've talked about not dictating. Let your influencers and your stakeholders take part in that — make your tent big. If you look at the transformation that GE Capital did, they didn't just say "this was a thing we're doing inside DevOps." As they were building it, they invited security into the mix, they invited testing — they said "we're going to talk about this." Maybe you don't start by saying "we're having the DevOps project and we're going to do this." Start by saying "hey, we have some brown bags, once a month or every two weeks we get together for lunch and let's talk about how things could be better." The trick of that is don't let it be a venting session. Keep your arms around it — it's not just "let's sit down and complain about how everything sucks." Let's, as a group, figure out where our pain points are, where our bottlenecks are. We can all talk about how we got where we are, but this is about moving the needle forward. We only care about the present and the future — we don't care about the past.

So we've got a couple minutes for questions, comments, problems with your life. I'll put this up with a couple links to reference. We did an episode of Arrested DevOps all about culture change that talked about a lot of these items. I'm @MattStratton on Twitter, I'm mattstratton on GitHub, and I also have the link to the TED talk. I think they'll put this all up later and you can check it out. Thank you.