S2E20 – Ascending the Tower of Techno-Babel

Show Notes

In both popular literature and media, we’ve all seen the clichéd portrayal of the brilliant engineer spouting indecipherable jargon to explain a situation … and, inevitably, the main character uses a simple analogy to demystify the message. In the real world, however, things rarely mirror those stereotypes, but miscommunication or poor communication of technical messages is still one of the biggest and often hidden problems for engineering leaders and organizations.

In this episode, hosts Andy and Mon-Chaio tackle the challenge of technical communication in the workplace. They offer practical advice for engineering leaders on how to effectively convey complex technical messages to less-technical bosses and peers. The focus is not just on using financial terms like ROI or KPIs, but on truly understanding your audience and using storytelling to make your message clear and impactful. Andy and Mon-Chaio also discuss the importance of empathy and the power of narrative to bridge the gap between technical and non-technical worlds.

References

•  Language of Business
• Goals, obstacles, and strategies in risk communication: A problem‐solving approach to improving communication about risks
• Communicating and Disseminating Research Findings
• The 7 Habits of Highly Effective People
• SPIN Selling
•  Start with Why

Transcript

Mon-Chaio: Andy and I are here once again for another episode of The TTL Podcast. The topic we wanted to present today came, I believe, Andy, from an article, that I found through my email box somewhere or somehow called The Language of Business, right? I think that’s what spawned it?

Andy: I think that’s what started it, yeah.

Mon-Chaio: We’ll talk through the article, but jumping forward, the topic that we want to talk about today is communicating technical information to non technical audiences. And what do technical leaders have to learn about how to communicate to non technical audiences. Does that seem right, Andy?

Andy: Exactly, that sounds like what I was planning on talking about today. I’ve prepared for the right thing, so I am happy to go ahead with that.

Mon-Chaio: I think starting with the article, the article again was called The Language of Business. And the beginning of the article I thought was quite interesting. The author mentions that he gives a lot of advice to young technologists and he tells them, “I’ve never seen a CTO get fired for not being technical enough, but I’ve seen a lot get fired because they can’t speak to the business.” His proposition there, I think, is that they’re too technical perhaps.

And to summarize what he’s saying, he wants to convey that the understanding of the language of finance is not just another skill to add to your repertoire, but it is a key language for business. And the language of finance is the language that business revolves around. And so as a technical leader, you need to get good at translating your technical message, into the language of finance.

Now, he mentions some things which I think I agree with: putting your messages in terms of ROI, I think that’s pretty important, although I do think that that often is over indexed for, KPIs and ROI, in terms of messaging, and we’ll talk about why as we get into this episode and harken back to our storytelling episode. But then he also talks about technical people really needing to understand balance sheets and cash flow and being able to talk in terms of that, and I think that’s less important in my mind.

And I think he is a little bit biased because he believes in that and he went back and got an MBA in order to be able to do that. But that did spawn the interesting question, which is, we’ve all seen technical people struggle to communicate technical messages to non-technical audiences. And generally, as you move up the leadership chain, you’re communicating with more and more non-technical people.

And so, what are some tactics that we can present around how to better do that communication?

Andy: Right! So, if I just take the article, should we just represent everything in spreadsheets and summations and cash flow projections? Would that address all of the concerns of talking to non-technical people, Mon-Chaio?

Mon-Chaio: Oh, absolutely, right? Because if I have, let’s say technical debt, I can just say, well, technical debt, the problem there is a balance sheet problem where if we have technical debt, it means that our balance sheet is going to be too low for this quarter … no, I think the answer obviously is no.

I don’t think, I don’t think that gives us any great tactics on how to move forward here.

Andy: Yeah, I agree. I think the language of finance is important and it’s something that you’ll need to be able to talk about because, well, you’re in a business. You’re probably running a technical organization to produce a software product that has a particular mode of being sold, and that has implications for whether or not they can pay your salary, can pay your team’s salary, and what kind of structure you can have for that team.

So it’s important to understand it, it’s important to be able to talk about it, but I don’t think it really gets us to that final thing that we’re interested in, which is how can you have that better conversation about a technical topic with someone who’s non-technical?

