Communication Failure Modes

About this Episode

In this episode of the Acima Development Podcast, host Mike welcomes returning contributors Kyle, Will, and Dave for a lively and insightful discussion on communication and its failure modes—especially in engineering and development teams. Mike kicks things off with a humorous but illustrative story involving his children, hoverboards, cactus spines, and a major context mismatch with his wife. This leads into the first failure mode: people interpreting the same situation differently due to differing contexts. The group agrees that a lack of shared understanding often derails conversations and projects, especially when assumptions go unspoken or expectations aren’t clarified. Will and Kyle emphasize the importance of providing full context when asking for help or collaborating remotely, noting that even minor omissions can significantly delay progress.

The conversation then shifts to another failure mode: assuming communication is complete after initial planning. They highlight how this mindset leads to integration issues near the end of projects—when it becomes clear that vital tasks or dependencies were overlooked. Dave tells a memorable story about a sound engineer who foresaw this issue and left a self-contained module called “OYWNS” (“Oh Yeah We Need Sound”) that could be plugged in later, exemplifying proactive thinking. However, the team debates whether these are truly communication issues or just planning failures, ultimately agreeing that both planning and communication must be iterative and responsive, especially in complex, cross-functional environments. Mike brings in the Agile principle of “customer collaboration over contract negotiation” as a more effective framework to reduce these last-minute failures.

Toward the end, the group introduces a third major communication failure: speaking without tailoring the message to the audience. Whether it’s explaining unit testing to a non-technical relative using car analogies or trying to influence C-suite executives without drowning them in technical jargon, they agree that effective communication requires strategic translation, not just transmission. They also discuss how hierarchy and communication chains create distortion, using examples like long managerial handoffs or segregated teams that never speak directly. The episode closes with a call to action: be deliberate about context-sharing, break down silos, speak in your audience’s language, and ensure someone owns the responsibility of facilitating true collaboration.

Transcript

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I am Mike, and I am hosting again today.

With us, we have long-standing contributor Kyle and Will Archer. Kyle Archer, Will Archer-no relationship to each other [laughs]. We have Dave Brady--

DAVE: Howdy, howdy.

MIKE: Who hasn't been here for a little while, but he's here today. He's been out on leave because of some medical challenges, so we're really happy to have him here with us today.

DAVE: I'm delighted to be vertical and to be here.

MIKE: [laughs]

DAVE: Yes, that was optional. That was an elective for me, was being vertical. So...

MIKE: So, great having you with us, Dave. We are looking forward to having a good conversation. And speaking of conversation [chuckles], that's what we're talking about today. We're going to talk about communication and communication failure modes.

I'm going to start, as usual, with a story, but I’ll introduce the topic first. To tell you a story...A few weeks ago, I got to do a little bit of setup here. So, you probably all know about hoverboards. They're not hoverboards, right? But it's like a Segway without a --

DAVE: Segway with no sticks?

MIKE: With no stick, exactly. The self-balancing scooter that you stand on and move around. They're ubiquitous, especially among young people and kids, and they're all over the place. We’d had one in my house for several years, and the kids played with it, and they enjoyed it.

My wife discovered something. You can put a seat on it, with a bar that comes out from it, and you put your feet on it. And it's got handlebars that you can lift up and down, two bars that you can lift up and down. So, you can adjust, you know, you can move it forward or back like you normally would by using your hands. And it makes it into, essentially, a little electric go-kart [laughs] because you've got a really low center of mass, you can just go full speed and have all kinds of fun.

So, my kids at home, at Christmas, that’s what they all got, and they love it [chuckles]. There's a ring around my house that’s...[inaudible 02:32] dead. [laughs] They have flattened it so much, not every day, but often. And [laughs] they have a great time. So, that’s the first line. So, I’ve got to tell a couple of things that are going on here.

In my office, I actually have a lot of cactus plants. Back during the depths of the pandemic, I had a little extra time and started doing some grafting experiments with cactus. It was fun. I've got quite a few cacti that I had some fun with that are now growing [chuckles] and taking up a lot of space in my office. But I like to take them outside in the summer.

So, a few weeks ago, late spring, yeah, the weather was going to be good, so I started bringing out these cacti. And I've got the gloves on, but sometimes you get the spines and especially the little fine...they're called glochids. I don't know if you're familiar with them, but they're fine, little spines, and they fall off really easily. And they get in your gloves, and they get in everywhere. And they're really hard to pull out, and they're itchy and awful [laughs]. So, they just get in everything. They are very hard to get rid of. It's like sand in the car after you've been to the beach, you know, it’s everywhere. Same kind of thing, it gets in your gloves.

So, I was bringing out these cactus plants, and I was getting more and more in my gloves, and my hands were getting itchier and itchier. And I got most of them upstairs, and my kids were out [inaudible 03:49] around the house on their hoverboards. And [chuckles] my four-year-old he comes up a lot in these stories because he’s a great source of stories. He ran his into a raspberry bush [laughs].

DAVE: Those are spiny. Oh.

MIKE: They are very spiny. I think he even did it deliberately, like, "Oh, I'm going to run into the bush, see what happens." Ooh, and then he realized that was not good. And then, he blamed the scooter because he thought...and he blamed the bush, “That shouldn’t be there [laughs].” So, he was angry at his scooter and refused to get on it because he thought it would hurt him again. And so, he started chasing my daughter, wanting her scooter. And --

