Pauly Comtois

Okay, so three things to start.

One, I have 60 minutes of material and 30 minutes to present it, so I'm going to talk a little fast, so I apologize.

Two, thank you to the DevOps Enterprise Summit folks, and especially Gene Kim, for asking me to come out here and speak. It's a huge honor and a privilege.

Three, thank you all for coming out and spending 30 minutes you'll never get back with me. And it takes a lot of courage, frankly, to come to a talk knowing that halfway through, you're going to be randomly selected for karaoke.

And special thanks to this gentleman up front who's volunteered to go first.

My name is Pauly Comtois, or at least I think that's how it's pronounced. I'm not really sure. It's really hard to spell, and it's impossible to pronounce, so everyone just calls me Pauly. I suggest you do the same.

A little about me. I'm a veteran. I spent 10 years in the Air Force, working on the stealth fighter. I'm a systems administrator and a developer for as long as I can remember. I was even a network administrator for a period of time, really more out of necessity because no one else would do the job.

I love coming to conferences like this one, where I get to rub shoulders with folks like you and learn and grow. And I haven't ever seen such a group of amazing, talented, intellectual, and beautiful people. And if that sounds like pandering, it is, because I really want to get a good review on this so that I can be asked back next time.

I call myself a DevOps therapist really for two reasons. The first is that I really feel like DevOps is really a culture. It's about people, it's about process, but more so, it's about culture and relationships. And two, I really kind of wanted a couch in my office, but so far that hasn't happened either.

I work for a company called Hearst. Hearst is a phenomenal organization that purchases other businesses and then invests very heavily in their success. I was brought on to help with that, specifically around Lean and Agile and DevOps, and so really looking at transformational change.

I realized, however, that we were seeing incredible amounts of success at the individual business unit level, but those were pockets of success. And we had a great opportunity to then take that and grow it out and build a community, and really start leveraging what we were seeing within one business unit and creating a much broader ability to scale and be flexible.

And so that's kind of what I'm going to talk about today.

So we're going to start with culture, or as I call it, the truth about talking sticks, trust falls, and patchouli. And it's sort of a tongue-in-cheek jab at the fact that a lot of people believe culture is something that's impossible to measure and impossible to change. But in reality, it's possible to do both. It's just glacial. Your culture tends to get set quickly and then change very slowly over time.

So I started thinking about how could I bring about the type of culture I wanted for Hearst Business Media, specifically across all these 10 business units.

I worked at a company called Chef for four years as the VP of Operations. Some of you may have heard of it. It's become quite popular. And at Chef, while I was there, we had this great and amazing ability to eradicate the barriers between our internal community and our external community. Instead, we just had one large community where everyone contributed together.

And I thought, "Why can't we have that at Hearst? Maybe just at a different scale, maybe bigger, but the idea conceptually is the same."

And so I really thought about, well, what was it that set that community apart? The biggest lesson and the most important lesson I learned when I exited Chef was the power and value of that community.

So I started looking at HugOps, which is really kind of silly, but it's just that. It's a hug. It's an embrace. And Chef still is really big on HugOps. When I go down and see the folks at Chef, I still hug everybody. It's very common.

Hugs are great because they create this bond. They allow you to focus on a culture that is really about being vulnerable and being okay with that. And I thought, "Well, why don't we look into that?" And that kind of became a cornerstone of what I was thinking of doing.

And the interesting thing: so I'm Canadian, so I'm inherently nice. And so hugs are not weird for me. I'm a big hugger. In fact, hugging is so sort of ingrained in who I am that when I left Chef, before I joined Hearst, I went on a job interview in Manhattan. And I hugged my interviewer.

No, it was powerful. Oh, man. So powerful.

Turns out, not everyone's into hugs. And random New Yorkers, even less so, right? Now, to be fair, maybe I held the hug a little too long, and maybe I shouldn't have hugged that person from behind. But realistically, what I was trying to do was, I was trying to break down barriers and start a dialogue. And it worked really well.

I had this amazing dialogue with this really large NYPD officer from the back of his cruiser. And I learned some really valuable lessons, and that is some people are handshake people. And that's probably something you should figure out before you go into the interview.

But the idea is, you want what the hug signifies. It doesn't have to be a physical hug. When we talk about culture, and especially collaboration in DevOps, it's really about what that hug means, and that means being able to be vulnerable.

So maybe you don't have hugs in your organization. Maybe you have fancy baseball hand signals. And that's fine. You don't have that awkward body contact. But what you do get is vulnerability.