Mon-Chaio: I agree. So if not that article, then where should we start? Is there any research or is there any guidance that helps us talk about what do we do with technical information and how do we communicate this to non-technical people?

Andy: Yeah, and so, I did some searching, and I was looking for communication studies, things along those lines. And there I did find a paper. I wouldn’t call it research. It was more of like an experience proposal and a bit of a framework to propose about what you could do. And I thought it was interesting.

So they were talking about how do you communicate risk effectively? Now, risk is also a technical topic! It’s a very technical topic that they’re going to have to communicate to fairly non-technical people and get them to understand, get them to be able to take action based on those risk assessments and judgments about changes that need to happen. So they had a framework. I will just go over the five top level goals that they said you need to go through in communicating.

The first one is to create awareness of the risk information, which means making sure that you can actually talk to the people that need to hear it, keeping your language less jargony, and creating an awareness of what this all might mean. So you just have to create that a bit of awareness that something is going on here. And then you need to help people understand or deepen their understanding of risk itself. So you almost have to train them a little bit about what does risk mean. A thing that they said there was you need both examples and non-examples. Things that are not risk, or not the kind of risk that you’re talking about, and things that are the kind of risk you’re talking about.

Then, and I think this is one of the points where as technical folks we sometimes really fall down, is you need to get agreement. You need to get agreement that those things actually exist, that what these risks are that they’re talking about are something that should be cared about. Because if you continue on without getting that agreement, they say, you could just lose credibility. And then – this is about risks like flooding – so then you have to motivate action in emergencies. You need to get people to viscerally feel. that risk and feel that there’s something that they should be doing when it happens. And then the last one is motivating action to volunteer or overcome habit. Once again, we’re talking about risk. So, this one is give people specific things to do. If you give them something general to do, they won’t do it or they won’t know what to do. So there was an example in the paper of don’t tell people to get enough water. They said a much more effective message is tell people “fill your bathtub with water.”

And so out of that whole framework, they gave a little bit of a structure of how can you communicate this very technical risk idea to someone who’s not steeped in risk and risk analysis and deciding on actions to take. And it’s basically, it’s help them through the process of understanding this.

So that was the first thing I found. What do you think about that Mon-Chaio?

Mon-Chaio: I think that that makes a lot of sense in my mind. I think that there are some good parts, especially, the creating awareness of risk information, that idea of placing information in familiar places, speaking the right language, aligning everybody on what you’re talking about. That, I think, goes into a really important part of communication that often people forget, which is the awareness of who you’re speaking with.

Andy: Yes. Yeah.

Mon-Chaio: And even if you’re communicating the same information to people at perhaps the same level, those people have different awarenesses and you have to look at them and understand them and say, okay, what do they know? What do they not know? And that informs how you communicate and the message that you communicate.

So I really like that creating awareness of risk information and grounding it in something that people understand. I also agree that that gaining agreement part is something that we often forget to do. As technical people, we often think that the data speaks for itself.

And when we did our storytelling episode, we talked about why that might not be the case. And in fact, one piece of research that I found, they had a really great statement. They say that “communication is defined as the interaction between the sender and the receiver. And it’s effective when the message elicits a desired response by the receiver.”

And they posit that if that response is not achieved, then your communication has actually largely failed. It doesn’t matter if you delivered all the information accurately. It doesn’t matter if you’ve given them all the charts. And it doesn’t matter if you’ve told them what’s gonna happen. If you had a goal on what you wanted to achieve, and then that goal doesn’t happen. Then that communication, in this case, was wasted.

And so, I think that in technical people, we often forget about that. Because we forget about that eliciting agreement part. Where we say, hey, here’s the data. Okay, well they heard the data.

Andy: Yeah. if I just keep telling the teams that they need to do TDD and stop branching trunk-based development, I’ve presented to them exactly what I want, but they’re not doing it. So you’re telling me that it was a failure on my part, not on their part?

Mon-Chaio: Yes, I am telling you that that is a failure on your part, not their part. Your communication has failed.

Andy: Oh, damn it.

Mon-Chaio: So I do like that. I do like goal number one, that creating awareness, goal number three, the gaining agreement part, and then motivating action in emergencies. Motivating action to volunteer. The thing you said about being specific about filling up your bathtub with water. Or saying every family should buy two bottles of water instead of some vague thing about having enough water. That all makes sense to me.