DAVE: Because her scooter has never driven him into the bushes. His logic checks out, yeah.

MIKE: That’s exactly right. So, he's chasing her around the house, screaming. And I’m like, I should do something about this. But my hands are full of spines. And the thing is, I’ve been going up and down. My belt was kind of loose, and my pants had been falling down. So, I’ve got this series of problems: If I start running around the house, my pants are going to fall off. But if I try to take my gloves off and redo my belt or pull my pants up, I’m going to get spines all over my belly, which I don’t want. So, urgent situation. I can do nothing about it.

So, I take off my gloves [laughs], set them down, lift up my pants, adjust the belt, and I’m about ready to go out. And my wife comes out, like, “Um... what are you doing?” I’m standing there with my belly hanging out [laughs] with my belt while my son is screaming. He’s really yelling out there. Somebody’s going to, like, call the authorities.

There was a lot of context that was missed in this situation. And the way she was perceiving this situation was very different than the way I was perceiving the situation. We both knew there was a problem and me standing there I was trying to solve the problem. And [chuckles] it certainly did not look that way to her.

DAVE: Right. “What are you doing?” “I'm spanking our boy. What does it look like?”

[laughter]

MIKE: Not the topic—not spanking—but that kind of situation is incredibly common, where one person has context, the other person doesn’t. And you may be thinking you’re talking about the same thing, but you’re not, because both of you see the situation so differently. And neither of us was wrong. She looked “There is a real problem going on here. Why aren’t you doing something about it?” I was thinking, “I am doing something about this real serious problem, and you’re not seeing it.” It was very cordial, by the way—no yelling at each other. She just was wondering, “What are you doing? [chuckles]” We worked it out.

But this kind of idea where people see things differently it’s just everywhere. And I think it's one of these failures of communication, not just this kind, but there are a variety of these failures of communication failures that happen in engineering. And they are the problem, I would say [chuckles], with almost anything. It almost always comes down to some sort of communication failure. And I could tell stories, a variety of stories, and I probably will tell a few here. We're going to talk about, what are these communication failure modes, and what do we do about them?

My introductory story gives an example, you know, different context. You may be talking about the same thing, but your context means you're seeing things very differently, and unless you resolve that, you’re not going to see eye to eye. There is one example. Feel free to run with that. I would like to hear from the panel here: What are some communication failure modes you’ve experienced, and what’s the underlying reason behind it, and what can you do about it?

WILL: The biggest thing that jumps out at me when I think about sort of failure modes of communication is a lack of, I don't want to say respect, like, regard, care given to making sure that people have the same context for a problem that you do, right? Like, when you'll be working on something, it'll be all day, every day. You've been chewing on this bone for a couple of days now, right?

You narrow it down to some external team, some other partner, some other person. And you ask them a question, but you're sort of like...it isn't that your question doesn't make sense; it's the question assumes a certain level of context they don't have, right? And then, you run into all kinds of problems, which is sort of like a bunch of follow-up questions, like, sometimes people can get defensive, right, where it's like, “Hey, I've got a problem with your API.” “Well, if you've got a problem with my API, you've got a problem with me,” right?

And I think you can mitigate a lot of that defensiveness with, I mean, that's a separate problem, right, like, it's a separate issue. But if you can really lay out your case and your context and what's been going on, why you're doing it, why that path has led them to my door or your door or whoever, right, like, what brought you here and the reason that you think this person can help, right, like, there's just a lot there.

And really breaking that down is pretty laborious, but it improves outcomes dramatically, especially in, like, a distributed workforce. Like, you’ll find yourself in a situation where, like, you'll drop some Slack message on somebody. And to a very large degree, whether you get a reply in five minutes, or an hour, or maybe today, depends directly on how much context you provide, how much “What the hell did they even mean by that?” that you're asking them to do in this public help Slack channel.

MIKE: I've seen that to be so true. I'm thinking about a junior developer saying...it doesn't even have to be a junior, but it could be a senior developer. “I'm getting an error when I try to sign in,” and be like, well --

WILL: Story of my life, buddy [laughter].

KYLE: You just described every message that comes into the DevOps channel [laughter].

MIKE: What you've just done is you've asked other people to go and find all that context for you. And it's a real problem. It means that...I could go as far as to mention this happens in the DevOps channel. It's not very polite, but even if you're doing your best, I mean, if you're ignorant of it, you're not going to get a good answer. But if you come with somebody who says, “Well, I can't log in, and this is what I tried, and this is the error message that I got,” well, then that's catnip to an engineer who's like, oh, there's a problem. What am I going to do about that? And they'll go in and they'll solve it. It's just a totally different experience when you provide that context.

DAVE: If you can't give me context, at least give me steps to reproduce the problem, right?

KYLE: Yeah.

DAVE: Because then you need context.

KYLE: Links. Links are huge.

DAVE: Links, logs.

KYLE: Let me know what you're looking at.

DAVE: There's a reverse to that, though, right? Because it's not just that if you don't provide all the context, it's bad. It's more like, you have to do an impedance mismatch because we've all had the problem where you're fighting with the compiler, and what the heck is going on? You just moved into a new machine, and everything was fine, and now everything is just thrown up on this one service. And you sit back and you're like, why won't this stupid thing work? And somebody two desks over will go, “You got a new machine?” “Yeah.” “Disable pthreading.” And they go back to typing. And you do it and it works.

