Kick ‘Em or Keep ‘Em - Collaborating on our own Deserted Islands

Hey, my name is Matt Stratton. I'm primarily known for a couple things — one being my enjoyment of Diet Coke. There is no in-game Diet Coke. I've been watching Nook's Cranny for a while, but I know there's a pop machine, so maybe that can work out. And I am a transformation specialist at Red Hat, and I work in a group called NAPS, which is amazing because it means that I work on transformation of NAPS. That's actually North America Private Sector Public Sector, but I like to say I'm a NAPS transformation specialist. I transform NAPS. And my other claim to fame is, according to Ryan Kitchens of Netflix, I have the best hair of any developer advocate. Unfortunately you can't see it, but trust me, it's really good.

All right, so let's talk about some stuff here.

This may or may not be your first DevOps conference. You've probably heard — we've heard a lot today already about why collaboration matters. Ian had a great keynote talking about building bridges. We know that collaboration is a key part of DevOps, and we hear about this all the time. This DevOps thing is about 10 years old, and at least conferences about DevOps are 10 years old. And we talk about why collaboration is super important, and we talk about why empathy is super important. Just so we're clear, I'm not saying it's not — it's a really critical part of doing DevOps well, is working together. And one of the ways we can work together is by having empathy.

So we've heard this a lot. Some of you have been hearing it for 10 years. Some of you maybe are hearing it for the first time today, and that's okay too. But enough talk, right? We get the point. You're like, "Maddie, I get it — we gotta get along, we got to work together." That's totally fine. How do we actually do it now? And that's going to be kind of my point of today's talk — talking about practical things that we can do to get better at collaborating and building those bridges and working together and having empathy.

One of the most amazing things — if you're not familiar with DevOps Research and Assessment and the State of DevOps Report — is that it brought a lot of science to DevOps. So for a long time we kind of knew that following these practices were good, but a lot of it was based on just how we felt. It was very anecdotal, it was very based on our gut. And then Dr. Nicole Forsgren and DORA came along and they rubbed some science on it, and that's been the most amazing thing because we have data.

I'm picking out just one thing to drive home the point that this has a marked impact in your organization. This bit from last year's State of DevOps Report: in their analysis they saw that having a culture of psychological safety is predictive of software delivery performance, organizational performance, and productivity. The reason this matters — years ago Google did some internal research around their high-performing teams and saw that one of the most important things was having a culture of psychological safety. What the folks at the State of DevOps Report wondered in last year's report was: is this just a Google thing? Was this true across the industry? And was it true among high performers that weren't Google? And as you can see — if you read the report, and I highly recommend it — you'll see that it was a hundred percent true, not just for Google.

So this matters. Yes, we should collaborate, we should have empathy, because we are reasonable human beings and we'd like to get along with our co-workers — and that stuff's great. But it also makes your organization successful. It hits the bottom line, it makes you perform better, and that's a thing that can super duper matter.

How do we do this? We say we want to have this result that we've seen. You're like, "We're engineers, yo. We would like some instructions. We would like some code." Now I don't have code like that, sorry about that, but we're going to be kind of practical.

The first thing we're going to do is talk about psychological safety. This is a key component. We talked about this idea of psychological safety being so important, but what I want to do is really quickly talk about what it means — because you might think you know what those words mean. You put them together, you're like, "I know what psychological means, I know what safety means," so you might think it means like just feeling good or something. Well, the good news is it's a real word, it's a real term, and it has a real definition.

Here's what it is, at least according to Amy Edmondson from Harvard Business School: it's a sense of confidence that the team will not embarrass, reject, or punish someone for speaking up. That's basically psychological safety. That is huge. And I want you to think about teams and organizations and things you've been on, and think about: have you felt that psychological safety, or have you not?

There are all kinds of places this comes up, and it's on a continuum, and you're always working at it. There have been all kinds of instances, and I want to give one example where you can think you have it — just because you get along with your team doesn't mean your team has a culture of psychological safety.

Years ago I was working at a software company as a sales engineer. One of my teammates was a very good friend of mine — such a good friend of mine that he sang at my wedding. And we were in HipChat — this predates Slack's use at this company. My colleague made a mistake. He was trying to figure something out, and it had to do with the flags on an SSH command. He had basically misremembered how to identify the identity file that he wanted to use. We rubber-ducked that through the chat, and then figured it out, and I said something like, "Oh my god, Sean, how can you possibly even..." — basically made some joke that he was incompetent. Which was said out of love. He's my friend, I know he's a much better engineer than I'll ever be, which is why it was kind of funny to me. And he totally took it that way, and he knew I was ribbing him.

But we talked later, and my manager pointed out to me, said, "Look, I know that you two are friends and he wasn't upset by that. But someone who's on the outside, who's new to the team — all they saw there is someone made a mistake and Matt made fun of them. And they are not going to feel comfortable sharing these mistakes, or these missteps, or even what they perceive as missteps, because they're afraid that you're gonna make fun of them." And that's not okay.