Interestingly, also, I found an article that was talking about how scientists should communicate information and how different communication habits are required when you’re doing journals versus when you’re trying to communicate to the general public.

Andy: Oh, absolutely. Yes, yes. A well known problem in science communication. Absolutely.

Mon-Chaio: And there’s a lot of good stuff in this paper, including how you should build your charts and how you should build your slides and notes, things like that. They have great examples, I feel like, of charts that work, and why they work, and how many colors you should use, that sort of thing, which if you’re interested, look into the linked article.

But what I wanted to pull out of it was something that they talk about with regard to newspaper articles. And they say in contrast to the way papers are written, things like introduce your hypothesis, your problem statement, describe how the research was conducted, what materials, right? And then you talk about the results, and then you have a conclusion, and then you talk about your anti-conclusions or whatever. They say a newspaper article includes the most notable findings or conclusions in the lead paragraph.

Andy: Yep.

Mon-Chaio: So they start off with, this is what happened! And then the remainder of the article contains not only supporting facts, but also quotes and anecdotes that support that. And one of their tactics was create brief, memorable quotes that explain what’s noteworthy about the research, and then include an anecdote that may help reporters and readers relate to the finding and discovery, kind of on their own terms.

Connecting it back into the language that they understand and the lives that they lead. So I think that that was a great tactic that they presented.

Andy: And that brings up a really important point that I think a lot of technical folks, we kind of forget sometimes, which is, don’t bury the lede. The lede is that start of the journalism article. It is the thing that, if you don’t go any further, that is what the journalist wanted you to walk away with. It could be the headline, it could be the first sentence, but it’s going to be right up at the top. Burying the lede is putting it anywhere else.

And if you put it anywhere else, someone reads an article about the latest React library contains an amazing security vulnerability that lets anyone steal the passwords of people using any site written in React because of something. Now, burying the lede would be saying, “New announcement about React!” And then you start talking about the newest releases that they have and some of the various things that they’ve been doing to develop those new releases and support backwards compatibility. And then on the fourth paragraph, then you say, unfortunately, introduced in all of these new changes to the underlying framework, there is a security vulnerability, a flaw that allows an attacker to record all users passwords. That is burying the lede.

It feels like this logical construction where you say, I first need to give the background and then I need to build up why that is important. Then I need to tell you why that’s important. And that’s wrong. That’s the wrong way around. You need to tell me first, why is it important? And then go into what makes that important.

Mon-Chaio: And we struggled to do that in our own podcast. I think in … we tend to introduce our own podcast in the same way. Well, here’s how we came about, here’s why we got interested in it, here are the things that led us to be interested.

And it’s two minutes and I’m sure listeners are like, okay, but what …

Andy: … are you talking about?

Mon-Chaio: … are you going to be talking about? Do I even want to listen to this episode? I feel like we’ve shortened it, but we still don’t do a great job of saying, look, this is exactly what we’re talking about. Even just today I was like, hey, it was this article that spawned it, ah, right. Uh, so, uh, yeah, everybody can get better at it, but yes, burying the lede I think is an important thing to recall and to not do.

Andy: Yes, and it brings us on to that this is all storytelling. So communicating technical topics to non-technical people, it’s a form of storytelling. So just like we talked about in our episode on storytelling, you need to, with those non-technical people, produce an ethos, pathos, and a logos going in the order that you probably want to present it. Now, in a lot of cases, if it’s with colleagues, you probably don’t need to go too much into the ethos, but you might want to get into the pathos fairly early on. You want to create a bit more of that connection, a bit more of that emotional reaction, so that that lead is there, that people can start thinking about it. And then you can get into the logos, but now here’s the thing. It has to remain at that connectable level.

So if I start describing that Debian had patched OpenSSL and broke the random number generator. And so it turned out that OpenSSL random numbers were not actually fully random. Which meant that the encryption keys produced through it weren’t secure, there was a pattern to them. Now, I could describe that either by saying, oh, that this library named OpenSSL had this file patched, and it was a diff of this size, and it was put in at this date, and all of that stuff. But if I’m talking to my CEO, trying to justify why we can’t work on that next feature, and instead we are working on patching all of our systems, that’s not where I’d start. I would start by saying, all of our data could be stolen and we wouldn’t know. We need to get that fixed right now. It came about through no fault of our own. It happened this way, and we learned about it through this channel. That’s why we’re doing this. And we’re also learning the lesson that it’s much harder to patch this, change this software than we had expected. And so we’re updating our processes at the same time.

