Listening to Your Stakeholders is Harder Than You Think

Rob Collie (00:00): Hello friends. Doing something a little bit different this week. It's just me. Solo podcast. And as it happens, I do have something on my mind that I think is both relevant and valuable to share. In the Coen Brothers movie, Barton Fink, John Turturro's character has multiple opportunities to listen to stories that John Goodman's character very badly wants to tell him. And in each instance, John Turturro, his character anyway, is so focused on telling his own stories that he doesn't have any interest in listening to what John Goodman's character has to say. And this ultimately ends up having some rather severe negative consequences for John Turturro's character. And while thankfully I don't have any Barton Fink-style consequences on tap in my life, and I also hope that you don't either, I have recently been reminded about how difficult it is to truly listen, even when you think you already are.

(01:02): And to take the immediate hard 90 degree turn into business relevance, the place where this lesson is most applicable is when you're thinking about your stakeholders, the stakeholders for any project, any endeavor that you're working on. And this is true whether you're the sponsor of a project or the hands-on developer of a project. So whether you're got your hands dirty down in DAX and M or whatever language you're coding a project in, or whether you have nothing to do with the direct implementation, and you;re instead the business leader who's driving this process while others actually perform the technical work, the value of this lesson is the same.

(01:48): It is very, very rare that we are sponsoring or implementing any sort of data project just for ourself. Because one of the most amazing opportunities that data affords us is the ability to operate at scale, the ability to see things that would take many, many lifetimes to see if you were just having to directly observe them, the ability to inform and advise action across a larger team that, again, one person couldn't do. Well-implemented data solutions are a means to act at scale without requiring all of the labor that it would normally require to act at scale.

(02:29): So most of the time we have at least several other people, sometimes hundreds of other people, that our data solutions are meant to serve, they're meant to help them or at least involve them. Even if we're not thinking of the data solution we're implementing as a means of helping someone, which most of the time we should be, we still need those other people to be bought in to the solution in order for it to work. And the chances of our success with any such endeavor, and in fact, not just the chances of success, but also the degree of success, the degree of impact, you can think of it as being at least partially proportional to how well we're listening to those people.

(03:13): And it's very difficult to listen actually, when you think about it, because you, let's just focus in on the sponsor, let's say you're the sponsor of this project, you're the one driving it. That kind of means, almost by definition, that you're the one with the vision. You know things, or are thinking things, that some or all of the stakeholders are not. And even if your stakeholders are incredibly enthusiastic and are almost actually in the role of pressing you for something, even when you're in that situation, which is by the way, one of our favorites, even then the reason they're coming to you is because you understand or they believe you understand the art of the possible better than they do or you have the time to engage with it that they do not.

(04:00): So listening to stakeholders always kind of starts off with an imbalance. There's sort of this implicit assumption running through everything that you, the sponsor, the driver, you're the one who is supposed to know. And once that dynamic is in place, which it almost always is, oh, it is so easy to turn off one's ears. And this is one of those lessons that you're kind of never done learning. You learn it, and then as soon as you learn it, you get a reminder of it, you begin the process of forgetting it again, until you get your next reminder. Well, it turns out I was due for my reminder and I did indeed receive it.

(04:37): A couple of weeks ago, we had Ryan Spar on the podcast, co-founder of Indy Inline Hockey, to talk about our collaboration on a set of dashboards that I built for our Indy Inline Hockey league. There were a number of valuable lessons and relevant takeaways in that episode so if you haven't listened to it, give it a listen with the added bonus that the dashboards in question are publicly available. And we'll link to those dashboards again in this show notes for this show. So definitely go take a look at those. On a computer, not on a mobile. They're designed for full screen use. But then after that episode, I continued to learn lessons.

(05:17): So think about the number of opportunities I had to listen to my stakeholders in the course of building these hockey dashboards. Sort of the first run through of listening happened while I was building them, while I was collaborating with Ryan, mostly over text messages during the holidays, to create them in the first place. So I had the opportunity to gather information from my stakeholder during that process. And then of course, I get the feedback, the tactical feedback as we're going on how this is looking and whether that's understandable and then all that kind of stuff. And there's an opportunity to absorb information there as well. So that's the second opportunity. And those are things that you usually get. You get those opportunities on a project. You get the implementation, you get the iteration, you get the feedback. So that's all kind of standard.

(06:01): But then in this particular project, we had some additional opportunities for listening. Number one, we sat down and recorded a podcast, because we had a conversation about it, a very lengthy conversation about it that wasn't even aimed at further development. A rich hour plus conversation, just of reflective nature about the project that we've been working on. How often do you do that in your average project?

(06:27): So then after having that conversation, I listened to the podcast afterwards. You'd think that if you're participating in the podcast, you're hearing it all, but no, you're having a conversation and so you're not listening at the same level as you are when you put on the headphones or whatever and listen to the whole conversation again. And then, folks, my wife wanted to listen to it so the two of us listened to it in the car together. So basically, in a way, I went through that conversation three times.

(06:57): And on that third time through, that third listen is when it hit me, of all the things I'd been missing. It was like the fifth or the sixth time at minimum that I had heard Ryan say, "I like this chart or I like this visual because, hey, I'm on it. I appear on this chart." And so many of the dashboards I had built are naturally sorted for the top. Who are the top performers in a particular category and things like that. Most of the league, most of the people in the league, are not top performers. So most of these dashboards don't show most of the people. And that was true at the moment that the podcast was recorded. In a way I thought the project, I didn't think it was completely done, but I had a sense of nearing completion on it.

