Adam discusses "The Five Dysfunctions of Team" by Patrick Lencioni with SRE & DevOps expert Dave Mangot.
Show Notes
Adam welcomes Dave Mangot to the show for a book discussion. The classic leadership and management book is "The Five Dysfunctions of a Team". Adam & Dave discuss the dysfunctions through a lens of software delivery, DevOps, and SRE.
Dave Mangot's Links
- The Goal 30th Anniversary Edition
- Just Culture: Restoring Trust and Accountability in Your Organization, Third Edition
- The Three Principles Underpinning DevOps
- Inno-Versity Presents: "Greatness" by David Marquet
- The Manager's Path (Book)
- People not Tech
- What Google Learned from Its Quest to Build the Perfect Team
Adam's Links
ā
Support this podcast on Patreon ā
Creators & Guests
What is Software Delivery in Small Batches?
Adam Hawkins presents the theory and practices behind software delivery excellence. Topics include DevOps, lean, software architecture, continuous delivery, and interviews with industry leaders.
[00:00:00] Hello and welcome. I'm your host, Adam Hawkins. In each episode I present a small batch with theory and practices behind building a high velocity software organization. Topics include dev ops, lean software architecture, continuous delivery and conversations with industry leaders. Now let's begin today's episode.
[00:00:26] Hello everybody. Welcome back to small batches. I know it's been awhile. Since I released an episode, I am still working through a backlog of interviews. There's only a few more to go before we get to something I've been working on for a long time now, which is a series of episodes on the high velocity edge, which will complete with a conversation between myself and Dr.
[00:00:55] Steven spear, the author of the book. So far, I have written five episodes. And I think I'll have about 10 parts of this one. And these are going to be actually real back to the basics. Small batches episodes. They're going to be short. I've written them to be about four, five, maybe six minutes. So this is going to be some potent information here.
[00:01:25] And these episodes. So stay tuned and I look forward to sharing those episodes with you. Now, for today's episode, I'm going to be doing something a little bit to different. As you know, I experiment with the format of the show and try to try out different things to see what works, kind of keep it fun and keep it different.
[00:01:47] So today I have a guest on, and we've both read a book and we're both going to talk about this book through the perspective of sort of like software delivery, dev ops, like tech, that kind of thing. So the book is the five dysfunctions of a team. You may have heard about this book before. It's kind of one of these, you know, easy to read kind of classic leadership management type books. you know, So it's a non-fiction book, similar to the goal. The idea here is the author tells a story of an executive team going through some challenges and illustrate the five dysfunctions of a team, what they are, how they play out in practice and what teams can do about them. So just to read off the five dysfunctions, because we'll bring them up in the conversation, kind of assume that you'll have read them or at least be familiar with them.
[00:02:39] So the first one is lack of trust. Number two fear of conflict, number three, lack of commitment, number four, avoidance of accountability, and five and attention to results. And I've experienced all of these in different ways of shapes or forms throughout my career and in different teams. So I just wanted to have somebody on the show, kind of what the perspective on organization design, sort of the dynamics of teams.
[00:03:06] And with an eye towards achieving a high-performance software delivery, just to talk about all this stuff. So my guest today is Dave mango. I've found him through some talks he'd given at conferences before, and I really found him through his current focus on SRE and dev ops. And I started to look into I thought this would be a good guy to have on the show. And I think the conversation delivered. So, let me read off a bit from Dave's official bio.Dave helps companies get good at delivering software as the principal at Manco tech. That's his consultancy as an early DevOps veteran, who was not content to work only with unicorns.
[00:03:50] Dave has tackled some of the major cultural and structural impediments to dev and ops collaboration at companies such as Salesforce, Barracuda, solar winds, and cable and wire. Between those and his best-selling video course, mastering DevOps. He's improved the lives of thousands of it professionals around the world.
[00:04:09] So I'll put links to Dave's websites in the show notes and places. You can find them online. They highly recommend you check out his work and kind of follow this guy. I think he is just, he gets it and we should pay attention to what he has to say. So with that, I gave you my conversation with Dave Mangot. Dave, welcome to the show. How are you? Thanks for having me. Adam. My pleasure. So I invited you on the show to try something a little bit different. So we have both read the book, the five dysfunctions of a team. And our plan here is sort of talk through how these dysfunctions have played out in our experience with like DevOps and SRE and sort of leading organizations and leading teams. So why don't we start off by just a question for you is like in your work, leading these teams and trying to move organizations towards these ideals, how have you seen these five dysfunctions impact your work?
[00:05:09] I
[00:05:10] guess I would say that, you know, each of the dysfunctions affect things differently. It depends on sort of whether we're talking about within teams, between teams.
[00:05:21] You know, organization-wise one of the things that I like the most about dev ops and, you know, the dev ops movement. I, I give a talk called the there's no such thing as DevSecOps it's, it's this whole thing about how we, we shouldn't get caught up on the, the names and like sticking like different words inside.
[00:05:43] So marketing legal, everyone doesn't have to be represented in the name. Dev ops, like dev ops is like Kleenex. At this point, it's just a brand name, but it gets started irrelevant. But I like how, you know, dev ops can bring all these different groups into focus together so that we're all moving in the same direction.
[00:06:03] And I think that was one of the things that was great about the five dysfunctions was that when, you know, Catherine, the CEO is like bringing all these different VPs and such like into the room. She very much had this idea of like, you are a team. Right. And she did a whole thing where she was talking about like, if your loyalty is to the team that you manage, or if your loyalty is to this team, right.
[00:06:28] This executive team. And I thought like from a dev ops perspective, like that was really cool, because now you're seeing that like, you know, everybody needs to be aligned in one direction if we're really going to get results. And, you know, obviously this is like crazy before the dev ops movement ever existed in any way, but like already, like she's talking about, you know, this alignment.
[00:06:54] So when we get into the actual, like individual dysfunctions, like, you know, conflict or accountability or results or whatever, It's good because in some respects, she's leaning on these leaders in the team to be responsible themselves for those things. But she also makes a big deal about having leaders, holding each other responsible for those things.
[00:07:16] That's her lab, you know, accountability, dysfunction. And so I thought it was really fun, you know? Cause you were like, Hey, why don't you read it from a dev ops perspective? I'm like, okay, cool. And like, it was, it was fun to see those things play out. You know, it's in some respects, like the dev ops movement didn't invent the idea of cooperation.
[00:07:36] Like, no, not
[00:07:38] at all.
[00:07:40] but it was, it's great to see like the successful patterns
[00:07:43] repeated.
[00:07:44] Yo. Yeah. When I read it and she called out, you know, who you're loyal to, and I just had this like gut punch of those times when I was thinking like, Hey, This is a product problem. This is a, or this is an engineering thing, like, oh, I'm in engineering.
[00:07:59] Now this is management who is messing it up or like, Hey, I'm on SRE now. So why are these dev doing this crap? Like I had just had this moment where, Hm. Yeah, maybe I don't really feel like I'm part of the team. Okay. Why that's another question, but that is. Really, if we ignore all the sort of like the technical stuff and all like DevOps is really just about optimizing for team performance, organizational performance that is like a team of five people, organization of five or organization of 500 different teams, right. You just have to scale up the ways you're working, but. No, it's really all about cooperation, but that's the hard thing I think for human beings is to actually just really cooperate and get along.
[00:08:43] Yeah. I had given a talk at a number of doubts, like conferences and stuff that I call the cognitive neuroscience of empathy. You're a dev ops natural, and it gets very much into this idea of like, The neuroscience of teamwork and there's just so much, there's so much stuff as hardwired into our brain.
[00:09:04] That's tribal. so it's very much about coming together as a group and then in psychology or neuroscience, we'll call it like in groups versus outgroups. But the things that you're describing Yeah. I am loyal to my in-group. I am loyal to the people who are like me and those clowns over and, you know, data science.
[00:09:25] They're not, they're not SRE, so they're an outgroup. And like there's a lot of stuff. And, you know, and the talk about how do we bridge those things, because that's a part of who we are. That's how we survive. Like, as I talk about in the talk. This whole myth of the elite hunter gatherer is like dumb, like the way that people survive when they a cave, people was bonding together as a group and everybody fights off.
[00:09:51] Whatever animal that's coming to eat them. Like you don't want to be the one person doing that. You want like the whole group. And so it's just part of who we are. So, yeah, it's great. I know, obviously, thank God progressed past that fighting off while animals days, but like the book does bring like a good focus on like, You know, what is teamwork?
[00:10:15] You know, how do we become a good team and how do we become a team that works together? And I think she said something in the book. I can't remember the exact phrasing, but it was something like this. Isn't a team like this is a collection of individuals.
[00:10:28] that was cool.
[00:10:29] That was one of those other moments when I read it, I'm like I could totally put myself. On both sides of that. Like one, you know, when you've experienced, like really like, oh, I, I know that I'm part of a team, like I'm in a unit with these people. Like we've jelled, we're all working together on this thing. Like we're all in the same boat, rowing in the same direction as paired to the other end when you're like and one individual over here doing this, this other person's over there, maybe, you know, like whatever other people are doing or like, maybe you're not.
[00:10:57] And, I want to steer the conversation now to some of the work. Like we both have done an SRE space coming back, to like the two of these dysfunctions on the like avoiding accountability and inattention to results. And, you know, one thing is critical. The lifeblood of all SRE is a SLIs and then thus SLO.
[00:11:18] You know, so probably people have been in organizations where they have their SLO and maybe they're looking at them, but they're not hitting them ever. You know? And they're just sort of this like unfortunate, I dunno, like Kabuki theater organizations go through and it's like, why don't we even have any of these numbers or these SLIs, if we don't care, if they're going in the right direction or not.
[00:11:41] And I think that inattention to results. Really it's like really painful, especially for SRE because we're numbers driven like all the way down. Right. We're looking at these graphs, we're watching all these things, but when the wider team is not paying attention to them, then that's when everything starts to go just in the wrong direction.
[00:12:07] So, I mean, have you encountered that of you smiling, but if you have encountered that, you know, what do you do in that situation?
[00:12:16] Well, I guess I'm smiling. because it goes back to the, are you asking the right question? Right. So if the SRE team thinks that the SLO are super important and you know, we have these SLRs set and, and we're not hitting them or whatever.
[00:12:32] Why aren't we hitting them? You know, you said something to the effect like, and everybody else doesn't care, but why don't they care? Like, is it possible that this thing that we've set as the target, that we should all be hitting? Isn't the right thing. You know that Jess humble and Nicole have a Nicole Forsgren have a, a great talk that you gave a Q con is I think the title is something like.
[00:12:59] If we don't know where we're going, it doesn't matter how fast we get there. It's this idea that like, what if you know what an inattention to results has nothing to do with the idea that we're not hitting the SLO? What if those are the wrong things that we're supposed to be paying attention to? Right.
[00:13:14] And for example, if having a low SLO is not affecting revenue, it's not affecting customer satisfaction, it's not affecting company growth or whatever. Then why are we obsessing over the SLO? That's something that somebody came up with, which is fine. Like it's, it doesn't mean that it's a bad measure, but it may not be a measure that represents the things that we want.
[00:13:37] If we can tie the SLOs to other parts of the business and that becomes reflective then yeah. Then now if I want to say like, Hey, how come no one else was paying attention to this. I can go to these other people and be like, you remember when we had that conversation about how this is tied to this? Like, let's just say customer satisfaction.
[00:13:55] Our SLOs, we're not hitting them, which means we have a lot of downtime. You look at our customers, you know, satisfaction metrics, whether it's NPS or, you know, how many calls a day or whatever you want to use as your metric. What do we do about this? Right? Because now I'm not getting, let's say the numbers I want, and you're not getting the numbers that you want.
[00:14:05] So we've, we have a collective problem. Now we're a team, you know? And like, how do we, how do we work through that? Do we have to get other people to see this? Because. You know, ultimately people buy into something that they see as valuable to themselves. Like, you know, getting back to our little tribalism, like idea or whatever, you know, the in-group and the out-group like, I can feel some empathy for you as an out-group.
[00:14:45] But I don't feel anywhere near the same empathy as a, I consider you part of my group. So like let's rally around whatever customer satisfaction we're all rallying around that. Then we can come at it from our own perspective and, you know, and contribute from our part of the organization to that.
[00:15:05] And so you saw that with Catherine in that team, right? They were like, Their metric was they wanted to get like 18 new customers over the next year or something like that. And they were like, I don't care what you're working on, as long as it's in the service of that. Right. And you're like I think it'd be very hard to rally an organization around being in service to an SLO because an SLO is just a number, like what are, what is that SLO contributing to?
[00:15:33] I think that's something that people can, rally around a little bit more.
[00:15:39] Oh, yeah, for sure. I mean, it has to be connected. You mentioned the conversation about like eight was it, they find to get like 18 deals or something like that. That was their goal for the whole executive team. But before that, they had this whole discussion about what does everybody actually think we should be doing?
[00:15:56] And they debated, they debated that. So they, you know, went through this whole, you know, process to come to some kind of conclusion that, okay, no, we needed to do this. So like, coming back to SLI, It's like, if you haven't actually had that whole conversation with all the different stateholders about what, why are these SLIs important and how do they contribute to whatever the top, like the single objective is without that, then you really are not going to be able to like move, move.
[00:16:24] Right. And this speaks to the inattention to results. Like if everybody says like organization needs to be working on getting like 18 deals. If you're not working towards that, then, you know, what are you, what are you doing? Like it's so easy for people to like, go off. Have like little side quests where they do whatever, but like keeping the, you know, like keeping the organization focused and aligned on that, turns out to be a really hard problem, you know?
[00:16:49] Yeah. Again, you have to tie the SLIs to some sort of business objectives. Like what are we trying to do here? Because an SLI is just some measure. There's a famous quote by Deming, which is something to the effect of. yeah. Give a manager, at target and they'll do whatever it takes They're, you know, hit that target, even if it means driving the company out of business.
[00:17:12] And, you know, I've done this with security organizations before a different job, you know, I was in SRE, you know, sort of role, but you know, they're like, you can't do this. Okay. You can't do this. Okay. Can't do this. Okay. What can I do? Well, I don't know, come to us as something else. You guys are gonna make us so secure that we're going to be out of business.
[00:17:35] And then they're going to write the obituary or the company that says they went out of business, but at least they were secure doing it. You know, it's was like, you can't just look at the whole world from your perspective. Like you need to focus on. What are we doing here? Like, what is our purpose? And so I, I think that like, you know, the inattention to results and, avoidance of accountability, I think those two things are more intertwined than they make it out to be in the book a little bit, but it's really going to be like, you know, what, what is that thing that we're trying to achieve?
[00:18:08] It's funny, because in the goal like Goldratt's book, right? What's the purpose of the business making money. Sorry, anything that we do, that's not in the service of making money is a problem, but like that's not what they chose in the five dysfunctions in the routine. They weren't like, oh, just making money.
[00:18:24] It was like, we want to hit these 18 whatevers. And then presumably the next year they hit another target. And then I think the good thing about that is it really ties into this idea of aligning the organization. One of the things that I like to, you know, talk about is like the whole OKR, you know, whatever kind of thing, or you want to, whatever those measures are called at Salesforce, they used to do V2 mom, which was like vision values, metrics, obstacles, and measures, of how to, something like that. but really like the cool thing about that was that like, you know, at Salesforce at least. In theory, you know, everything when a 15,000 now, 35,000 person organization, a little difficult, but you know, in theory like mark Benioff would set his goals for that period. And then every leader underneath him would write what their goals were.
[00:19:18] But each of their goals was written in service to the goals that mark was setting for the company. And so I think it's interesting here. Like when we're talking about SLOs and SLIs, it'd be interesting for the SRE teams to write their goals and how those goals tie into achieving the goals that the company has.
[00:19:39] Right. And so like, to me, the SLIs are important, right? I'm an SRE SLI, like blah, blah, blah, to somebody in marketing. Like, first of all, if I don't want to look up what SLI even means. And second of all, like anything that an SLI means is probably not something that I really care about all that much anyways.
[00:19:59] So, so I think it's, it's important that we recognize that. like, Being part of that wider organization, like even like the dev ops movement, we recognize that there's things that we're going to be focused on. They're important, but they're important to us. And we need to make sure that everybody's focused on the things that are important to us, so that we're all sort of marching in the same direction to get to where the company wants to go.
[00:20:22] So I think there's certain audiences where we can yell. at... Yell, well was probably not the right word, but there are certain audiences where you can go after them and be like, Hey, look at this SLI. It's not here or there, but like at the same time, why are we going to them with that problem? Right. Is it something they can even fix?
[00:20:41] And if it is, if it's something only they can fix, is it something only we can fix? Or is it something that we need to fix together? Because I've worked on a lot of high-performing teams where like a lot of these things it's like, Hey, YouTube, This SRE and this developer need to sit down and work on this problem because it's not going to get solved in isolation.
[00:21:02] That's just not a thing it's impossible. And like, so, you know, can they sit down together and find a way of bringing that SLI back into the compliance of whatever we probably agreed to as a combined group anyway.
[00:21:17] When you're talking about aligning the teams and now we kind of talk dancing around something, we talked about pre-show, which is how some of all these different business novels, they kind of overlap each other.
[00:21:27] You know, we talk about, you mentioned the goal, just a great book, right? Like all of the sort of DevOps handbook, all that stuff is all kind of traceable back to some of these like really early work in manufacturing and then Phoenix projects and unicorn. project. And one of my favorite parts about both those books.
[00:21:43] because they tell the same story is the story about how they all rallied around. It was like the marketing. project. And that is okay, we'll do the Phoenix thing. We'll launch this. We're about to do this campaign because we can do this campaign. We'll be able to generate all this revenue. It will prove out like this way of working this whole tech stack.
[00:22:02] And that comes with that demonstrates the importance of that cross functional or cross department, whatever alignment in service of whatever the higher level objective is. Right. And that's where the real performance and the real results come from. And why. Without that you get stuck in local optimizations, right?
[00:22:24] Like in the goal when I was at Eric, he's like, oh, the goal is efficiency. All I care about is efficiency. And John is like, no, that's not the goal. Like, that's you're like, you've missed the mark focus on that one thing. Right. But there's. a higher, Higher level purpose here. And one of the hard thing, like in my mind with DevOps is getting it out of the tech framing.
[00:22:48] Like this has nothing to do with tech, right? Like this is the implementation, but really the philosophy has nothing to do with tech. It's just teams, organization performance, and you can do it like this, but it's so hard. how do you actually get people to do that? That's the, that's the challenge And like these different novels.
[00:23:06] They have to give 'em like just a perspective on like, it seems like more ways that things go wrong rather than things, the way that things go. Right.
[00:23:14] I think it was cold because when Gene went back to write the unicorn project, right? Like you said, he's writing the same story, but he purposely wrote the same story from the different perspective.
[00:23:26] Right. So it was like, all these books are giving you a different perspective on the city. Those two books are literally designed to give you like the ops perspective and the dev perspective. And you know, it is cool that he was pulling in like some of the other, other departments. I written a story a hundred times, I think, on blog posts and, in talks and stuff about working with the marketing department from DevOps principles.
[00:23:52] because I was explaining it it's like, Toyota manufacturing is legendary, you know, Toyota. Right? You're going back to the battery. They're legendary for this idea of just-in-time manufacturing. Right. And the problem that they're trying to solve is that inventory is expensive and you don't want to carry inventory.
[00:24:11] You don't want to have a bunch of parts sitting in our warehouse waiting to be used because that's capital that I've spent that I'm not making money on. I'm paying to store it, which is terrible. And then you also don't want cars on the lot outside the factory, because now I've created something. I've spent all that capital and I'm not making money on it because it's not a dealership or someone can drive away with it.
[00:24:34] And so there's, I love the parallels between that and software because, you know, I always make the argument that like, if developer checks in code and it's sitting in. git. So what, I didn't make any money on that, that, that sit in and get like, it has to be out in production, right? That's where we make the money is when stuff's in production.
[00:24:51] so what we did, we looked at, but from marketing was that a lot of times we would release a new feature out into production, and then the marketing people would come along, you know, afterwards and be like, can you give us a blog post? Can you do this? Can you help us out with this or whatever. Cause now the features out there, we want to write about it and.
[00:25:10] I was We've spent all this money to get this product out in production. Nobody knows about it because marketing isn't ready to talk about it because we're going to start that clock. After the thing has been released. I was like, why don't we start the clock earlier? So that marketing is in lock step with us.
[00:25:29] So when we released that feature into production, the next morning marketing has a blog post out that says, Hey, we released this great new feature. You're going to love it. You know, tell all your friends, show up, sign up more customers, whatever you want to call it. But like, then we don't have this lag. We don't have this period where we've invested this money and we're now carrying inventory.
[00:25:50] But nobody knows about, so it was like, it was a great exercise of bringing marketing into this dev ops idea where we're doing, you know, Phoenix project Jenkins, first way of dev ops, where we're looking at doing the systems thinking, and like applying that to the problem.
[00:26:06] One thing it's actually more fun for me is trying to get people working in this way outside of tech, because it forces you to break that sort of assumption about maybe what people know or what they think or. through of their Expectation about how work actually happens. You know, if you can get more used to working an extract like abstractly about it, I think it's easier to succeed in a different context where it is, where it is useful, you know, and people, I think generally care or at least are interested in getting their work done, like faster, like having their results sooner.
[00:26:39] Like people want that. If you can show them how I never heard somebody to be like, no, I'd rather have it later.
[00:26:45] God, no, not definitely no, Nowadays speed is totally kidding.
[00:26:51] Yeah. So this actually comes back to one of the other dysfunctions. I want to get your take on, which is, I think probably the hardest one they call out in the book too, which is the lack of.
[00:27:02] like avoiding accountability. And in the book they tell the story of, you have to be able to call your peers on, say like when they're going against whatever the objectives are, or, you know, doing something detrimental. So taking this back to say like dev ops and tech, this might be seeing somebody in your team who is like, You know, like writing code without, without tests or doing things in a really like committing to work arounds or say things that are known to be detrimental to the team or detrimental to whatever the tech stack is.
[00:27:37] And it's hard to, you know, call somebody out and say them like, Hey, you really need to be doing this. Like, why aren't you doing this? Do you not know what to do? Like, do you need help? Like, why are you. Like where's this coming from? Cause one of the challenges is from my perspective is you don't always know what somebody else knows, like what their assumptions are about like ways of working.
[00:27:58] But like, without that say the trust of being able to, you know, talk to your peers about like, Hey, we need to be working like this. Like, why isn't this happening? And like, if you, you know, if somebody needs help, like let's get them help. Or like what happens in the book too? right? Somebody just quits because we're like, nah, this isn't for me, you know?
[00:28:18] But It's hard. I think I've not really seen that aspect play out to, in any tech, besides like people's getting frustrated with the waist up. Like, you know,
[00:28:29] I mean, so a couple of things, one is, I don't really think that avoidance of accountability. I think that accountability stuff happens at a higher level.
[00:28:39] one of the things I advise a lot of clients on is like move your SRE team under the same leader as your development teams. It's really like weird when I look at or charts and like, you know, SREs over here and developments over here. I'm like those teams have to work so closely with one another that you, you don't, you don't want to do that.
[00:29:00] I think, like not calling somebody out on writing tests and stuff like that is that fear of conflict that she talks about as a dysfunction, which ties into the absence of trust. And I, I think there's, there's both things There's a famous, you know, Google study. Now they have like a whole rework website or whatever they called it project something or other, I don't know.
[00:29:21] but there was a whole article in New York times about what makes the best teams, what makes them the highest performing teams. Right. And it's, it's almost ironic because, you know, they discovered what was written in the five dysfunctions of a team years earlier, but it was. like. It was psychological safety like that by and far the overwhelming thing.
[00:29:43] It had nothing to do with, you know, how many years of experience people had or how many years of experience they had with each other or anything? It was just straight up like psychological safety was the highest predictor, like just by far. when a blossom has an entire startup, than she's doing called people, not tech.
[00:30:02] That's just about psychological safety. Like that's her whole shtick. But you see it on these teams. And it really is about this psychological safety is about being able to express yourself without worry that someone's going to make you feel stupid or whatever, blah, blah, blah. That's a dumb idea. So it's about being able to have this respectful conflict.
[00:30:25] And so, you know, Katherine plays this up when she's talking about the fear of conflict in the book, but you know, it's being able to, To be able to have that space where, you know, you feel comfortable and you don't feel foolish if somebody doesn't expect that, you know, take your idea. I wrote a blog post years ago called, what it's like a, an agile SRE plan or something like that.
[00:30:51] And it was about how we did SRE and a number of different companies, not just, the one I was at at the time. but how we built up this meeting plan for the week. I think it's called an ed agile SRE meeting plan. and one of the meetings that we had during the week and we had hardly any meetings yet, we were still able to get a ton done, was called, the architecture meeting.
[00:31:14] And the architecture meeting, people would present an idea, like how do we want to get this done or whatever. And everybody would discuss like how to get that done. And, you know, one of the things that was really important was being able to express yourself without any fear or whatever. And, you know, there were junior people presenting.
[00:31:34] There were people who had like, you know, 20 years experience like I did, who were presenting or there. And we needed to create an environment where people felt like they could, you know, take that because ultimately. The goal was to get the best, you know, the best outcome that we possibly could. And so the team would rally around that idea of getting the best possible outcome.
[00:31:56] And, you know, there's a lot of other things you can do to build psychological safety within the team. Like we use, you know, we're a distributed team. We do stand up every day. I always let the first five minutes of stand up, just be. chit chat. It's snowed here. My kid won the balanced team competition at gymnastics yesterday, whatever, whatever people wanted to talk about because they needed to connect on that personal level.
[00:32:21] But then all those things can carry forward into your technical discussions where like, yeah, well maybe I wanted to use jumbo frames here and somebody else didn't and I didn't get my way or whatever. I can't walk away like, oh my God, I'm so attached to those jumbo frames. You know, it's like, have to be like, Hey, this was like the, you know, the team deciding that this was the best way forward.
[00:32:45] And sometimes I'm going to get my way. Sometimes they're not going to get my way as the leader on that team. I had to be even more conscious of that. Like that I didn't be like, well, no, this is how we're going to do it. Because like, you know, that's, that's not really being a real leader. Right. Go read a.
[00:33:01] Turn the ship around by David Marquet. Like it's the smartest person in the room idea is a horrible way to run a team or an organization or whatever. So Nobody
[00:33:11] liked Martin in the book, right? Yeah.
[00:33:14] Right. Yeah. Martin was, yeah. But you know, that was his approach at first. Right. And he had to come around once he, once they had established that psychological safety, then he was able to subvert his own ideas.
[00:33:28] To the greater goal that they were trying to accomplish. And I think that's a natural outcome of once you build that up, then you don't have the fear of conflict because nobody's, coming after you, they're trying to find the best answer. And that's where you get your commitment and whatever.
[00:33:44] And again, I think the accountability and the inattention to results are a higher level thing that happens. Maybe in our technical organizations. I think we're a lot more focused on like maybe those first three.
[00:33:58] Yeah. So it's, you know, psychological safety is such a big deal. And I think for me, the best thing to come out of unicorn project is just being able to put a name on it because it's there, it's like what? The five ideals, psychological safety. And I recently read this book, agile conversations it's from it revolution. And they had, Jeffrey Fredrick and double squirrel on the podcast and they have this concept. TDD for people. Actually, they call it trust and test development for people, but it's this ladder that you can have in your conversation so that you can build that trust.
[00:34:36] So that it doesn't actually become conflict. It's more of just like the debate or maybe not even debate the conversation. Like there's, the conflict comes from the feeling of being attacked or under some kind of duress, but, you know, you can have a really heated, passionate conversation with somebody that doesn't ever feel like conflict.
[00:34:56] It just feels. like, Like two people or a couple of people just having it out. Like, what is the best thing to do here? Like what actually makes the most sense? You know, like in the book, what they talked about was you don't have to agree, but at least everybody needs to be heard. Like if you don't, if you're not heard, you don't feel like you're having any buy-in to whatever this group is doing.
[00:35:17] And without that, you can't have commitment in up the chain. Right. So I really like, I'm going to put a link in the show notes to this illustration trust driven development for people. but I read the book and it was just a great way to afford a frame, how to have conversations to build psychological safety, like building this connection, laddering up from like assumptions, expectations, like meanings, all of this stuff into ways of working like ways of thinking behaviors, because that's what we're really trying to get to is have people adopt quote the right behaviors in these different contexts,
[00:35:53] Yeah.
[00:35:53] If you've ever read a crucial conversations, like one of the. Key things or whatever you want to call it. You know, foundational things you're supposed to keep in mind is establish mutual purpose. And like, that's a way of being able to have these conversations with less conflict, let's call it. But like, I was like, oh my God, establish mutual purpose. That's DevOps. like, you know, I'm trying to get this done.
[00:36:18] You're trying to get this done. We both have this. Let's do it together! Yeah. I was like, all right, that's another DevOps book before there were DevOps books.
[00:36:27] it's funny. Like, at least for me, like the more I read about this stuff, the more I see coming up in completely different contexts, like totally unrelated. You could be reading a book on just relationships and then I'll be like, oh, that's DevOps right there.
[00:36:44] but it just comes down to people the way that, like, this is really about people, the way they work, the way they get along and how they can be productive as teams and not necessarily as individuals.
[00:36:53] Yeah. Well, you've talked to any of the, people like me, who have made that jump between, like a technical role to a, like a leadership role.
[00:37:04] And like every one of us, you know, I mean, you just see it come up over and over and over and over again on Twitter. Technical problems are easy by comparison. The people problems are hard.
[00:37:17] My gosh. Oh God. Who can't do a whole podcast on people problems. But, but that's where the, like the quote, I think the real hard problem is that's where all of the, the real results come from is getting the people on board and work together.
[00:37:32] Well, You're you're changing hearts and minds. Before I jump on that, you kind of freaked me out when you talked about the five ideals. because then I was like five ideals, the five dysfunctions. Oh my God. I've heard that together.
[00:37:45] well, yeah, there's all these little like numbers, there's little groups of things. Like I had this little thought when I was reading the unicorn project is like five, wait, the three ways of DevOps, the four key metrics, the five ideals, like, wait, is there going to be a sixth?
[00:38:02] Like they all sort of like fit together in this way, but draw these kind of conclusions.
[00:38:07] They could Call to be start reading into all the numbers. Perhaps, but yeah, changing the hearts and minds stuff is, I mean, you and I were talking earlier about the guy who tries to learn how to ride the bicycle. That like, if you turn right, it goes left.
[00:38:24] And if you turn left, it goes right. Which is opposite of what you learned when you were riding a bicycle. though. Ironically, I think motorcycles worked anyways. but I like, yeah, I think, you know, the hardest thing is, is getting people to unlearn a behavior that they, this is how they work. Like I've, I've worked with SRE teams where like, they literally thought that their job was rebooting servers.
[00:38:49] And I was like, yeah, we don't want to do that anymore. And they're like, what do you mean? And like, we want to make the system stable and reliable so that we're not rebooting servers anymore. But that's my job. That's what I do for a living is reboot the servers. And we're like, yeah, you don't want to do that anymore.
[00:39:07] Like, what do you mean I don't want to do, you're telling me I don't want to do my job anymore. This is how I feed my family. And it's like, they're so far into that mindset that like, Jumping into this other way of art our way, whatever, looking at this SRE way of looking at the world to them is like learning how to ride a bicycle.
[00:39:26] That goes the wrong way. When you turn the handlebars. And like she did a really, you know, interesting thing in the book, right. Where they had, like, I don't remember how many off-sites as a five or whatever, but after the first offsite she was. like, Okay. You guys feel really good or you people feel really good about what you've done now.
[00:39:46] We're going to go back to the office and you're totally gonna screw it up. And they're like, no, no, we're on board. And then like, literally the next day, like it didn't take two hours and everybody was off back into their silos, doing their thing. And you know, it's just this constant repetition learning.
[00:40:06] You know, learning people, teaching people how to see teaching people, new ways of, of learning things. And, you know, change is hard. It takes time humans, you know, there's a famous cartoon, whatever of like the guy first and standing in the front is like, who wants change? And everybody raises their hands and he goes, who wants to change?
[00:40:26] And like, everybody keeps their hands down. It's difficult. And so it was really interesting to watch her leading that Team through change. And, you know, I've been my job, like for my company is to help people through like dev ops transformations, SRE transformations and things like that. So you could say I'm kind of crazy for signing up for that, but like, you know, part of what I need to do is help organizations move to a different way of looking at the world.
[00:40:55] And it's not hard in some respects because. Unless someone has like that terminal case of Stockholm sooner, we're just talking about where, like, they just think that their job is to reboot servers. Most people recognize that like, Hey, this doesn't feel good. Like, I, don't like being a ticket monkey where all I do every day is like, you know, press this thing here because somebody put it in JIRA.
[00:41:21] Like that's not what they want to be doing. And we, you know, you and I read enough of this stuff that we know that. That's a horrible use of a human being. They're super creative. They're, you know, they, they can get inspiration, they can collaborate. They, they can do all kinds of things like wasting their time on like doing repetitive monkey tasks.
[00:41:41] What they call them, the Google SRE book, toil, And like, it's not hard to go in and talk to an SRE group and they're like, yeah, this sucks. I don't want to be doing toil. And so then we started talking about like, okay, well, where is this toil coming from? And you know, what can we do about it?
[00:42:01] And how can we change the way that we work? But yeah, it's, you know, it's hard, but like it's a lot easier when you, you know, what is the, the old adage is like, before you can change, you have to admit that you have a problem. you can't get people to admit they have a problem.
[00:42:17] Yeah. And that's how the whole book started. Really. She calls him to the offsite and she says, look, we have a problem. This is not a team. This is a group of individuals. You have to unlearn everything that you know, and you have to start doing things differently because until you can admit that and then start unlearning those behaviors to learn new ones, like habit, forming all that.
[00:42:35] You're going to be just returning right back to what you're doing before. And that's exactly what happened in the. book. So Dave, I would probably talk a lot longer, but I want to make sure I get you out of here. So before we go, is there anything you'd like to leave listeners with?
[00:42:50] You know, just keep going and your dev ops transformations, like keep trying to make it better.
[00:42:55] You know, I just talked about, you know, people being stuck in a situation of toil, like maybe. People listening to you and I today, like are going to recognize something about their situation, where you know, they can change. They can make better. The only way to do that is, you know, not to tell everybody else why they're wrong, but it's to show them that.
[00:43:18] Hey, we're all going to be better off if we change this, like this is what's in it for you. This is what's in it for me. You know, if you come to somebody and say like, Hey, I think that you should change because it's going to help me. I think that's the. thing. It's a pipe dream. Like I haven't, I I've been doing the transformations for a long time and I, I don't, I have not seen that be effective, appealing to somebody's sense of mercy.
[00:43:44] It doesn't change anything in society. So it's certainly unlikely to change something in your company. And then, yeah, the only other thing is, I love to just hang out with SRE team. So if your SRE team is having a Friday happy hour or something, I will show up with beer on zoom for myself, and hang out and just love to hear about what people are doing.
[00:44:07] All right. So take that as an open invitation to tell Dave what's going on with your team. I'm sure he'd be happy to. Well, Dave, thank you so much for making the time to come on the show. It's been my pleasure to talk to you and hopefully I'll talk to you again some time.
[00:44:20] Yeah, thanks for having me.
[00:44:22] You've just finished another episode of small batches podcast on building a high-performance software delivery organization for more information, and to subscribe to this podcast, go to small batches dot FX.
[00:44:35] It hope to have you back again for the next episode. So until then happy shipping.
[00:44:41] Like the sound of small batches? This episode was produced by pods worth media. That's podsworth.com.