So you want to stay more at that feelings level a bit longer to help them to understand it and not get down deep into these details.

Mon-Chaio: Going back to the article that spawned this whole conversation, I think a big challenge there is the author was proposing using different language in order to communicate the information. He was really talking about the logos part, changing the way that you present the logic of your argument with different language. But I really do think that the important part is more that pathos part. I think that’s what technical people tend to forget. They tend to be really good at the logos part. And I’ve done this as recently as a few months ago. Where you’re presenting information and people aren’t getting it and you think, oh, well, maybe I should present it in a different way. And the ways in which I think about changing my presentation is always around that logos.

Andy: Mmm.

Mon-Chaio: It’s the, oh, well, maybe I presented too many numbers. Let me present fewer numbers or, oh, I was talking about this particular part of the problem. That didn’t resonate with them. And so let me talk about this particular part of the problem with these different numbers.

But often really is that pathos part. And I liked that you gave examples. So I was wondering if maybe what we should do for the remainder of this episode is talk about two common technical topics that technical people have to talk with non-technical people about.

Andy: Mmm, OK.

Mon-Chaio: See if we can give some examples and guidance of how to do that. The one I was thinking of is technical debt. So, you are an engineering leader and you have to go to your CEO and explain why you have to take three weeks or four weeks to eliminate some technical debt. Now, maybe that’s never the right thing to do, but let’s put that aside for the moment. I know that a lot of people do that, so maybe that’s one. How do you feel about that, Andy? Or do you feel like there’s a different example that we should go through?

Andy: No, I think that’s a good example. The technical dead example is, as you say, very common. I would generally not advise people to have that conversation, but if you’re going to have that conversation, let’s have it a little bit better. So, where would you start with that conversation? I think the place you would start is empathy.

So, I’m gonna go into the Seven Habits of Highly Effective People for a second, and give a place that we should really start on this, because if you’re the CTO, VP of Engineering, you go to the CEO or Head of Sales or whoever is the stakeholder in this case. And you just say, hey, I’m stopping development for three weeks because we need to refactor our code base. The Whatsit module we just haven’t been keeping it up to date. And that’s now dragging us down and we just can’t work with it anymore. And so, to get the Postgres database to communicate with it over SSL, which the security guys for ISO 27001 said we have to do, and if we don’t do that we’re going to lose our PCI DSS. We need to do this. And then while we’re doing that, a bit of Route 53 shenanigans need to get changed around so that they can find each other. If you go to them saying that – I admit that was just a mishmash of things – you’ve got no empathy.

So Seven Habits of Highly Effective People, habit five is first seek to understand. First you have to seek to understand their emotional reaction to your basic message. And what’s your basic message? I need to stop feature development work for three weeks. Everything’s going to be delayed by at least three weeks. To do that, the first thing you need to do is actually rather than talking to them, giving them more information, you need to ask them questions. You need to start understanding what that means to them. And once you can do that, a quote from this is ” you’ve got to empathize with his head. You’ve got to get into his frame of mind. You’ve got to make your point simply and visually and describe the alternative he is in favor of better than he can himself. And that will take some homework. And then when you can present your own ideas in the context of a deep understanding of other people’s paradigms and concerns, you significantly increase the credibility of your ideas.”

So the very first thing I need to do in trying to communicate this is actually not try to communicate it, but to understand what reaction they are having. Does that work for you, Mon-Chaio? That first seek to understand?

Mon-Chaio: I think so, and I think I do want to talk about this concept of collaboratively creating stories, and that might fit in here as well. But I think also, seeking to understand doesn’t just mean asking questions. To your point, there is homework to be done, and there’s homework that can be done without asking questions. This gets back to understand your audience, that person. And so without asking, you can probably understand your Head of Sales or your CEO. What are they going to be concerned about?