So here's the first thing to remember: instilling psychological safety means approaching conflict as a collaborator, not an adversary. What we're trying to do when there is conflict is work together — we are a team. It's not about me winning, it's not about me being right. And we do this more than we think we do. Nobody thinks they act this way, by the way. Nobody thinks they're bad, nobody thinks they're the villain of the story — including the villain. So we have to reframe this to ourselves and be very cognizant that this is a team sport. When conflict comes up, we're actually trying to get to a result. I'm not here to prove that I am smarter or more right than my colleague.

And here's the next one: you want to replace blame with curiosity. Because the thing is, you don't have all the facts. You think you know, but you don't. You don't know everything. If we look at it as a positive thing — which is curiosity — I want to understand, I want to learn more. So if my approach within my group is to do that, to learn more, and I'm taking this curiosity approach.

And this is a big one: you need to model vulnerability. This is a way that creates emotional bonds. This doesn't mean that you and your teammates have to be best friends and go out to the bar together and go to each other's kids' birthday parties. But sharing things about your own life and your own lived experiences is a way to create those emotional bonds. And it is incumbent upon folks who are a leader in that team to do that. I said "leader" and not "manager" — that goes back to the story I gave earlier, where I was not the team lead, I was not the manager, but I had a senior responsibility. I was someone who had been on the team for a long time, so my behavior is modeled.

So we're going to talk a little bit now about the idea of blameless facilitation. We hear a lot about blameless postmortems — we talk about them a lot. I'm not going to go too much into why blamelessness matters, because again we're kind of operating under the assumption that we get that. We want to come from a learning place. But what about if we're trying to run a conversation — maybe it's running a meeting, maybe it is a post-mortem meeting, maybe it's just a different kind of conversation — and we want to facilitate it in a blameless way? What are some of the things we can do around that?

The first thing: I'm going to turn the corner and say that being blameless is almost impossible. According to J. Paul Reed, if we think about it, as humans we are hardwired. There's been millions of years of evolutionary neurobiology and then thousands of years of social conditioning to use blame as a way to give voice to these feelings that are uncomfortable and frankly painful, in order to effectively disperse them from our psyches. We cannot remove blame from what we do. But what we can do is become blame-aware, and then we can try to make our actions avoid blame. And there are some really practical things that we can do in a conversation and in a meeting as a facilitator to help steer the conversation away from a blame-type approach.

So the first thing, if you are a facilitator, is understanding what your role is. What is the role of a facilitator? This is not a moderator, this is not a presenter. But if you are trying to facilitate a meeting — or a conversation — in a blameless way, as a facilitator this is your role: you're there to encourage people to speak up and to make sure that everyone is heard. One of the things in psychological safety is that on teams with high amounts of psychological safety, team members all speak about the same amount. So a facilitator can really help — one of your roles is to encourage people to speak up, make sure people get a chance to be heard. It doesn't mean you necessarily call on people, because people aren't necessarily comfortable. You're there to clarify insights and challenge the team with questions.

I run a podcast called Arrested DevOps — you should all check it out. But as a podcast host, when I have guests I consider myself the audience proxy. I might ask questions of the guests that I already know the answer to. But I'm doing that to give voice to people that don't necessarily have a voice on the podcast, because they're not on the call — but maybe even in the room. You're there to clarify, and also to challenge with questions. And you're also there to help the team see different angles and different options, because you're a little bit abstracted away from it. You as an individual may have a vested interest in this conversation, so as a facilitator you need to step out of it a little bit and try to be somewhat objective, and maybe introduce different angles.

And then there's the housekeeping of it. As a facilitator, you're supposed to help keep everyone on time and on track. We only have so much time. If people are dominating the entire meeting, you really have a responsibility to keep things on track — that kind of housekeeping stuff.

A couple other things to keep in mind as a facilitator: you do not make decisions. You're not there to take sides. You need to be as impartial as you can. Even though in your head you totally know what you feel and what you think — and I'm not telling you to stop doing that — you also need to try to speak as little as possible. You're not a presenter, you're a shadow that guides discussion. You're not there to run the entire conversation, you're there to support and guide and help people be heard.

And also I know that my son Henry is watching this talk, and this would be very very hard for Henry, so Henry we may need to work on making you a blameless facilitator. But everybody, it's a growth opportunity.

And then finally, let's talk about conflict. Conflict is going to happen. You'll notice I talk about de-escalating conflict, not removing conflict. It's going to happen, but it can be done in a way that feels safe, where we can feel heard, and we can have even greater collaboration.

Marshall Rosenberg really put it this way, and I love this. He said we really don't seek compromise — we're looking to resolve the conflict to everybody's complete satisfaction. I've told my kids before that a compromise is when none of us are happy, and that's actually maybe a little true. So that's why we're reframing away from the word compromise. Our goal is to resolve the conflict and have everybody be happy. Now, that doesn't mean you get what you wanted in the first place. This is part of building a better understanding so that we are actually all completely satisfied with the resolution that occurs.