Now, vulnerability here is different, right? I'm not talking about sitting around a table and talking about your love of Barry Manilow and long walks on the beach. I'm talking about the vulnerability to raise your hand and say, "All right, look, I don't really understand the acronym you keep using. And I know I've been here four years, and I probably should know what it is, but I just don't."

Or maybe it's raising your hand at that table with those same peers and your boss in the room and saying, "You know what? I know you're my boss, but I just don't agree, and I want to have a constructive argument, a discourse about this, and see if we can find a better solution."

So that's the type of culture we're talking about.

So what's the difference, then, between culture and community?

So here's the disclaimer time. This is not me representing Hearst. This isn't me representing Chef. It's just Pauly talking.

I believe culture is based around your beliefs. It's a set of beliefs that make up your culture, and then the behaviors that you want to really enforce that drive those beliefs home.

Community, on the other hand, it's about rallying around those beliefs and creating fellowship. They work hand in hand. But in this case, fellowship is really for one reason, and that is support. In our case, moral and technical, that's normally what we're looking for.

Moral support is really about, "Geez, Pauly, I'd like to say that anybody could have deleted the database and the backup simultaneously, but... geez, okay. But it's all right. You know what? It's all right. We're going to figure it out. We're going to do it together as a team, as a community."

And that community doesn't mean one team, it means all the teams, and we're going to fix it. And that's lifting me up and making me feel better.

Now, in practical terms, like at Hearst, and probably a lot of your organizations, we use blameless postmortems to do that. We focus on forward-thinking language. We will fix it. We're going to do it differently. This will be the way we're going to approach the problems in the future.

And we don't focus on what's called counterfactuals. "Well, Pauly, if you hadn't deleted the database, we wouldn't be here." That's true, but there's nothing you can do about it now other than try and fix it in the future.

Technical's a little easier. This is usually when we talk about helping each other out when you have a technical problem. You jump in chat, IRC. You do it face-to-face.

In this case, community's real power is where you leverage the slack in the overall community to benefit you. It sounds somewhat like a negative term, but it's really about everyone helping each other out and paying it forward.

So if I have a problem, and I jump on IRC, as an example, in, say, a Ruby problem in a Ruby community, and I say, "I need some help," someone helps me with the problem. They had just enough time, just enough initiative, and just enough know-how to help me with my issue.

That's very powerful.

And the reason the community is so important, from an evolutionary perspective, we knew early on as a species that we had to have community to survive. We had to work together. It was just the way it was. There was no other way around it.

Now, we're blessed with a limbic system, and I'm going to get very general here on the brain for a second. But we're blessed with a limbic system, which is really the pleasure and reward center of the brain. It's what kind of drives us at a primal level, and that's awesome. But if that's all we had, there's no way we could be empathic. And we're some of the most empathic creatures, period. Incredibly social.

Luckily, we have something called a PFC, or a prefrontal cortex, which allows us to really think of things in terms of logic and abstract thought, judgment, moderation of social behaviors.

And I know what some of you are thinking, because I recognize some of you from re:Invent in Vegas a couple of weeks ago, and judgment and moderation of social behavior is not high on the list of things that you saw there. But everyone has a PFC. It's just probably stunted from maybe too long on the pub crawl, or maybe you were dropped as a child, I don't know.

But certainly that allows us to create community, both for survival and for moving ahead in business. And that community is really about bringing the two teams together and thinking of it as one team.

Community is built on relationships, relationships built on trust.

The thing about techies, I consider myself a techie, is it's hard for us to build relationships. It's just not something we do inherently. It's like this gentleman here is probably working on a Snapchat while she's expecting to be caught.

But it's not something that we can't do. It's just not our wheelhouse. It's not what we think of first. When we think of, what do I identify myself with? I'm a great developer. I'm a great ops person. I'm a great DBA or SAN engineer.

So recognizing that's the first step, and then taking steps to say, okay, let's try and find ways where we can reach out and create those relationships that then become the pillars of the overall community.

My issue was, how do I build trust across a bunch of business units that have no idea who I am?

There's a real danger here of being perceived as someone coming in and taking over. I didn't want to become the Eye of Sauron.

If anyone who knows me in the room, you know I'm really into collaboration and really looking at joint ventures and how can we solve problems together. But I'm from corporate.

So one way I addressed this early on was to use AMAs. Everyone know what an ask me anything is from Reddit? It's essentially you gather everyone into a room. Now, what Reddit does is famous people do it on Reddit. I'm not famous, but famous people will get on Reddit and do an AMA, like President Obama, and you can ask any question that you want, and he'll answer it.