Because just the sound of your error, the tone of your voice, the time of day you were having this problem, right? You just got out of your sync meeting, and just the mention of “Why doesn't this work?” was enough for this person to grasp all the other context, assemble it, and hand you the correct answer.

MIKE: So, context is huge and one of the key failure modes, right, I've seen in communication. I think we'll hit on some other critical ones here, but I think that that is absolutely one of the important ones. That’s what I led out with, right? And the way to solve it, as we've been talking about, is give people those clues, right? Give people the breadcrumbs they need to be able to do something. If you don't build that shared understanding, then one of you is going to be standing there fixing their belt, and everyone's going to...”What are you doing out there [laughs]?” This is just going to happen.

I think one thing that I've taken to doing is in almost any group conversation where we're talking about a project, I will start by laying out the reason that we're working on that project and a summary of what we're doing and why. A lot of people in the meeting, I'm assuming, already know that, but almost I always get expressions of appreciation. Because even if you have been working on it, maybe it's been a week, and developing that foundation for the conversation is useful. Even if it feels a little silly, even if it feels a little redundant, even if everybody knows it, it gives you something to run with. Without that shared understanding, you don't really have language.

KYLE: That's an interesting one, because we actually had a leader that posted a topic at our work here a while back, and it really kind of stuck with me. He talked about how his father would start conversations with people, and he would provide that context, like, hey, I'm such and such from this interaction, from when we did yard work together, or just to kind of give context so that actually clues people in on who you are and where you're coming from, why you're talking to them.

You gave a very specific answer to engineering, which is great for this topic but I'm just saying, like, in general, for everything, just providing context, even in introductory conversations with people, it's very helpful and can save embarrassment, even.

MIKE: Yeah. I loved that also. Like, “Hi, I'm Mike. This is where we met.” Because they're thinking the same thing, like, you may not remember their name, and maybe you don't. And that way, you're giving them permission to do the same, right? You're saying, it's okay if you don't remember me. That's normal. Let's build some shared understanding.

DAVE: How do we make sure...so, I've got this idea bouncing around in my head. It might be a dangerous one or a dumb one. We won't know until we release it into the world.

I've been fascinated for decades on unit testing my own brain, like, coming up with things that are external to my meatware because a telescope can look at anything but itself, right? A microscope can examine anything but itself, right? Same idea. And the brain, it's hard to diagnose what's going on, especially because the order of operation is always back...like, we always think that we reason our way through something, and then we feel good about the decision. No, you integrated it; you synthesized the emotion, and then you back-justified it in your brain. We've got the receipts on the fMRI to show that that's actually what you did. But your brain tells yourself, no, I did it the other way around. You literally give yourself this reverse receipt that it's backwards because that would be logical.

Context: How to debug context is starting to feel, to me, like an integration test for my brain, where there are things I can do with my unit test brain. Like, I can pull up a video game that I've played tons and tons and tons that's challenging for me. And if it kicks my trash, I know I'm done. I know it's late at night, and I've lost my dopamine from the day, and I've lost my focus. I should put the computer down. If I open it, and I play it, and I just get a high score, I'm like, okay, I'm as locked in as I think I am. Let's go be productive.

I'm wondering about integration tests, where if we are following these rules, we should see this change. We should see this thing happen. You know, given a situation where I know this, and you don't...and this is the beauty of it: going into the problem, you never know what the other person doesn't know, right? So, it is a challenging unit test. So yeah, I'm just thinking through because it does feel like that, to me, like an integration test where you say, you log into the website, go here, and in the back end, you're bouncing back through seven different services, da, da, da, and at the end, you end up with a lease or with the end product of our system.

And it makes me wonder, like, if you are in a leadership role, and you want to affect a certain change in the organization, and that has got to be passed down by telephone through five layers, good luck, right? I'm not even sure how to approach that. I'm at the phase where I just thought of this thought, and now I have some interesting questions, but I have no interesting answers. It's just kind of a spicy thought.

MIKE: Well, it's an interesting idea. A way to get that shared understanding is that you test it. It’s like, do you know...and that's something I've seen work as well. Like, have you worked with this API before? It's a non-judgmental question. If you haven't worked with it, that doesn't judge you. It doesn't say you're a bad person. It just means you haven't gotten to it yet. So, asking those kinds of questions, “Well, have you worked with this API before? Are you familiar with this one?”

And if you ask a few of those questions and some of the answers are blank stares or “No,” “Well, let me talk about it a little bit, and then explain how it works.” If you're not running those tests, right, then you're almost certainly not going to have the kind of shared understanding that you want, because you haven't taken the time to check whether it's there. I like that. Testing in production, not so great. Not so great.

DAVE: There was a thing that Marty Seligman did. Marty Seligman wrote Authentic Happiness and Raising the Optimistic Child, which I think should be required reading for every parent ever because there's things that you can put into a child's wetware before the age of seven that will bake in and will stay with them, and that you can dramatically affect their health care, their mental health outcomes over their life with that.

WILL: Dang. My kid’s seven. Oh, well, I could save one of them maybe.

DAVE: What’s that?

WILL: I have a seven-year-old, so maybe I can save one of them.

DAVE: Right. It's on the bubble. Yeah, speed-read it. Speed-read it.