And also, what is the language that they speak? They probably don’t speak story points. Or even if they do, it’s at the beginner level of story points, right? They don’t understand the nuance of story points. And so the language that they’re probably speaking is features. When are these features gonna get out? When are other features gonna get out?

And this is what the original article was positing that, well, they speak ROI, and they speak finance language, and everyone in the business speaks finance language. So I think that’s something that can ground us, and when we don’t know what a language is, we can say, okay, we can default to finance language perhaps. But I do think that there’s a lot more powerful and emotionally connective language than that. So, if you’re saying, look, this technical debt has reduced our velocity from 15 points to 10 points. Yeah, that’s technically true, and yes, they probably do understand story points.

But it’s not as valuable as speaking a language that they speak, which is to say something along the lines of, well, features have been coming out 30 percent slower. These past five features, if they came out 30 percent faster, we would have released this then, and this then, and this then.

Andy: And, also, the things that they’re feeling. Very likely also, if we’re talking about technical debt, there’s bugs showing up, there’s things that the users are complaining about. And so, to be the CTO, VP of Engineering, I should be aware of what our users are experiencing just as much as our sales or customer support or whatever. And I can try to put myself into their shoes and talk to them about that emotional impact on them that that has. That, oh yeah, you know, our users keep hitting these problems and then they complain to us and we feel stuck because there’s nothing that we can say that will help them. And I want to tell you why that’s happening and what I’m planning to do about it.

Mon-Chaio: Absolutely. And I like that, right? You’re grounding yourself in their language. And you’re telling them, hey, I empathize with you, something that you are also feeling. And I’m here to help you. I’m not here to not help you, right? Not helping you is you want to ship a feature? I’m not going to let you ship it for three weeks. Helping you is your users have a big problem. You have giant complaints here. I’m here to help you. So, I really like that part of it.

I also think a way of empathizing, and I alluded to this previously, is this concept of collaboratively creating stories, and we talked about this a little bit in our storytelling episode. So, one way you can collaboratively create stories is to have a conversation with your stakeholder. Don’t go in there telling them, well, we have technical debt, and it’s going to take us three weeks. Again, be open to learning and empathetic. And go there and say something to the point of, hey, have you noticed we’re shipping fewer features? Or, I’ve heard through the grapevine that you feel like we’re slower than we used to be. Let’s talk about that. What have you noticed that has changed from us? Other than being slower, have you noticed anything else that’s changed that might cause us to be slower?

And then you can bring that back into the conversation of saying, you know, one thing that I’ve noticed from being in the technical details is there’s this thing which is getting more and more complex. And the last three features that you wanted us to write, I myself have felt like it took like 20 percent longer or something.

Andy: I think that’s very good. And a point that I want to make about it is that when you ask them that question, have you noticed, and why do you think it might be happening? Listen to their answer. That’s the first seek to understand . So, listen to their answer and be open to it being different from yours.

Don’t just plow ahead with, yeah, yeah, yeah, yeah, yeah. So yeah, you noticed things kept going back to be redeveloped. Yeah, yeah. Don’t worry about that. That’s a separate problem. No, listen to that problem and listen to what they think might be going on and work with them on understanding it and incorporating it into what you’re thinking, helping them incorporate what you’re thinking as well. But that’s the act of listening. That’s the empathy. That’s the seeking to understand.

Mon-Chaio: And when you’re seeking to understand, again, lead with curiosity I think is so important. Something that I was actually just talking with my daughter about this weekend when she was trying to solve a problem with her and her teacher. It’s so important, we forget about it so often. And so, yeah, don’t just ask the question being like, I’m trying to collaboratively create a story like Andy and Mon-Chaio told me to. Yeah. I’m in the asking questions part, but I’m soon going to be going into the presenting information part, right? You really want to listen.

Because the best thing that can happen is that they can say something where it triggers in you, oh, I hadn’t thought about that. Huh. I wonder if that’s also contributing to it. Right? You came in wanting to talk about technical debt and you’re leaving, hopefully having talked about technical debt, but maybe you took away from it, yeah, these requirement documents are actually terrible. And this is the section that they’ve noticed that I’ve never noticed. That’s actually also slowing us down, right?