And so I took the same concept and said, "All right, get everyone together, and I'll answer anything that you have. Sometimes the answer may be I don't know. Sometimes the answer will be something you like, and sometimes it won't. But it'll always be honest and transparent."

And in the beginning, you usually get some softball questions like, "What's your favorite color?" "Who's your favorite Pokémon?" Stuff like that. But three, four, five questions in, you're starting to get to the meat. And you get to that one person who's brave enough or angry enough to ask the question everyone's thinking, which is, "Why are you here, Pauly? What's going on? You keep talking about DevOps and automation. Are you automating me out of a job, or are we outsourcing my job? Are we shutting down the business unit? Are we reorging? Am I getting a new boss?"

What they're really saying is, "Should I be afraid? Because I am, but I don't understand why I'm afraid."

So once you start getting that out into the open, then the real questions start coming out, and you start building that trust.

If you start building a community within your own organization, and you're trying to bring two teams together, you need to do something very similar. You have to be very honest. Why are you doing this? I'm perfectly happy in my own little world, and you're talking about disrupting that.

So really talk about the value of why you're trying to accomplish this. It goes a long, long way towards building the trust and the relationships that you need.

And this works really well. It works really well for me because work doesn't flow through me. So I'm a VP of DevOps, but I'm not a silo. We're there just solely to help and aid the business units become more successful.

So we'll get a little Zen for a minute here, but I like the idea of I'm just a drop of water. So we're 25,000-plus employees. I'm just one drop of 25,000 drops flowing in this stream. I'm just along for the ride, along with everyone else. We're all trying to make our way through our life the best we can.

I don't prescribe or demand alignment. That's an Eye of Sauron-type tactic. I don't walk in and say, "I am the VP of DevOps, ergo, everything I say is truth, and I shall impart value upon thee."

So what happens there is that's the equivalent of someone standing at the edge of this stream with a big rock, and they're like, "You know what I'm going to do? I'm going to make a big splash. I'm going to be disruptive. I'm going to make a change. I'm going to make a name for myself."

And they throw that rock into the water. The result of that is some of the water, some of those droplets, are ejected. So that's the churn from that kind of disruption, and they never make it back in.

The other result is what happens is the water just moves out of the way of the rock, lets it sink to the bottom, and goes right back about its business like it never existed.

Because you can't do this kind of cultural change with that type of disruption.

I don't know it all. I don't claim to know it all. That's okay. I don't have to be the smartest person in the room. The reason is we're all smart. We work together, and we collaborate. That type of focus and that type of culture really helps to build a community where people feel, again, vulnerable, and that's okay.

It's okay to say, "I'm not the smartest person in the room." Nobody has to be. All we have to do is be the smartest team we can possibly be.

I consider myself a guide, so more of a Gandalf. Only shorter, less hair, and I think I smell better because I don't think they ever showered on the trip.

And if you think about it, if you follow this analogy through to its natural conclusion, Gandalf felt the same pain and anxiety and fear and uncertainty as everyone else did. He went along the journey. He was a drop of water.

You have to do the same thing if you're going to build a community. If you want to build that trust and have people believe in you and your cause, you have to be in there with them.

For me, it's I go to backlog refinements with the business units, sprint planning, user stories. I put myself on call with the ops team to help with alert fatigue. I'm there with them.

And the great thing, too, about eventually, Gandalf let the team move along. Of course, he fell into a crevasse. I don't recommend you do that. But the idea is that that community will eventually self-govern. It will take care of itself.

It takes a lot of calories to get a flywheel going. It doesn't take a lot to keep it going.

Your community is going to support your culture whether you want it to or not. So think about the culture that you want, make sure you build a community that supports it, and do so with compassion and assertion. And we'll get into compassion and assertion in just a minute, but that's really, really important.

A lot of times people think, "Well, I'm going to build this community, and it's going to be different than my culture." It's just not possible.

So if relationships are the pillars that hold up the community, these are sort of the four fundamental things I see wrong more often than not in any community. And we really want to be mindful of these things to make sure that when we see... They're going to occur. You can't help it. But when they do occur, the idea is that we work towards resolving them, and we do so without a person that's over it.

The community should take care of it itself. They should recognize it.

So being mindful of things like the automatic mental processes that cause group identification. This is literally fifth-grade clique. When one group thinks they're the cool kids and everyone else is not included in that group. And you'll see it. It happens.