DAVE: But he did...I wish I could remember what it was called. I want to say it was, like, a case, like, it was a case study, but, like, CASE was an acronym. It was, like, Context-Aware Semantic Evaluation or something like that, where they were taking dead people and analyzing their speeches, like presidential stump speeches and that sort of thing. Because it’s science, you have to come up with a hypothesis, make a prediction, and then test your prediction. And so, what you do is you gather statistically improbable phrases.

And so, where am I going with this [laughter]? What's the context that you have on this? When I sit down to work on a ticket with a coworker and I ask them, “How does this tie into the rest of the system?” if the answer is, “I don't know,” and they're the senior and they're the person who knows that system, then that's significant. We should maybe put a tick mark on that, right? It's like, I'm supposed to get this from you. I would expect you to have this. Who would you expect to get this from? And that's kind of an interesting idea.

I certainly, like, hanging out with Ramses, like, Ramses knows where...I don't know if Ramses knows where all of the bodies are buried, but he certainly knows where all the memorial services are held. And he and I worked on something a couple of months ago, where it was going to send an email. The system was going to send an email. And that piece got written eight years ago and never got tested. I mean, we went on production; we verified manually that it works, and then we walked away. And so, I'm like, “So how do we test this?” And he's like, “Um...” And when Ramses says, “Um,” I get real nervous. My tail goes way bushy because that means we're in the dark times in the code. And you do still find those. You do still find those.

And so, anyway, the point being, coming up with, like, identifying specific phrases, think back on this...machine learning, you can examine your past life for data. Come up with the phrases that you think were maybe telling a certain thing, and then watch for them. I don't know if this is a genius idea or not. I'm just telling you the experiment that I'm going to run next, and I'll tell you guys later how it went, so...

MIKE: Well, the principle you're suggesting here is to test it out, right?

DAVE: Yeah, test it, yeah.

MIKE: Verify it. It makes perfect sense. You verify it, and then you fill in the gaps.

DAVE: Yeah. We measure this as a cadence run rate, right? Like, somewhere in the org there's somebody whose job it is to just, you know, obsequiously, fastidiously, you know, slick up Jira like a fat daughter for a beauty contest. Sorry, that's a weird southwestern phrase. But just somebody's job who it is to just fuss with Jira all day. And this is the person who knows how to make a burnedout chart and a burnup chart and an Eigen chart and a Gantt chart and all this stuff. And these are the people that, you know, in every organization, there's somebody that can tell you these teams have this much velocity, and if we ask them for this feature, it will take them this long to get it, right? And we aggregate this over time.

And I'm actually suggesting so that you think that's, like, the wave function, right? We aggregate and sum them all together. I'm actually talking about, like, taking one interaction and putting a point on it and saying, “Okay, start the stopwatch. We're going to measure this one, and we're going to watch and see how this input affected the output. Did this one run long, or did it run short?” You'll have to do it multiple times because, you know, there's going to be 73 external circumstances to everything.

MIKE: So, I'd like to maybe, if you all are good, because we've talked a lot about how to deal with this specific problem about context, to talk about another communication failure mode. I think that we've all experienced this. So, you've got, like, five teams working on something, and the project is down to the wire. You've got about a week left, and then somebody realizes that the API between two of these systems isn't working. And everybody knew it had to be built. It was in the requirements six months ago, right?

But you reach this moment like, oh, we didn't do that. Because you all got in your silo, and you didn't talk to each other about it because you thought, oh yeah, we’ve figured this all out. We've done the communication. We're done with that. Let's go work on our stuff. And it's somewhat related to the missing context, but it's a little different, right? This is assuming that the communication is done and not iterating on it.

Big projects, as you're coming near to the end, it seems like they always have something like this, right? Like, oh, wait, we missed that. We forgot to either...well, there's always the one thing, right, the thing that doesn't work and takes way longer than everything else. And there's that, but a lot of times there's also that, oh, wait, how did we miss that? And we didn't miss it a lot of times. A lot of times you knew about it, and just somebody didn't write it down in the stories that can get done. So, have you seen this? And what do we do about it?

DAVE: I have a fun, short story about this. Years and years ago, I worked at Acclaim Entertainment. I worked on video games for them, Jeremy McGrath Supercross. And when you work on a video game 25 years ago, all you care about is 3D pixels, texels, voxels. How much graphics can we stream? And you can literally have a AAA title get nine months down the road on a 12-month dev cycle, and there's no sound effects anywhere in the game. There's no music; there's no sound, nothing.

And the friend I had at Acclaim that I most closely worked with was the sound guy, and he was a sound programmer. That's what he did all the time. And he put a module in there called Oywns, O-Y-W-N-S.cpp, right? And we would compile it, these libraries, and he would just check it into the repo, and he's like, “When you need it, let me know.” And we walked off.

And he actually left the company. And time went on, and it's like, do we need? Oh yeah, we need sound. We should go do this. And we pulled it up, and we realized, O-Y-W-N-S. Oh yeah, we need sound. He called it from the get-go that you were going to...like, I'm going to tell you in advance the thing you're going to forget. There you go. And bless his heart, he wrote the sound engine to have no dependencies so that you could just pick it up and plug it in. You only had to fight with the upstream code. You didn't have to fight with the sound. That was a genius-level, like, master development. Like, to see it, to call it, to walk away and leave working code in the future for somebody, it's amazing to me.

MIKE: And he'd learned that because he'd seen it happen [laughs].

