Today, we're answering a listener question from Saul: How do you communicate a technical solution to a non-technical team member? Specifically, when that team member needs to be involved in making a decision that has technical implications?
In today's episode, we dive into Saul's question by recounting past experience and providing tools to approach this situation at a human level and from your employers expectation.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop a message over at: developertea.com.
Whether you’re working on a personal project or managing your enterprise’s infrastructure, Linode has the pricing, support, and scale you need to take your project to the next level. Get started on Linode today with a special $20 credit for listeners of Developer Tea.
Wanna get your hands on the hottest #JavaScript tech?
Reserve a spot at #JSNationLive happening on June 18-19, and see speakers / instructors like Tobias Koppers (Webpack), Orta Therox (TypeScript), Minko Gechev (Angular), Matteo Collina (Node.js) and many others.
Check them out and reserve your FREE spot at live.jsnation.com
Visit: linode.com/developertea and use promo code developertea2020
P.s. They're also hiring! Visit https://www.linode.com/careers to see what careers are available to you.
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 Cottrell. You're listening to Developer Tea. 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 jcottrell. And you can also find me at developertea. 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. Now, we can get into the nuanced discussion of... What 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, having 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. 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 that's not to say that you won't provide some information, some critical information even, as a subject matter expert. But the truth is that you won't provide some expert. But a subject matter expert's 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, is that you're not going to be able to teach them 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 its 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. So if you're a teacher, you're going to have to be very careful about how you're going to communicate this raw performance metric. So if you're a teacher, you're going to have to 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 Linux 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 code developer T 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 Linux server along with an API that is all the way at version four, 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 Nanode 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 T. Use the promo code developer T 2020. That's developer T 2020. To get that $20 worth of credit at checkout. Thanks again to Linode for sponsoring today's episode of developer T. 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 you, if, if your audience is not interested in those technical details, then your time spent talking about them is 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 kind of 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 experience. So if you were to write your ownijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijijij 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. Saul, 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 the people who are responsible for that growth and change and the future of JavaScript, then head over to live.jsnation.com and get your free registration to JS Nation Live. This is... 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.jsnation.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 developertea2020 at checkout to get $20 worth of credit on any Linode service or product. Today's episode was produced by... My name is Jonathan Cottrell. And until next time, enjoy your tea.