« All Episodes

Interview w/ David Marquet

Published 9/25/2020

🌎 David On The Web

 

📮 Ask a Question 

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com. 

 

🧡 Leave a Review

If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

Transcript (Generated by OpenAI Whisper)

How does your language affect your work? How does it affect your team? If you are a leader, your language is everything. That's what we learn from today's guest, David Marquet. David wrote two books on the subject of leadership. His most recent is called Leadership is Language. I highly recommend you check out this book. This book will teach you why leadership and language are intertwined with each other. It will give you a framework for thinking about, both practically and abstractly, how your language can be shaped to improve your working environment. Not only yours, but your co-workers, and most importantly, if you are a leader, the people you lead. My name is Jonathan Cottrell, and you're listening to Developer Talks. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in your career. David not only wrote a book about the subject, but he lived this experience when he was the captain of a submarine from 1999 to 2001. He was the captain of the Santa Fe, and most critically, during his tenure on the submarine, he took it from being one of the most poor performance submarines in the Navy to being at the top of the list. And we get into a little bit of that. Thank you so much for listening to today's episode. Let's get straight into the interview with David Marquet. David, welcome to the show. Oh, thanks, Jonathan. Welcome everyone out there, all your listeners. I'd love to start with a question that usually I end with, but I'm starting to learn a little bit more that people want this question earlier. And the question is simple, but can be difficult to answer. What do you wish more people would do? What do you wish more people would do? What do you wish more people would ask you about? Language, the language that they use. When I do events, often people will say, I mean, my story is I was a submarine commander and I realized that all our leadership, the leadership I've been trained to was fundamentally a coercion. It was about getting people to comply with what I wanted them to do. And we have all kinds of different tools and instruments for making people, compliant. And the only thing we, I could change really, on the submarine was the way we talked to each other. And it turned out that was hugely powerful. And so the thing that's interesting now is when I listen to people, I hear in the language and our language is structured this way, these sort of micro coercions, micro compliance efforts, and they're just built in and we don't even realize them. And when, when we're talking about, you know, we're talking about, you know, when people hear the story, they, there's a lot of times I ask, well, how, what do I do about my boss who won't listen to me? And how about, tell me, you know, what happened in the Navy after you left? There's sort of these externalized questions as opposed to what can I do? How can I change? What patterns do I have, which are unhelpful? Because we've got to start with ourselves. The only, the only control we have is over yourself. Right. Practice controlling yourself and all other things will follow. And this is something that your book goes into significant detail. Of course, leadership is language. I'm interested in, you know, of course there are some practical things that we could do, some practical parts of our language. For example, I'll bring up one that sticks with me in the book. You mentioned, Yeah. Giving information rather than giving direction. Yeah. And anytime I help, anytime I help my wife move a car out of the garage or something, every time I think of your book because of this, because I'm sitting there thinking, oh, go left. No, no. I'll just give you my hand. I'll show you with my hands how far away you are. And you can decide if you want to hit the tree or not, you know? Yeah, perfect. So, so it's that kind of thing. But I, you know, I think it's difficult for us to think in terms of replace. Yeah. This word with that word and perhaps more useful to think in terms of principles so that we can kind of derive for ourselves what kinds of language would be more useful. Can you talk about one or two of those principles that you found in this experience that, that people can think about to help them adjust their language over time? Yeah, I, so I'll give you an example, but I'm also going to challenge you a little bit on what you, what you just said, because, we do the principles all day long. All day long I can say things like, oh, you want to be curious, ask questions and be curious. And then the very next question out of the person's mouth is, do you want to go on break? And it's like, that's exactly the kind of question that we're, we're asking people not to say because it's a binary question. Do I want to go on break? Yes, no. As opposed to how strongly do I want to feel? We want to ask probabilistic questions. So, we feel it's not enough to just give people principles. These principles everyone's heard before. I don't think there's anything revelatory, too revelatory about it, but it's converting it to the, that it's then showing now here's how the language sabotages these principles. Another one of my favorites is right. Does that make sense? Well, I'll just go through a session and then the interviewer would say, blah, blah, blah. Right? Does that make sense? I was like, those are all coercions. You're trying to get me to nod my head. Yes. And so, and so it's not enough. I don't think. But, one key principle is the idea of embracing variability. The language is designed to reduce variability. It's a rush to reduce variability. That's why we love binary questions. It reduces the variability, reduces possible responses to two. Yes, no. And then there's this sort of implicit. Generally, there's an implicit right answer. So, for example, are you ready to launch the product? Implied right answer. Yes. And so, and will it work? Yes. Is this assumption going to be true? Yes. Of course, all of those things. Yes. Is not the right answer. The right answer is something like 85%. I'm fairly confident. It's a nuanced answer. And so, when I collapse uncertainty, the desire to collapse uncertainty down to yes, no. Well, 100, zero is premature in a very complex world. And so, the language we use needs to be a language which invites the person to speak in an uncertain probabilistic way, which many people are uncomfortable with. So, we have to help them. How sure are you? How confident are you? How likely is the assumption to be true? One to one. We also don't use zero and 100. You never can say it's 100%. Because that's arrogance of thinking you know the future. If you knew the future, you wouldn't be listening to our podcast. But in any event, so the principle is embrace variability. When it comes to thinking, making decisions, reflection, and letting people make decisions, it's about embracing variability, not reducing variability. So, listen in your language. For the little cues, the little ticks you have that are a rush, a premature rush to reduce variability. Yeah, that is. So, I appreciate you kind of calling that out there for a moment, the idea that these principles, there's nothing really groundbreaking new. But what I love about the book is that it walks through these patterns. For example, the binary question. Yeah. Or the expected answer. Where you're essentially you're looking for affirmation on a foregone conclusion. Right? If somebody was to say, no, the product's not going to be ready to launch. Right. Or even if they were to say, I don't know. Both of those seem like unacceptable answers in that kind of culture. So, I'm curious, you know, what did you find the most kind of unexpected findings? Yeah. What was the most unexpected finding when you were doing some of the research for this? What was the most unexpected, I guess, pattern that you found that even you maybe didn't realize was there? So, this is really interesting. When teams talk and we count their words, the number of words that the different people in the team say, let's say we just recorded number words. I don't care what kind of words they say. I don't care what kind of words they say. I don't care what kind of words they are. Just number of words. And we did this by looking at some black box recordings. And one of them that was very important was a black box recording from a ship. So, it was 25 hours of conversation. It turns out that the distribution of words exactly matched the distribution of salary. When we looked at when the captain, an officer, and a crew member were talking, they were talking about the distribution of salary. Right. So, the way the salary goes, I may have the exact numbers off a little bit, but essentially, so this is a large container ship. The captain might make $180,000. The officer, maybe $150,000. The crewman, maybe $40,000 or something. And the word distribution almost exactly, not only did it match with the captain saying the most number words, but it also matched the distribution of salary. Right. So, the captain saying the most number words, the officer saying the next most, and the crewman saying the third most. But it almost matched almost exactly by proportion. And this was over three different watch sections. So, it was a common pattern. Now, this was a ship. The reason we have this black box recording available publicly is because this was a ship. The name was El Faro, which in 2015 sailed into a hurricane, sank, and all 33 people perished in the storm. The government was able to locate the wreck and recover the black box. It's super valuable. And this idea of share of voice is really important. And so, then we started noticing it in meetings where the senior person, everyone waits. The senior person opens the meeting. Well, we're here to talk about blah, blah, blah. When people speak. One of the things we look at is in a meeting. We say, where are people's eyes? Now, Zoom is changing this. So, it's making it more interesting. Everyone's Zoom square is the same size. But in an in-person meeting, people typically sit where the most important people sit near the most senior person. And it kind of cascades down. And then when people talk, they look at the boss. And over and over again, we say, don't look at the boss. Look at the rest of the team. You're talking to your team. And so, we're talking to the boss. We're talking to the team. And so, and then it gets reflect. It's measurable. These things are measurable. This is one of the things that's really terrible. This idea that so some fuzzy soft skill. These things are highly measurable. And language was the first coding. So, early books are called codexes. And language was an encoding of information. And I want. I want people to think about languages. It's a code. And we need to change the code. We've been using a code that's about coercion and compliance. And we need to change it to a code of curiosity and embracing variability. Yeah. This is such an incredible finding, the idea that the word share roughly or almost exactly, you say, proportionally matches. At the same time, evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution each other to do, but instead they're actually collaborating. What does the word share look like? How does that ratio change? It's a lot more even. If you plotted the distribution, you would have a more even word share, which means number one, there's no one person sucking all the air out of the room. And there's also participation by everyone. There's no one or two people who are just quiet and don't say anything because the group is deprived from what those people see and what those people know. And we have that. We know, and then there's some science, some studies show that in groups where the word share is more even, those groups are more resilient. Why? Because there's more information out there for the group to make a decision on, or the leader. I don't care. At the end of the day, I don't think groups actually make decisions. Individuals make decisions. And so if you want to avoid making a decision, make sure you do it. Make sure a group has to make the decision. But if you want to be bold and move forward, have clear lines of ownership and decision-making, but the key is have all the information before you make a decision. And again, we always say push the decision to where the information is rather than the information to the decision maker. So if the coders know exactly how complex the code is, and they know the likelihood of a vulnerability, they know exactly how complex the code is, they know exactly how complex the code is, they know exactly how complex the code is, they know exactly how complex the code is, they know exactly how complex the code is, but we don't let them make decisions about, is it ready to launch it? It has to go up to the senior vice president for product or something. And so now I'm trying to explain to somebody who's not a coder, well, it's pretty, I mean, we added these two features at the last minute and blah, blah, blah. What's the impact? As opposed to just saying, well, why don't you guys tell me if it's ready to launch? What's the probability of a security that we're going to have a security breach? It's always greater than zero. If you say zero, then you're missing something. The regional. Yeah. So it feels free. No one wears a mask. No one is like pretending to know stuff they don't know. No one's pretending to hide behind something. People are willing to admit their mistakes. People have ideas. They share them out, even if they're not 100% sure. And there's this banter. And then no one gets upset when someone shares an idea that's different and people have different points of view. We're curious about that. We don't say, oh, no, no, let me explain it to you why you're so wrong. Once again, we say, oh, tell me, tell us more about that. Oh, we didn't see it that way. We're curious about that. We invite that. And then when the decision is made, you know, we're still going to launch the product. Everyone says, OK, fine, we got it. We're going to accept that risk. You've heard us out. We feel heard out. And we're going to and we can line up behind it. And so organizations are more resilient. They're more adaptive. They can change. There's less there's there's less hard feelings. And we can be our true, honest, full 100% human selves in those organizations. This is such a hopeful message for people who are currently in an organization that isn't this way. Right. And I think there's there's probably two types of maybe three types of perceptions listening to this right now. Number one is the leader who says, oh, yeah, we already do this. Right. But they're not actually doing it. I'm curious about your thoughts about that persona, but also the individual who is kind of the individual contributor, the coder who is experiencing all the bad, the cultural kind of disease. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. Right. I can't help you. You may be. I'd say the odds are pretty low, though, because the language that we've all grown up with is an inherently coercive language. Unless you've deliberately decided, I'm going to learn a new language and speak differently. And there are a few people who seem to naturally have this more embrace of language, but they're very few and far between. And those people, what they say is, I try to do this, but I know I can be better. People say, oh, I'm already doing this. Probably what they need to do is record themselves and listen to themselves and or ask their team. They don't realize what they're doing. I was at a meeting with, so we had a big construction company as a client, global construction company. I'm sitting in the meeting and the foreman stands up and he's talking to the carpenters. And he's very, I mean, imagine a brusque foreman on a construction site, exactly the archetype. Bah, bah, bah, do this, this, this, this, this. A bunch of F-bombs thrown in for effect. And then the safety guy who's my sort of walking me around, he's my minder, so to speak. And he realizes that this is not, what we've been telling these guys that how to run these meetings. And so he's going to try and rescue it at the last minute. He asks six questions right in a row. They're all, everyone is binary. They're questions like, so we're ready to go, right? So we don't want anyone's hard hat to blow off, do we? Everyone has a binary question. Everyone has a predetermined right answer. And he doesn't even, he doesn't even actually expect anyone to respond. No one says anything. And they say, okay, let's go to work. And this is a guy who thinks he's doing everything right. And you got to get outside your, I call it, most people spend their life looking at the world from behind their own eyeballs. You got to get, you got to get away from it. You got to get out from behind your eyeball. You're trapped behind your eyeballs and behind, like behind my own, right? And so he's going to try and rescue it. And he's going to try and rescue it. And he's going to my keynote is brilliant. Of course. And, you know, you hear, see, I already see you slip in. See, even though I talk about this, I, I still say things that, that I'm programmed, we're programmed to say these things. So you got to get external feedback, get out from your own eyeballs, look back at yourself from an external perspective and see what, what you're really doing. You are 100% doing something. that is making it less likely for someone to share, somehow nudging them towards agreeing with you, that kind of thing. As for the person who says, well, I'm the subject, I'm the victim of this kind of language. If the person's evil, you got to get out of there. But if they're just thinking they're doing the right thing, but they've been programmed to tell people what to do, like 99% of all the other leaders, don't start by challenging their authority. This is the big mistake. I know I've made it, which is, oh, you just told us that we're going to launch the product. I think it's a bad idea. We should not launch the product. So you're just basically, you're challenging them authority. You're telling them they're an idiot and you're smarter than they are. The first step is to simply gain the right to be heard. And that comes with simply description. So it's, I think about it as the buttons on a BCR, pause, rewind, fast forward. So pause is, I'm just freezing. Let me tell you what we see. Here's what the team sees. In the last two months, we've added four features we didn't expect to, blah, blah, blah, blah, blah. This is description. Then assessment, that's rewind. How do we get here? It's, so we, as we did this, we didn't do all the checks that we normally do. We didn't do all the checks that we normally do. We didn't do all the checks that we normally do. We didn't do all the checks that we normally do. So we're accepting more risk when it comes to security vulnerability. And then we go to forward, which is what should we do. And at each step, you have to pause and make sure that you have permission to go on to the next step. And if the boss says, no, I've heard enough, launch the product. So, okay, great. We're going to line up behind you. We're going to launch the product. We'll do the best we can. And then, and then practice that, but you earn the right to be heard. And then you have to pause and make sure that you have permission to go on to the next step. And then, and then practice that, but you earn the right to be heard. And then, and then practice that, but you have permission to go on to the next step. And then you have permission to go on to the next step. And then, and then practice that, but you have permission to go on to the next step. And then, ideally with time, the boss will say, okay, tell me what you guys see. All right. Tell me what you guys think. All right. Tell me what you guys want to do here. Now, if you're not moving in this direction, you got to get a new job because there's a health toll of being stuck someplace and not having control over what you work. And so normally what we say, if your boss is talking about holding people accountable, we know what that's code for. That's code for, I'm going to tell you what to do, when to do it, how to do it and what, and what the timeline is and what resources you have. And then when you don't do it the way I want you to do it, I'm going to quote, hold you accountable. And, and that looks like, uh, you're, you're getting a performance improvement plan or something like that. Yeah. It's terrible. It's terrible. David, thank you so much for your time today. We, it looks like we are running out of time here. Uh, and, uh, I just want to say, I appreciate the work you're doing and, um, thank you for the books that you've written. Uh, I think you are improving the world of software engineering, maybe without even realizing it. So thank you so much. I appreciate it. Cheers. And thanks for everything that you, you and your listeners do. Thank you again for listening to today's episode, this episode with David Marquet, the author of Leadership is Language and Turn the Ship Around. I hope you enjoyed this, uh, this discussion with David, and I hope that you will go out and pick up a copy of Leadership is Language, especially if you are in a leadership role, but also if you aspire to a leadership role, this is one of the most important lessons you can learn. It's actually a series of lessons on how your leadership and language are intertwined. Thank you so much for listening to this episode. If you enjoyed this episode, I encourage you go and leave a review for us in iTunes. This is the most important way to help Developer Tea continue doing what we're doing. And it's not just iTunes anymore. There are other platforms, Google, Play, for example. If you can leave a review in whatever platform you prefer using, that can help other engineers like you find Developer Tea. Thank you so much for listening. This episode and every other episode of Developer Tea, along with the show notes, can be found at spec.fm. Today's episode was produced by Sarah Jackson, and my name is Jonathan Cottrell. Until next time, enjoy your tea.