But even if they are coming from a place, and you are truly listening, and what you’re hearing is not what you think is the problem. And because, look, they don’t have all the context that you do. So perhaps they’re telling you, well, I see your engineers playing ping pong all the time, uh, you know, that seems to be why. And I feel like they play more ping pong now, whatever the case may be, that may not be exactly a valid reason why. And so they’re not creating that story with you in that way with the logos part of it, but what they tell you there helps you create that pathos part. Okay, well, they’re feeling like we’re slow because they’re feeling like we’re not working as hard. What can I do with that? Is there some way that I weave that into my story? Maybe it’s, well they’re very frustrated because everything takes a lot longer than it needs to. And that’s why they have to vent off steam. Or, what is it that we can connect that back to? And so I think, to your point Andy, it’s really important to do that active listening.

Um, I do want to point out one way to continue to listen. We talked about this episodes and episodes ago, is the AWE question: And What Else? So, whenever you’re ready to respond, instead of responding, respond with that. Say, “and what else?” There is a tactic here where you ask “and what else” until they get annoyed at you asking “and what else” and they’re like “nothing else! There is absolutely nothing.” And then you ask “and what else” and they’re like, “I just told you nothing!” So there is a tactic to get there saying that you always have to get there. But think about using that “and what else” in order to elicit as much information as possible.

Andy: And then back to that thing from Seven Habits, now that you have all of that, make sure that you can now explain the impact that the situation is having on them better than they could. That will really get that communication clear that you both are understanding it. And now, the next step, I’m following, I actually didn’t say this, the other model that I’m following in my head is called SPIN. Situation, Problem, Impact, and Create Need. It’s actually a selling tactic, but once you understand the situation, you understand the problem that people are encountering, which is kind of what we’ve talked through about this tech debt.

Like, here’s the situation. How do you see the situation? What’s the problem you’re seeing? These are the problems I’m seeing. What is the impact that’s having? Oh, the impact that’s having is that we have been trying to put together the marketing materials for this upcoming conference based on those features coming out. But since you guys have been so slow on that, and they keep changing, we don’t know what to put together. So we’ve just been stuck doing nothing for three weeks. So you might have just identified a completely different problem than you initially went in thinking that you were going to tell them about this bad news about the tech debt. But then the next thing is a need to resolve it.

And sometimes that need is very clear. Sometimes it takes a bit of working out. What is the need to resolve it? And then once you’ve got that need, and you’ve understood the problem and all of that, the action you need to take is now something mutually agreed upon. Because it’s clear to everyone involved why you need to do something, what this is going to do for them, and how their life might be better, and how your life might be better out of it.

Mon-Chaio: I really like you pivoting back to the Seven Habits of Highly Effective People. Especially that part about explaining it better than they could explain it themselves. Which is something that I tell people actually about strategy. And I say, you know, your strategy is not done when you’ve written a strategy document. Your strategy is done when your partner teams are espousing the strategy for you. Because they see your strategy as so much more important for them than you see for yourself, and they’re pushing it for you, so I really like that part. On the technical debt side of things, there is also this case, often, where maybe your stakeholder doesn’t feel the pain.

Andy: Yeah.

Mon-Chaio: And that is why the technical debt exists in the first place, is because you’ve never let them feel the pain, right? They’ve said, hey, I want this out. You’re like, I’m going to create as much debt as possible. Now again, setting aside for a moment, whether that’s a good practice or not, to let them not share in the pain …

Andy: I think we’re somewhat alluding to why we don’t think that the technical debt conversation, although it happens a lot, is the conversation that should actually be happening.

Mon-Chaio: And I think if it does happen, and if they’re not feeling the pain, there is still a way to collaboratively create this story. It could be something around this next feature that you wanted, right? Which you wanted in a month. Wouldn’t it be great if we could ship it in three weeks? And wouldn’t it be great if we could ship these past features faster, ’cause you know, we deliver them every month, but if we had all delivered them in three weeks, you know, where would we be? And wouldn’t that be a great state? And let’s problem solve around what’s preventing us from reaching that state? And perhaps one of the things that you will bring to the conversation is, we could reach that state from a technical perspective, but there’s this thing, there’s this big rock which is blocking our way, which we’ve never had a chance to chip down, and so we’ve built roads around it, right?

