How do you communicate a technical solution to a non-technical team member? And specifically, when that non-technical team member needs to be involved in making a decision that has technical implications? That's the question that we're talking about on today's episode. My name is Jonathan Cutrell. We're listening to Developer Tea and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. And I got this question actually from a listener named Saul Cruz, Saul contacted me on LinkedIn. Feel free to connect with me on LinkedIn if you want to. I'm more active on Twitter. You can find me at Jake Atrell and you can also find me at Developer Tea. This question is such a good question because there's so many important topics that are wrapped up into this question. So I want to dive into the question. But first I want to kind of take a step back and talk about how this happens. Why do we end up in these situations to begin with? When I first started as an engineer, I thought that my job was to create good code. Code that other engineers would find inspiring or creative. Things that were novel and solutions to hard technical problems. This is what I thought my job was. But the truth was my job went far beyond this very simplistic version. It's easy to attach to those things. These are the kinds of things that a lot of engineers believe. They believe that a lot of their job has to do with the quality of their code or the vast majority of their job has to do with whether or not they're solving hard technical problems with novel solutions. And that's not wrong. It's not wrong that that could be a part of your job. But your actual job, and when we say job on the show, on this episode at least, we're talking about what your employer is willing to pay you for. What they are willing to give you money for. Your actual job is to provide value to that employer. Nothing more and nothing less. And we can get into the nuance discussion of what exactly is value. And it's useful to at least talk about one particular aspect. And that is tangible versus intangible value. Tangible value is directly tied to some kind of obvious resource that we all share. Let's say that you're developing a feature that is a specific contingency for winning a particular customer. This is tangible value and it's pretty clear that your contributions are tied almost directly to that value becoming a reality for your company. But then there's other intangible value. Let's say that your company is interested in having good developer relations. Well going back to that previous misconception of what my job was when I started as an engineer, something really well written code that would impress those other engineers might be used as a recruiting tool. And it may not be the only specific thing that causes somebody to join the company. It may not be the only thing that gives you kind of a thumbs up as a developer relations expert. But it provides intangible value that snowballs and eventually connects to tangible value. So I want to go back to the question that was asked by Saul where he asks how we can as developers communicate to non-technical people who we have to make decisions with. And first I'm going to tell you how not to do it. Then we'll take a quick sponsor break and then I'll come back and give you some tips on how to do it better. So here's the first rule on how not to communicate to a non-technical stakeholder. Don't treat them as if they want to learn the technical details. This is very difficult for me as an engineer and as someone who has kind of the mindset of a teacher because in my mind everything that I'm interested in other people may also be interested in. Everything I know about a subject that helps me make clear decisions, I assume other people who want to make decisions about the same subject may also want that same knowledge. But the truth is that your role is not to be a teacher. And it's not to say that you won't provide some information, some critical information even as a subject matter expert but a subject matter experts job is not to teach the technical details but instead to communicate their impact. So we're kind of getting ahead of ourselves here but it's not to teach the person who is non-technical that's not your job to teach them. The second thing you have to be aware of as an engineer is that the reasons that you might make a decision, especially the technical reasons that you might make a decision, are very likely to not make immediate sense to your audience. In other words, let's imagine that the technical reason that you want to use a particular language is because it's ability to work concurrently or some kind of performance metric. Well communicating this raw performance metric is unlikely to sway an audience that doesn't really know the difference between one language and another or one performance metric and another. We're going to take a quick sponsor break and then I'm going to come back and give you some pointers, some detailed ways of doing this better when you're communicating with non-technical stakeholders. This episode is sponsored by Linode. With Linode you can get started with as little as $5 a month with Linx in the cloud. And on top of that, Linode is going to provide you as a new user of Linode, $20 worth of credit for using the promo code Developer Tea 2020. With Linode you get 11 data centers worldwide, including the newest data center in Sydney, Australia, Enterprise Grade Hardware, S3 Compatible Storage Option, and the Next Generation Network. Linode delivers the performance you expect at a price that you don't. You'll get root access to your Linx server along with an API that is all the way at version 4, a Python CLI. This is all because Linode is a company of developers building tools for other developers. They understand the kinds of things that you want and need to be productive. I mentioned that $5 a month, that's the nano plan. It starts as low as $5 a month. And of course, Linode scales all the way up to the most specific needs you could have. For example, dedicated CPU plans or GPU compute plans. Go and check it out head over to Linode.com slash Developer Tea. Use the promo code Developer Tea 2020 that's Developer Tea 2020 to get that $20 worth of credit at checkout. Thanks again to Linode for sponsoring today's episode of Developer Tea. So if you're communicating to a non-technical stakeholder, then we should go back to that definition of what your job is to provide value. And since value is, in many ways, determined by your audience rather than by you, it makes sense to understand what they find valuable. If you can't make the technical details worth thinking about, if you can't make it worth talking about, if your audience is not interested in those technical details, then your time spent talking about them has probably wasted. Instead, figure out what they do care about. Why are they having this discussion with you? What is the decision and its impact on the things that they are responsible for? It's even reasonable to ask somebody before a meeting, what are your primary concerns? What are your factors for making this decision with me? And what role would you like me to play in the decision-making process? Are there any metrics that you're looking to optimize for? These kinds of questions can guide the conversation that you have. So you might want to ask that a day in advance so you can prepare and extrapolate from your own technical knowledge and draw the lines, draw the correlations between the options that you have, the decision options that you have, and the impact that it has on the things that that person, that audience cares about. This sounds incredibly simple, but in reality, it's incredibly complex. Understanding what other people value is not as simple as asking them just for those metrics, but also understanding the kinds of things that they're not telling you that they value as well. Maybe they were assigned this decision and, frankly, they don't really care too much about what the decision outcome is. Maybe the answer is to make the decision as easy as possible for that person to make. Ultimately, your job as an engineer is not only to write code, but to understand how that code impacts other people and how it helps them achieve various values that they care about. So I hope this was helpful for you and I know other engineers are facing this same problem, those of you who are listening that find this valuable, please consider sharing it with other engineers that you think would benefit from it as well. Thanks so much for listening to this episode of Developer Tea, a quick reminder about JS Nation Live. JavaScript seems to be everywhere these days, most developers, if they haven't used it yet, they probably will, but most probably already have. And JavaScript is not frozen, it's not stagnant, the tooling and the language itself are still growing and changing. And if you want to hear from people who are responsible for that growth and change and the future of JavaScript, then head over to live.js Nation.com and get your free registration to JS Nation Live. This is happening on June 18th and 19th as of the airing of this episode that is six days away. So go register head over to live.js Nation.com registration is once again free. Thanks again to Linode for sponsoring today's episode head over to Linode.com slash Developer Tea and use the promo code Developer Tea 2020 at checkout to get $20 worth of credit on any Linode service or product. My name is Jonathan Cutrell and until next time, enjoy your tea.