We need to be mindful and focus on the similarities between us and them. This is the Venn diagram of us and them. We really want to work on that overlap, push those circles together, focus on the middle, and not so much on the outside.

Create mental categories that include others that you would usually regard as not me. So if you're in a meeting and I'm a dev and you're an ops person, you really want to focus on, look, we're just engineers. We're in here trying to solve a problem. Yeah, I get that you have different jobs. We all know you have different jobs. That's obvious. What's not so obvious is how we can get together and think of ourselves as one team.

And we want to really be mindful of the process of valuing your group while devaluing someone else's.

So I'll give you a real-world example of this.

A VP of engineering friend of mine said, "Hey, Pauly, we're doing some great stuff with DevOps. I'd love for you to come over and check it out."

I said, "Yeah, absolutely."

So I came over, and the first thing I noticed was that the devs and the ops folks were on different floors and separated by four floors. And so I said, "Okay, well, I'm not going to judge, so tell me how you get past this disparity of not having people work together every day."

He said, "Oh, we have persistent chat rooms in Slack."

I said, "That's awesome. Can I take a look at it?"

"Sure."

So we went and looked at the Slack history, and I see a lot of comments like, "Well, that other team doesn't work as hard." And the unspoken end of that sentence is comma, as we do, right? So they're falling victim to this bottom.

Now, you can't tell people not to have an emotional reaction. That's just human nature. It's going to happen. What you can do is, as a community, really think about the implications of that and how we can fix it, right?

Community should step in and tell people, "Look, this is not our behaviors. This is not our culture," right? Our beliefs are that we are all equal.

And so I said, "Well, how do you address this bit?"

And he said, "Well, it's great, Pauly. I'm glad you asked. Actually, what we do is we end up going, the end of the month every Friday, last Friday of every month, we go and have a beer, and that just creates some tight bonds. It's tight."

And I was like, "Well, so once a month. All right. Well, I'm not going to judge, right? What works for some folks may not work for me."

But I said, "Do you mind if I tag along?"

He said, "Yeah, absolutely. That would be fantastic. I'd love for you to come along."

And so we all piled into cars and went to the TGI Fridays, squeezed through the door, and what do you think happened as soon as we hit the inside? Everybody scattered and then started to coalesce, right?

You had your developers over here starting to mold into their scrum teams. Even they weren't talking, right? And they had tables of scrum teams.

Then over here, you had the ops team, right? You had the SAN team, you had the systems team. So the systems guys are up front stroking their beards and squinting at the bright lights and wondering how they got thrust into the day star.

And you've got the SAN team, and they scatter and scare easily, but they'll be back in greater numbers. And you've got the network team who run the firewall. Everybody hates them. No one even talks to them at all.

And then you've got one guy in the corner just kind of bumping his head over and over, and that's the SharePoint administrator.

And so I'm like, "Clearly, you guys are really not focusing on these things."

So we did a lot of work with that. We squished everyone down to one floor, really got people talking, everybody included into every meeting, right? Everyone had a voice. It was okay to call people out. It was okay to argue, even in meetings, as long as the arguing didn't devolve, right?

So there's a difference between arguing and fighting. An argument can devolve into ad hominem attacks, and when it gets to that point, cut it. It's not productive. But arguing is productive.

Okay, so compassion and assertion: the two wings working together to get a relationship off the ground and keep it soaring. It's a very lofty statement, isn't it? It's kind of a lofty goal.

Relationships are hard. You've probably heard empathy a lot this week, and the reason is it's super important, and there's still a huge, distinct lack of it in our cultures. It just is. And again, it's hard, so that's why it's not there, but we need to keep working on it.

One of the things I like is empathy does not mean agreement or approval. This is often mixed up for some reason. "I can't be empathetic with him. I don't agree with his approach."

You don't have to. Recognize that his life is hard, too, and that she has challenges at home. We're human. We're all human in this room, so we all face our own little microcosms of challenges and difficulties, and that's okay. We're not saying waive your rights. We're saying assert your rights, but do so virtuously.

So unfortunately, it cut off my quotes down at the bottom. So, "People remember not what you said, but how you said it." That's Simon Sinek. None of these are mine. I gave credit, but it got cut off. Sorry, Simon.

And so that's not true all of the time, but it's true most of the time. So what that means, essentially, is if you're a jerk, people don't really hear the message, regardless of how much value you're going to add with it. So just think about that when you're trying to communicate.

And what happens is, if you're a jerk all the time, people shut down before you even open your mouth. They're already plugged into something else, right? They're thinking of something else entirely.

