This is a transcript of episode 222 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.

We describe Marquet’s “Psychological Ownership” and how it goes beyond the “turn signal” we’ve advocated before when building trust with stakeholders. Then we go into applications to our clients, Microsoft Excel date formats, and the candy preferences of heavy metal bands.

Show links:

Listen to the episode on SoundCloud or Apple Podcasts.

Introduction

Listen to this section at 00:11

Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.

Jeffrey: Hi, Squirrel.

Squirrel: So you told me that you had come across some really great ideas about signaling what you’re going to do. This is something we keep telling our listeners to do: talk to executives, talk to the marketing department, talk to the salespeople, talk to the CEO, find out what the real mission is, find out what you’re trying to do and conform to that. Whether you’re in technology or not, what you want to do is make sure you’re signaling. You said you’d found some really great thoughts on how to do that.

Jeffrey: Yeah. We’ve talked in the past about the value of signaling intent. The article was actually about radiating intent and used the analogy of making a turn signal when you’re going to be turning. What I was encountering was people would hear that advice and say, “okay, I need to be telling people what I intend to do.” But then they would do it in a way that wasn’t wholly effective, in the sense that as soon as they would signal their intent, the next thing that happened is that someone would ask them a question and things would kind of fall apart. What was happening is they weren’t anticipating everything that they should have in mind when they go and share their intent. I came across a clip from David Marquette, it’s one of the really nice sketch/note type video illustrations. David Marquette people might remember from the book Turn the Ship Around, where he was a sub-commander and got great results by delegating to his staff, and really changed the culture of the ship; some really good lessons in that book. But in this particular part of the video he’s talking about how he got better: instead of just delegating, he got to the point where he could establish psychological ownership in people. What’s interesting here is he’s describing this as a commander, what he wanted from people, and he changed how he operates. And I think the key insight for me was he’s describing essentially what every leader wants, but won’t tell you. What’s nice here is he’s laying it out, because what he said is “people come to me with their intent and I then say, ‘what do you think I’m thinking?’”

Squirrel: “Hey, Captain, I’m going to submerge the ship.”

Jeffrey: Yeah, exactly. So the response “what do you think I’m thinking here,” people at first were caught out by that. The fundamental thing was like, “well, is it safe?” So then people would come and say, “I intend to submerge the ship, and here’s my checklist of things I’ve done to make sure it’s safe.” He even went beyond that. After the first question, he followed with “is it the right thing to do?” So the idea is that people are coming now with their plan, with their intent, and actually providing the details that went into why they chose that. It struck me that this is a lot like the back-briefing we’ve also talked about in the past, and it’s just a different mindset that people can have: to not just radiate the intent, but also how they got there. Be prepared to talk about those things because actually, the CEO or the executive you’re talking to, they really want to trust you. They’re happy that the people doing the work are thinking through the right thing to do and coming with the plan’s intents. They’re just looking to be reassured.

Squirrel: Another sort of a flavor of what they won’t tell you is they’re doing spot checks. If you’re a product manager or a technical lead you might have encountered this when you’re doing a code review or testing of a piece of software. You probably don’t check every single case, every single possible line of code, every possible way that the software could fail. But you do a few, and that builds your confidence. This reminds me of a very, very old blog post. I bet there have been two entire generations of developers since Joel Spolsky and his blog, which were the main way of getting advice about software. I mean, we didn’t even have podcasts, can you believe it? But way back in 2006, he wrote about having a product review with Bill Gates, who it’s very clear was doing this exact kind of check, and the end of the review after Bill has peppered Joel with all these questions about how Excel works—he was building Excel back in the 1990s—he asked, “well, what about dates? Dates are hard to handle. Do we match with the main competitor at the time? Do we do dates the same as them?” And Joel stopped and said, “well, we do, except for January and February 1900.” And Bill said, “Oh, okay, thanks,” and left. What he had done was, by peppering Joel with questions, he hadn’t checked the entirety of Excel. He couldn’t possibly, right? This is a massive product, but he had checked enough that he had found confidence, he had trusted but verified that Joel actually knew it. Joel actually learned later from people that everyone always got a question that they couldn’t answer. This was the first time anyone had seen one where Joel had had an answer for the hardest question. So the advice I think we have for our listeners is: when you’re going to signal your intent, when you’re going to let the captain know what you’re going to do, come with your checklist! Be ready, anticipate the sorts of spot-checking questions that you’re going to get, because that will do two things. One, it will prove to them that you’re worthy of trust, that your direction is good. Also, it will make you worthy of the trust because you will have actually checked the things. So it will have two good effects.