DAVE: The other one is, like, you get to the last week, and it's not that you forgot to write the API but that you never tested the API at scale. And if it's a third-party company...I won't name names, but this has happened recently where we connected up to the remote API, and not only did it not work at scale, but it didn't work at all. Like, they had written it, and they had signed off their acceptance test plan for their unit test.

They had never talked to us. We were the customer. They had never spoken to us. And we connected to it, and it just...you know, to this day, we still see messages come through from the QA team saying, “Hey, just so you know, this guy's API is down, so you're going to be seeing a problem, you know, coming back from this.” So, I'm not going to name names, but I'm seeing nodding around the table, like, we've seen this. We've seen this.

And I like this because...like is the wrong word. There's not an obvious scapegoat that you can point to and just shriek at and say, “This is all your fault,” right? It's all our fault. This was too complicated, and we left one of our PFAs, our Potentially Fatal Assumptions, we left it unexplored until way, way, way, way late. And then, that's when you have late-night coding sessions to code around the problem.

MIKE: So, I gave, like, the overall idea. Dave, you gave a couple of specific examples. I'm guessing, Kyle and Will, you've seen similar problems in your careers, and if so, what do we do about it? Whether or not you've seen it, how do you address that problem? Because it's everywhere. I have some thoughts here, but I'm going to be quiet for a minute and let you all --

WILL: Is that a communication failure, really, or is it a planning failure? No offense. That's one of the hard parts of, like, just planning, and there’s things that are...I don't see it as, like, we could express this, or we didn't express this, or we said it, and it didn't land. Everybody was like, “Oh yeah, it’s sound.” Everybody was like, “Sound,” but everybody's focused on, oh, voxels, character design, game player, whatever, right? And everybody's just like “Sound,” right? Yeah, yeah, it’s sound.

But then, I mean, it's an organizational strategic sort of, like, planning kind of an issue. And that's just, you know, in my experience, it's just the nature of very complex plans and integration. So, it doesn't matter. Something is always last on the list, and that is, like, the further down the list you go, like, the more strategic risk, let's say, that it's not going to get looked at. And, you know, the reason it always comes at the end of the project when everything is integrating is that's when everything on the list is getting checked off. To call it a communication failure, I think, is not how I experience it, at least.

MIKE: Well, let me --

DAVE: I think I agree with you. It's both, right? It was a planning failure, but it's exacerbated by the communication failure around it. It's kind of how I see that.

MIKE: Well, let me give a take on this because there's a lot of truth in what you're saying, right, is planning. So, should we all do waterfall-style planning, where we just really lean heavily into planning, make sure we get the planning right?

DAVE: If you've built this thing five times before, yes, you should. It's a proven method.

MIKE: Good point. There is an approach that gets away from some of the upfront contract negotiation and makes it an iterative communication process, where does this work? Does this work? Does this work? I have just pulled up the Agile manifesto, and one of the principles it says, “Customer collaboration over contract negotiation.” One of the key items in there is that if you lean heavily into the plan, well, that is a really expensive way to solve the problem. And some of those things are going to be left out because it's just so hard to get right.

And it is a planning exercise, but to a degree, planning is all about getting that shared context, right? It's how are we going to be working together? And if you change that to having a repeated, iterative conversation, then you're still going to miss stuff, but the costs are lower.

WILL: Sure. I mean, everything's a waterfall at a small enough scale.

MIKE: Sure.

WILL: I don't know. I mean, still, yeah, I still see it as planning. I still see it as a planning problem more than a communication problem. I don't know. I think six of one half [inaudible 30:29] the other, right? Because what's planning other than communicating, right? Like, planning is communication of an idea.

DAVE: I think I can split this correctly. You're seeing this as...I'm not seeing...in the communication that happened, I'm not seeing a defect in that communication, and I think that's valid. I'm saying that the communication should have happened here, and it failed to happen at all, and that's the slice that I'm kind of approaching this as. Like, it just didn't happen, and you can make an argument that it wasn't anybody's job to do it. It was all of our job, but nobody...I don't know if that makes sense.

I agree with you that these, like, much of this communication that I described absolutely fell down on planning. And the oywns, my friend, Sean, he wrote oywn, and he had brought up sound at the team meetings, like, every single week for, like, six months, and everyone would just, like, you know, whatever, the sound guy is talking while they're doing it, and, to me, that's a communication failure.

But it led to, yeah, failure to plan of, like, when are we going to...there was nothing on the Gantt chart of, hey, let's make sound effects work, and you can better believe that when we released the game, the sound was not a tight fit. It wasn't Crazy Taxi where you could rock out to the game because the sound was tight and had been up since the beginning. It was just like, yeah, it's a soundtrack. We bolted it on, and you could feel it. You could definitely feel it.

KYLE: But in that scenario, the communication was attempted, right? Is that a problem in communication, or is that a problem in that we didn't have a project manager or somebody else that wasn't prioritizing it correctly?

DAVE: Good question. In my opinion, the answer is yes. I have kind of a...I don't want to get too many southwestern colloquialisms in there, but I grew up with a phrase called tough titty [chuckles]. And what that meant was suck it up. Yeah, this sucks. I can literally go back to an interaction and say, “You were the victim in this interaction, but you were also the only agent that you had control over what you would do. So, this is not your fault, but it's your responsibility. If you go back to this team meeting again in a week, you are the one who gets to present this.”