My buddy Dave Shackleford has said that when you have conflict, you can pause things with force. Sometimes you just have to say, "Hey, yo, chill out, take a step back, we need to pause and reset." But it's hard to make progress until people feel heard. There is a visceral, physical response when you believe that your point of view has been understood and acknowledged. Being understood and acknowledged does not mean it's necessarily agreed with — but you have been heard. We want to be heard. And remember that the other people want to be heard too. We communicate human to human — they are humans, just like me.

So when we think about non-violent communication, there are four key components. This is a way of keeping conflict from escalating and getting ourselves to this better understanding. Marshall Rosenberg is the one who created this idea of non-violent communication, and it's around observations, feelings, needs, and requests. We're going to go through these and see how we can actually implement this as an understanding when we are in a situation of conflict, whether it's with a teammate or even in your personal life.

Sometimes in DevOps you hear us talk about this idea of CALMS, which is Culture, Automation, Lean, Measurement, and Sharing, and we say the order doesn't matter because it just spells a word. In this case the order matters, because each of these things are going to build upon each other.

So we start with observations. What's an observation? It's, as its name implies, what I observe — what I see, I hear, I remember, even what I imagine — but free from evaluation. Just the facts that do or do not contribute to my well-being. What do I see or hear? But the thing about non-violent communication — it's not just the "I" part. It's also for me to understand what you observe, what you remember, what you see, free from my evaluations, that does or does not contribute to your well-being.

So I start with the observations. When I see this happen, when this is a thing that I see happen, those go into feelings. And we can't control our feelings. Trying to stop feelings is kind of a fool's errand — they're going to happen. What matters is what we do with them, and we have to acknowledge and understand and respect that they occur. So the feelings are how I feel — it's an emotion or sensation, not a thought — in relation to that thing that I just observed. When I see this, I feel this. And then I need to put that into the frame for you as well: how are you feeling in relation to that observation?

And those go into our needs. The needs are so human. This is what I need or value, but it's not a preference, it's not a thing that I like or prefer, and it's also not an action which causes my feelings. So: when I see this, I feel this way — I feel upset because I value being heard, because I value justice. Because I value Kubernetes — okay, that's not a real one — and because I need root access. And likewise I need to be able to frame and understand what you need or value.

And then this comes into request — the actual action. Requests are clearly requesting what would enrich my life without demanding. It's a request. This word is intentional. And then I need to empathetically receive what would enrich your life without hearing it as a demand. Even if you demand it, I need to not hear it that way. That's really hard.

So what are requests, as a final thing? They're the concrete actions that I would like taken. "Would you be willing to...?" When I see or hear this, I feel this way, because of this thing — would you be willing to do this other thing? And this is a little more empathetic: I might need to volunteer something and say, "Would you like this to happen? Would you like this to occur?"

So to put a bow on it — here's what it boils down to. If you want to go fast, go alone. You can do things by yourself. I've got tons of GitHub repos where I am the only collaborator, and yes, I argue with myself in GitHub issues and it is hilarious. I can move a lot quicker when I'm the only one I have to convince of something. But if you want to go far, go together.

My name is Matt Stratton. These slides are available at speaking.mattstratton.com, along with some resource links that you might find interesting. Thank you very much for your time. You can find me on the Twitters — I'm at Matt Stratton. And I am so excited to be part of this event.

---

I actually had to reframe how I thought about the success of my talks, because I used to measure it by whether there were questions. If there were a lot of questions I felt like it was a good talk. What I found with a bunch of my talks is that I would get a lot of questions later in the day, because sometimes we need to marinate on things. I might hear a talk, I might have seen something in Ian's talk, and then later as we're having a different conversation I'm like, "Oh, that kind of reminds me of when they said that thing — now I have a question." So that's why I love events where we can participate throughout the entire event, because everything kind of connects together and we can have these conversations.

How would you recommend starting this culture as a junior dev on a very senior team?

Wow, that is definitely tricky. Any time that you are trying to make culture change, it's always something where you need to start small. Going back to the example I gave with my friend, where later offline it was brought up — when you see some of the things that don't contribute to psychological safety, you might not be able to bring it up in the moment. In fact, in the moment is often not the best time, because people aren't receptive.

But if you have some opportunity later, you could say, "Hey, in this conversation I noticed this." So you go back to the non-violent communication. Apply non-violent communication, because you fundamentally have a conflict there — someone's behavior was not reinforcing psychological safety. And be able to sit there and say, "I noticed this statement, in this particular way, and it made me feel this way. This is what I observed, and so my request is to maybe not make jokes like that."

The other thing is it's okay to introduce it as an idea. Don't try to do everything all at once, because it is something the team kind of has to agree to. They don't necessarily have to agree as individuals, and some people might not. But I've been on teams where we have a charter — not super formal, not a big doc in Confluence or whatever — just the thing we agree to, the rules of engagement for our team.

And especially for some folks who maybe aren't into this — you start going on about psychological safety and empathy and everything, and their engineer brain turns off. So what you can do is just say, "Hey, I think it would be really great if we put together some informal rules of engagement about how our team works together. Here are some ways that we might be able to do that." You can introduce these things without using the hug-ops terms that might turn some people off — or they might be into it. You know your team better than I do.

Don't be afraid to take the next smallest step.