Deserving by Earning

Listen to this section at 06:42

Jeffrey: I think that’s actually the key point! You are worthy of trust when you’ve put the work in to anticipate what might go wrong, and you’re ready to demonstrate that. That’s when you’re ready for the trust. Before that, if you’re saying “why don’t they trust me? Why don’t they trust me?” Have you demonstrated your trustworthiness? The way that you do it is to have gone through the details. When I was telling one person about this and giving them this advice, I told them a story that I heard a long time ago. The green M&M story, which people in our audience may recognize, was about Van Halen. When I first heard this story it was in the context of “what kind of prima donnas these people are, that they even specified in their contract that when they would come to a venue-“

Squirrel: Jeffrey, I have to correct you. It’s brown M&Ms.

Jeffrey: Oh, was it really?

Squirrel: It’s brown.

Jeffrey: Thank you. I appreciate that.

Squirrel: That’s precisely the sort of detail that someone might want to check! It’s like, “well, Jeffrey, he wasn’t sure whether it was green or brown. I’m not sure how well he did his research.” Don’t worry. I’m not going to beat you up like that.

Jeffrey: So it was this story that they were prima donnas. They wanted no brown M&Ms. So they specified that they must have M&Ms backstage as a treat. But they had to have no brown M&Ms in the bowl.

Squirrel: “Oh, those rock stars, you know, they’re just such perfectionists, they’re probably going to trash the place when they’re done.”

Jeffrey: Yeah, but it was decades later that I heard the rest of the story: Van Halen was one of the first big venue rock shows that would tour second-tier cities. So they were often the first time you had a such a big stage production in some of these smaller venues, and there were huge safety concerns.

Squirrel: They could fall through the stage, the whole thing could collapse under the weight of their drum kit or whatever it was.

Jeffrey: That’s right. So what they did is they added this clause into their contract as as a kind of a safety check. They wanted the kind of venues where they were very diligent about having read all the terms of the rider that lays out how the stage needs to be set up and all the safety standards included. If they were diligent enough to read this and follow through on the M&Ms, then they probably had read everything closely and done what was needed. But if they came in and saw brown M&Ms in the bowl, then they knew they were going to have to go through and check all of the items and make sure that it was going to be safe. That’s what I told this person I was coaching, I said “when you come up and tell your story about what you want to do, they don’t have time to analyze everything. Executives are busy, and they want to be reassured. So what they do is they look for the brown M&Ms. They are going to ask some questions just as a way to reassure themselves that you’ve done your homework, and if you can demonstrate it, you’re great. But if they find a brown M&M, if they find something that doesn’t add up, then suddenly it’s like, ‘okay, well, I guess we’re going have to look at this much more closely,’ and suddenly you’re going to feel micromanaged. But it’s because you failed to establish trust.”

Squirrel: There you go. So I guess our advice to our listeners is if you’re feeling mistrusted, either by your developers from outside technology asking them to do something, or inside technology asking somebody else to trust you that you’re building the right product, make sure you’re dealing with your brown M&Ms, that you know whether the dates are working on January and February 1900, have all those things buttoned up and anticipate what they are going to ask you. If you have that buttoned up and ready, you’re going to be in a much better condition for being trusted and then not having to do it in the future.

Jeffrey: That’s right.

Squirrel: Fantastic. Thanks, Jeffrey.

Jeffrey: Thanks, Squirrel.