And, at some point, what do you do? It's like, I presented it to the team. I said, “This is getting urgent.” I communicated that as well as I could, but nobody wanted to pick it up. And, at some point, you just have to drop it at other people's feet and say, “It was sitting on your porch. All you had to do was open the door and pick it up.”

WILL: Yeah, I'm assuming that communication failure mode, right, if I explain, like, I need a context or a task, something, clearly, concisely, to the point in a constructive fashion and you just don't care, we are definitely in a communication failure mode, but I can only go so far [inaudible 33:23] don't care [laughs].

DAVE: Is that communication, or is that culture, or is it psychological safety? This is a beast with many symptoms, right?

MIKE: Well, I think it was Kyle who touched on this a little bit. If you don't have somebody who owns it, who is going to listen, then you have everybody caring about their own silo of stuff, and they're not going to care because they have no reason to care because they are worrying about their own responsibility. And if you say, “Well, it's everybody's responsibility,” then everybody has a tiny piece of the responsibility. If you get a crime that happens in a large city and lots of people are watching, well, everybody thinks somebody else is going to do something about it, right, so nobody does anything.

And if you don't have that designated person who's like, “Oh, I'm going to go in and do something,” you can hope people will be proactive and fill your world with heroes. Well, that's great, but it goes against human nature a lot of times. You need somebody who says, “Oh, yeah, this is my job. I am going to listen to this person, and I'm going to figure out if that fits in the plan.” And I think if you don't have the designated person, and I've seen this over and over again, if you don't have somebody who knows it is their responsibility to care about what happens, then nobody cares.

KYLE: This reminds me. I had an old manager. He was always in meetings, and he was always very...what I called silver-tongued, and I always teased him. I said, “You're quite a salesman. You're quite a salesman.” Finally, he stopped me one day, and he says, “You realize you have to be this way, right?” I was like, “Why do I have to be a salesman and an engineer? What are you even talking about?” He kind of explained it to me. And I have wondered if this is what the sound guy, you know, maybe it was above, they weren't willing to listen, or maybe it was the sound guy not selling it correctly.

Because what you have to explain to get an engineer to understand is going to be massively different than, say, a C-level or somebody in sales. You have to sell your idea completely different. You have to sell the priority of your task. And I guess maybe that's what I'm recommending is take a salesman's approach in your communication just to get your idea sold, to get your priority sold in these kinds of situations.

MIKE: Okay, so you didn't say it directly, but you just identified another failure mode of communication that's even bigger than that. If you don't speak to your audience, you've lost them. Oh, this is simplistic. If my four-year-old asked me, “Why does the sun come up in the morning?” And there's multiple ways I can answer that, right? Many of which would be ineffective. And if a professor asked me [chuckles], “Why does the sun come up in the morning?” They're probably looking for a very different answer.

And if I'm not changing my answer...and sometimes people get uncomfortable about this. They're like, no, I should just tell the truth. Well, that's a lot squishier concept than that, right? Your goal is to communicate something to somebody, and language is not very precise. So, communicating that message is not going to be the same, depending on your audience, because you have to meet them where they are. So, that's not a matter of breaking the message to filter it in some way, right? It's a matter of actually attempting to share it better, to carefully tailor the message to the audience. And if you don't do that, the communication does not happen, or at least does not happen well.

KYLE: Yeah, I feel like I do it all the time, because, for example, everybody you're speaking to, when you're explaining a problem, right? My father is a mechanic, so when I'm talking to him about anything computer-related, I relate it back to a car, you know? How does this work with a car? How does this work with the systems he's aware of? And yeah, just breaking that silo, I guess, we brought the word silo up earlier, breaking down that silo so that you are able to communicate on a commonality. Without that, I mean, right then, he's finally interested, before then, he doesn't care at all. It's just computers to him, right? But turn it into a car, and he's engaged.

DAVE: My father-in-law was a plant engineer for years and years and years. He had a full machine shop in his garage. He would make engines, like, actual engines that would burn gas or steam. He liked making steam boilers that would run. He was working with that level of precision and tolerance. And he didn't understand computers, bless his heart. He was born in the 1930s. He was a Depression child, and he worked at one company his entire life. He was the last of the boomer career, one-job career people.

And I remember trying to explain to him testing and finally saying, “You know when you went to make this cut, and you stepped back, and you made a jig so that you could calibrate the cut exactly where you needed it?” He's like, “Yeah.” “The unit test is that jig.” “Oh, okay,” and then he was on board. He's like, “Okay, it’s going to tell you this is going to be exactly where you want it, when you want it, at the time you want it.” I’m like, “You got it exactly.”

MIKE: Absolutely. And, you know, you mentioned the C-suite, Kyle. I've seen this. I've even done it. I've helped somebody write a slide, right, you know, make a PowerPoint, and put in some language that I thought was right. And I go, “Yeah, this is exactly what happened. And, you know, here's the technical reasons.” And they're like, “No, that doesn't convey it at all. If you have any technical details in your description, you're doing it wrong.” “Oh, okay [chuckles], but that's my job is to provide the technical answer, right? I'm the technical person.” “No, no, your job is to translate it to somebody who's not looking for a technical answer.”

And thinking about that differently is a critical realization if you want to fix that communication. Otherwise, you know, eyes glaze over, and communication did not happen. Like you said, you don't engage somebody. But then if you engage with something they actually do care about, it makes all of the difference.