And you know when this happens, right? When Bob pops up and makes a beeline to your desk, and you're just like, "Oh, God, here comes Bob. Why can't he just fall down an elevator shaft and die? Hey, Bob," with the face. Still there.

You know that guy. You've worked with him. You've worked for him. Hopefully, you're not him. If you are, please do something about it.

And we judge ourselves based on our intentions and others on their behaviors. It's incredibly true. It's just base-level stuff. We can't help it.

So this is where relationships are so important. If you have a preexisting relationship with someone and they send a chat, now that chat can be interpreted as either really good or really bad, depending on where you put the commas and the emphasis.

Now, if you have a preexisting relationship, you're like, "Ah, it's just Bob. He's snarky. He doesn't really mean anything by it. It's not a big deal."

But if you don't, we immediately go to the bad place. Human nature. Immediately, you're like, "What the hell is that supposed to mean?"

"Bob, that means whatever the hell you want it to mean."

And before you know it, you're both posturing and you're ready to fight, and you're like, "I've got to defend my position. I don't even know what my position is. I'm not even sure what we're fighting about, but I'm damn sure going to win whatever it is that we're doing, and I'm going to punch this dude in the nose."

And it devolves very rapidly, and you're like, "What the hell happened? All I asked was, 'Did you provision the IPs or not?'" But suddenly, I'm taking it as like I don't know my job, I'm an idiot, I don't know how to do IP provision. It's like, that's not what I said at all.

And the reason we go to the bad place, again, from an evolutionary perspective, it was for survival. So if you had an opportunity to get food and you missed it, usually another opportunity for food will come along. If you had an opportunity not to get eaten by a tiger and you missed it, you pretty much usually got the one shot.

So our brain was like, all right, this is more important. Do this first. If this is not it, then we'll come over to the other stuff.

It's really important to recognize, excuse me, the limitations. These are biological things. Recognize that it's going to happen, and then really work on adjusting our behavior towards it.

So I literally wrote this, I think, 35 minutes ago. I didn't realize I had to do the takeaways. But I think these are all very salient points.

Relationships are critical to strong communities. Let's be honest, the relationships are important to everything. How often have you heard of somebody getting a job because somebody asked someone else if they knew someone? It never even hit the posts. It never went to the board or nothing.

Relationships are really important. The problem is they're really hard. They're messy, they're unpredictable because humans are messy and unpredictable. And it's even harder for us.

Believe it or not, I'm not an extrovert. I'm an introvert. It seems weird for me to volunteer to get up here in front of a bunch of people and talk and say I'm an introvert, but I'm comfortable in this setting.

But if you were to pluck me out of this one and airdrop me into a room of 50 people and say, "Okay, mingle. And by the end of the day, I need you to have 10% of them in some sort of relationship with you," I'd be like, "Oh, God. I'm not feeling good. It's not for me."

And I recognize that about myself, so I force myself to create relationships just so that I can get better at it. You have to kind of do the same thing.

So effort diminishes but never truly dissipates in relationships. You never stop working on a relationship, regardless of what it is. It's always work because everything is fluid. It keeps changing around you. Just when you feel like it's solid and everything's good, something happens. Economies change, your jobs change, your home life changes.

Community increases efficiency by leveraging slack. And again, I think that's really important to recognize, that the true power of community is being able to help each other out.

And your community's going to support your culture whether you want it to or not. So don't forget to work on culture. That's the ultimate relationship. That's the one you always have to be working on.

So my ask, I think we're doing really, really well at Hearst, frankly. But we've only been looking at the technology folks, the engineering. How do we get everyone else involved?

It's super important to pull everyone in, especially if you think about the fact that we have data breaches every other day. You need to have those relationships and that strong community in place beforehand, so when that occurs, everyone reacts simultaneously in one group, one team effort.

Product owners and managers, especially true for them. Leadership. I mean, heck, even pull finance in. There's fun finance people, I've heard. I'm sure that there's some out there. And they're probably more fun than you realize, just they've been on the outs.

So if you've done this, if you've been able to build a community that includes folks like marketing and PR, finance, folks that we don't normally think about and we don't normally build relationships with, I'd love to hear it.

That's one of the things I'm starting to recommend is like, okay, I'm willing to go try and build a relationship with somebody. Cool. Make it outside of engineering. It's going to be a little harder. Now you have nothing to talk about. You got to think of things. You got to ask questions and be involved.

So that's my talk. Thank you all for coming out. Really appreciate it. And if you have questions or want to talk afterwards, please come up and let me know.