And this gets back into the imagery part. Can you speak a language that they understand? We’ve just been taking detours around it, and so there’s this big rock blocking a well-paved road. And instead of taking time to chip it away, we’ve built like these little dirt roads. So, yeah, I mean, it’s faster than chipping away the rock, but these dirt roads are slow travel, right? And so if we spent time chipping away this rock, we’d have a nice wide road to travel. And you would have gotten your features here in three weeks. And wouldn’t that be great? What could we do with that? And so, there are other ways of having that conversation too, even if your stakeholder’s not feeling that pain.

Andy: And you actually now just got to the conversation that I would actually recommend people have. Technical debt is a very technical concept. It was designed to talk to people about it, but didn’t really help it too well. If we try to talk to Sales, CTOs, Customer Success about technical debt, what we’re talking about is a cause of issues, but not the issue. So the issue is, as you were just talking about, this feature is delayed. We’re going to be taking a new approach that unfortunately will delay it a little bit longer. But in that approach, we want to get to this better world. That’s actually the conversation. You want to be talking about what’s the impact and what’s the advantage and what’s the things that the company or those departments get out of this.

The technical stuff is the details of why that happens. But the why, even though Simon Sinek says ” start with why”, not this “why”. That’s not the “why” you want to start with. That’s more of a “how”. So you start with the “why”. Why am I talking to you? I’m talking to you because I want to speed things up. You want to talk to them about the things that matter in their world.

Mon-Chaio: Agreed. Why don’t we try to summarize a little bit , and we can sort of trade off here. I think the first one that I will say is truly try to understand your audience. It might be the same message, but you should not be delivering it in the same way. And one of the ways to help understand your audience is to really empathize with them, ground them in their place, speak their language, think about their needs and wants.

Andy: I agree. You want to talk in their language. You want to talk about the problems they’re encountering. I think also, think about it in terms of the ethos, pathos, logos. Spend a lot of time on the pathos, and then the logos starts giving more of that reason of how this might change things when you’re having this kind of conversation. You should work on collaboratively creating those stories as well. I think we touched on that a little bit, which is once you understand, incorporating that into the communication you’re having, which helps people believe that you actually understand and helps you check that you understand.

But then it incorporates into what it is that you’re saying and you can let that alter the outcome.

Mon-Chaio: And from there, remember that anecdotes, stories, narratives really help create that pathos. And so build those types of things. It’s not all just numbers and charts.

Andy: Absolutely, because numbers and charts just distract. And you don’t want to distract from your message. You want to keep it simple in their language. I suppose, though, if their language is numbers and charts, puts some in.

But I would be careful about it. Numbers and charts can be deceptive as well. Even if everyone wants to see ROI numbers, might be better to create a conversation around why they’re not there instead.

Mon-Chaio: And that takes us full circle to the part where, while ROI and KPIs are important, and being able to speak the language of finance is often important, it is really the base level of the conversation and having that conversation around technical topics to non-technical people requires much much much more than that

Now If you yourself are having challenges having technical conversations, would like our help, we would love to help you. In fact this technical debt example, while I think was a pretty meaty example, was kind of the freebie, Andy, because we didn’t even get to the difficult part, which is if your stakeholder feels no pain and doesn’t feel like things are slow. And what you want to communicate is my engineers have low morale because of technical right?

That’s a much more difficult conversation. We would love to have it with you if you would like to have it with us. So please reach out to Andy and I, we would like to help you as an individual or you as an organization. You can reach us at hosts@thettlpodcast.com. With the same email address, you can also give us any feedback you have on the episodes, whether you like it, dislike it, agree, disagree, or give us ideas for episodes that you would like to hear about in the future. We love hearing audience comments and we want to make sure that what we present is of the most use to all of our listeners.

We also have a small ask of you. Please like, subscribe, rate us on your favorite podcatching platforms. That really helps us out. And of course, one thing we haven’t asked, recommend us to your friends. Do you know an engineering leader that would really benefit from content like this? Maybe it’s your peer. That would be easy. Maybe it’s your boss, probably a lot more difficult, but if you do know anyone, we would love recommendations, and that would really help us out.

Until next time, folks, be kind and stay curious!