DAVE: There was a thing --

MIKE: Go ahead --

DAVE: Something that I got taught years and years and years ago was when you're writing, like, an email to somebody where you want them to do something or you want to answer their question and it's detailed, you write out the answer. Then you read through your answer and drill it down to, like, one sentence. And back then, we called it the executive summary, right? And so, it was literally like, “Hey, can we use Hibernate to, you know, backdate the JVM with the database this way?” Executive summary, “No.” [laughs]. And then you give them, you know, three pages explaining why.

And we still do this to this day. You'll see people write this post and then at the bottom they go, TL;DR, too long, didn't read. That's perfect, except the TL;DR should have been at the beginning. Write your message, write your TL;DR, and then move it to the top so that somebody can read the TL;DR and then decide, “Oh, yeah, that is too long. I don't want to read that.”

MIKE: Some of the best blog posts I see do exactly that. They'll say TL;DR, a semicolon, and then give you the two-sentence answer. And, honestly, if they do that, I'm more likely to read it sometimes.

DAVE: Absolutely.

MIKE: Even though I've already got the answer. Because here's somebody who respects their communication.

DAVE: Yeah. I’ve wanted to --

MIKE: Go ahead.

DAVE: I've wanted to do, like, a YouTube channel where literally every video starts off with, “Hey, YouTube. I'm Dave Brady, and today I'm going to teach you how to...” you know, and in the first three seconds, I've told you what the video is going to be about. And you won't see this in the wild because the YouTube algorithm is explicitly designed to punish that. It incentivizes watch time. And what’s the easiest way to drag out the watch time? Is not give you the answer you need for as long as possible. And it's evil. It's awful.

MIKE: Which is why every recipe on the internet is a nightmare. Have you noticed this?

DAVE: Mm-hmm.

MIKE: How many pages do you have to scroll down to? The nice people at least put a link, “Take me to the recipe.”

DAVE: Yeah. I tweeted this, like, a few years back that if you have a problem with your computer, like, “I can't get Windows to resize, you know, when I'm in this mode. And when I'm in full-screen mode, I can't get this window to resize.” And you search it, and if the top-level search begins with an explanation of why you might be wanting that answer, in other words, like, “Full-screen apps are a great way to use your computer to its maximum potential, but some people...” you're not reading the answer; you're reading a content farm. And somebody is pumping up their SEO to get out in front of that, and they're doing the same thing. They're just dragging out the watch time.

MIKE: Let's not do that. The Internet is becoming a sea of AI-generated slob and declining in usefulness. We can do better in our individual communication, and we can be concise and tailor our message to our audiences.

So, we've covered three failure modes of communication. We've talked about lacking context. We've talked about everybody owns it, and so nobody does problem. And so, you know, how do you get somebody who will make sure that things don't get dropped and is keeping that iteration going? “Well, did we miss this? Did we miss something? Did we miss something?” And we've talked about not talking to your audience. Are there any other key failure modes in communication you'd like to talk through today?

KYLE: I've got one that I've been thinking about bringing up and trying to figure out when to [inaudible 43:28] in. But that is the chain, the chain of the communication. And what I mean by that, the best examples that I can think of right now is when you've got people lined up and you draw on their back. And then, the person there, the next person will draw what they think was drawn on their back, and it goes down and down and down. By the time it gets to that last person, the context is completely different. And the longer that chain is, the more context that is either changed or is missing from the original context.

And so, point being, in, like, the engineering world, that's how many chains of leadership something will go through before it actually gets to you or how many team members it will go through before it gets to you, meaning, like, you go too far, and by the time it gets to you, it's not actually what was wanted. And that's where I'm just thinking of situations where I've completed tickets only to find out, “Oh, that's not at all what they wanted,” and I had to go back and talk to the person directly and could have saved a day's worth of effort going directly to the individual rather than having it go down the chain to me.

And I've seen this problem be a concern even just one level where team members aren't allowed or are discouraged from communicating with one another. And they have to go up through their manager over to the other person's manager and back down to the other person to get the communication done, and it just sits there and runs through. You don't have that direct communication, and things just start to break down.

DAVE: Microsoft did an amazing study in the late ‘90s, early noughties, where they ran all the project data longitudinally for, like, Windows 3.1 all the way up through Windows 2000, which was excellent at the time. And they were basically, “What causes bugs? What causes bugs to take forever to fix?” And they found that it wasn't team size or project complexity. It was the number of layers of management you have to go up and back down to get into the right leg of the trousers to get the solution that you need, and it's exponential. So, if you have to go up one level, it's twice as hard. But if you have to go up two levels, it's four times as hard. If you go up three, it's nine times as hard, and it gets insane.

And going back to contract negotiation versus collaborating with customers, when you're stuck in that hierarchy, what you have to do is say, “Draw it again,” and then somebody comes and draws on your back again. You're going to argue over how much resolution of data I need on my back in order to fit, right? You're negotiating a contract. Just turn around and talk to the person, right, which is against the rules of the game.

But the point of the game is to show you that the game is broken, right? It's like, this is literally an exercise in doing it badly. So, when that happens, attack the hierarchy. Don't go after better contracts. Don't try to make it so, “Well, if we could just get it so that the DBA team and the engineering team and the ops team, if they could just pass everything back together as tickets, this would all be solved.” Nope. Nope.