(07:46): And when you think about the goal of these dashboards, the "business value" of these dashboards, it's not business. The value of these dashboards, the intent, is to increase people's enjoyment of the league. When you stop and think and you look at it through that lens of clarity, how obvious is it that to the average stakeholder, the members of this league, them not appearing on the dashboards makes them kind of uninteresting. They don't enhance their enjoyment of the league.

(08:17): So there I am on the third listen to the podcast, with this lightning bolt realization moment of, "Oh my God, I have not done a dashboard page, a report page, that is dedicated to all of the information about a single player, with the ability to toggle which player it's showing," like a single player deep dive. Wow, why had I not done that from the beginning? This is just a colossal miss. And it required so many, essentially redos, so many opportunities to listen, that I don't normally get, that most of us normally do not get in a project, to have something that obvious finally clunk me upside the head, like a mallet.

(09:00): And other things he'd been saying over time and in the podcast like, "Oh, I like looking at this one because then it sort of shows me who I'm similar to and surprisingly similar to that I wouldn't have expected." And now with these new ears on, that I suddenly found attached to my head while I'm listening to the podcast for the nth time, I go, "Oh, right, that's something that we could put on the player deep dive page. Let's use the formulas." Go looking through the data for the players that you're most similar to. And I came up with something to put on that page. And when I showed it to Ryan and he started kicking the tires, he's like, "Oh my God, this is so dead on," over and over and over again, "This thing is so accurate." And it was just clear to hear how much joy it was bringing him.

(09:42): This was a dashboard page with a radio button on it where you could select 100 different players. I kind of got the sense he'd gone through and clicked every single person. Why, why, why, why, was I missing this from the beginning? And then with that same newly discovered set of ears, I realized that Ryan, as the commissioner of the league, his number one workflow during the week is to write preview messages before each week's games. He writes a several paragraph summary preview that goes on Facebook every week trying to get people thinking about, excited, and smiling really about the games that are going to be played that Wednesday. And I had never produced a matchup analyzer page that helps him, that would facilitate exactly that workflow. What are the week's games? Who's playing who? What happened last time those two teams played each other? Is the last matchup relevant?

(10:39): In the matchup analyzer that I built for him now, he can look and see what the result of the last multiple games this season between those two teams, what those results were. He can drill down and get the detail of who showed up, who wasn't there, who performed well, who underperformed relative to their average. And it gives him narratives that he can talk about, that there would be no way he could just have from memory. Help him write his weekly preview, help him. And then that feeds into everyone else's enjoyment, engagement. There's screenshots of the matchup analyzer and sort of showing how it broke down and all that kind of stuff.

(11:17): These things should have been absolutely brain-dead obvious to me, but they weren't. And I know it's like a silly kind of non-business example in some sense. But I think that this dynamic I'm talking about, I think it's 100% active and relevant in every business project as well. And, yeah, it's been a long time since I have implemented a project like this. So in some sense, I might be rusty. I don't do billable client work for our clients at P3 anymore, but I still think I'm pretty good at understanding where people are at and what would be delightful to them and then turning that into experiences that deliver on that. I'm at least better than average at that, rusty or not.

(11:58): And so it's a sobering thought to me that if I can miss things so obvious in hindsight, and only catch them because of an extraordinary process that allows me to sort of hear the same things over and over and over again, which we almost never get in our professional lives, or heck even in our personal lives, that tells me that all of us are probably missing really important opportunities. Even when we're succeeding, we're missing things that could make us and our stakeholders more successful. So I think I'm going to slow down a little bit next time. Yes, producing results to get iteration, to get feedback, is an important part of the process, and it's something that the Microsoft family of tools allows us to do that traditional tools and really almost all other tools today don't allow for. Get that real-time, confident, transparent feedback by giving people something to respond to, but at the same time, reserving some space in your brain for the things you haven't thought of yet. And be tuning in to those little nuances and the things that people are saying.

(13:03): They're not going to sound like requests. None of the things that I caught on the third or fourth listen that Ryan was saying, none of them were formulated as requests. He wasn't saying, "Hey, it would be great if." But that doesn't mean that they shouldn't be requests, that they can't be thought of that way.

(13:21): I think the other actionable tactic that we might be able to adopt here as well is to make time for just relatively unstructured reflective conversation about your stakeholders interactions with the work so far. And again, going back to it's so valuable to put tangible results in front of people, to put reports, dashboards, solutions, apps, rough drafts of them if you will, even, to be able to have them interact with those things and react is really valuable. And I think the thing I'm learning here is that one of the ways that we can collect feedback is to have those unstructured, informal conversations about them, as opposed to making it always just feel like an interview about what should we do with this chart should make that chart different? Or is that metric right? We should do all of those things too. But there needs to be time for just good, relatively light and easy, low pressure type feeling conversation about the work so far, about their thoughts about it, their reactions to it, even their emotions about it.

(14:29): It's a little weird, but even those are important because they are clues to other things. Because again, circling back to the very beginning, you as the sponsor or as the developer, you do know things. You do have things about you that are different from the stakeholders. You do have a responsibility as the art of the possible person to connect dots that your stakeholders won't connect for you. But you have to hear the dots, don't you? So we'll be back next week with a regular episode, but in the meantime, let's go out there and listen, shall we?