MIKE: [laughs] Oh man. I've seen that one as well. “Oh, yeah, just make a ticket system then we won't have to talk to each other, right? It's all just organized.” And, of course, the opposite happens. It's a nightmare. But you said the solution is embedded in the description of the problem. And I've seen this, and I've seen it a lot from good, well-run organizations is the first thing you do is when you identify the teams that are dealing with this, you get people on the ground, and you connect them together, and then you step away.

If somebody is going to claim ownership of that communication and say, “No, everything's got to go through me,” then they are destroying their organization because you are preventing communication. And people who will instead say, “My job is to facilitate the right conversations. So, my job is to make conversation happen. That doesn't mean it has to come through me. In fact, I'm probably the wrong way for that to happen. I'm going to find the people who need to talk and get them talking.” And that kind of leader will make great changes in their organization, make things move forward. Again, I've seen this happen.

So, I've seen that kind of leader fairly often, and I deeply appreciate when I do because everybody's lives are so much better. And the best negotiations I've seen are exactly that. You might have some leaders who get in like, “Oh, yeah, we need to do this. Let's get the engineers and put them together and have them figure it out.” And when you don't see that happen, you're like, “Okay, this is going to take a few months.”

DAVE: We've talked about this on the podcast in the past that one of the most amazing things you can do if you're on a siloed team is to violate the borders of the silo and just go talk to somebody. We would do team swaps, and now you know somebody over there that you can just poke.

I'm just thinking about this, that we have call processors that talk to the customers, and they have to use our website on a side of the website that I hadn't seen anybody use because I was always facing another set of customers, and all of a sudden, I'm facing these people as they are my customer.

So, it's all remote. I jumped in on a remote meeting with one of the call processors to just shadow them on some phone calls. And if I had been in office, I would have picked up my laptop and gone and sat next to them, like, physically next to them because I want to actually create rapport. I want them to know what I look like and what my name is and that I'm a nice guy so they know they can come talk to me.

And just sitting with them, I immediately realized, “Oh my gosh, we are making you type with thumbtacks on your keyboard. It does not have to hurt this much.” I added, like, a dot sort. There was a thing, four or five merchants in it, right, and it wasn't sorted. And that's fine if you need to read through five things, but these poor processors were seeing 500 stores unsorted, and they had to find them by name. And they were just...and when you're a call processor, you're making minimum wage or barely above, and when you're in that job, you don't complain, right? You just put your head down, and you just do what it is.

I'm watching this, and I'm like, “Oh, my gosh, you're working in a Dickens novel. Who did this to you?” And I'm like, “I did this to you. I'll be right back,” right? And so, like, the next day, I, like, poked him, and I said, “Hey, just go to Jira,” and he went and he looked, and there was a ticket to fix the thing, to just sort the merchants. And that's a one-line fix, right? It's literally dot sort. It's a seven-character fix.

And I have friends on the processing team now because I took the one thing that hurt them the most in their eyeballs, and my point is it was collaboration. It was crossing through the DMZ and saying, “Show me what you're working on, and show me how you use this product because, in theory, we built it for you. Let's collaborate.”

KYLE: See, and without that direct communication, how slow would that have been? Because that's processing up to some project manager. Then it would be prioritized down to you, and you wouldn't care. You'd be like, “Sure, yeah, this ticket, throw it back over,” you know? And you would have never heard any update. But now you get that personal interaction, and you've got friends over there that are just like, “Thank you, Dave. Like, this is great.”

DAVE: The truest proof of that is the fact that this bug had been in their system, and with this particular...you guys know we have one merchant that's, like, an aggregate. They've got thousands of merchants right under them. It was that merchant, that super merchant, right? And we never checked it on the engineering side, and they had been dealing with this for years.

KYLE: Wow.

DAVE: And no ticket had been created. Because if you're processing, you don't get to complain about the software. You don't get to have input on what would make it easier. And just having an engineer sit down and go, “Oh my gosh, we need to fix this for you,” it was world-changing, right? Literally, there was somebody going, “Let me make this not hurt so much.”

And we talked about this a few minutes ago. A gift card is so much better than just more salary, and a nice bonus is so much better than, you know...I mean, to be fair, I like getting cash as a bonus. I love that. It's fantastic. But those aren't the things that I remember, right?

You'll find anybody on WordPerfect the second year that they were in business, and when the company took all of them to Hawaii for two weeks as the Christmas bonus, right? They all remember that because they were wildly profitable and spending like stupid because it was the middle of the ‘90s. You get the idea.

MIKE: Well, I think that is a great place to tie things up today. We could probably go and find a variety of --

DAVE: Oh, I've got eight more topics we could go into on this. There's different ways that communication can falter down [inaudible 52:11]. This is an evergreen topic. We could easily circle back to this [crosstalk 52:16].

MIKE: Absolutely. But we hit some big ones. And importantly, these all have relatively straightforward solutions. You just have to do them. You just have to use the solution, right? Test the context. Make sure that you have it. Cut through the hierarchy and go meet with somebody directly. Speak to your audience, right? Think about who you're talking to. Or designate somebody. Designate the person when you have a large group that needs to communicate who is going to facilitate that communication.

Let's work on that and make our communication better because, in the end, it's most of what we do is trying to figure out how to do things together as humans. And with that, until next time on the Acima Development Podcast.