Making Technical Expertise Understood With Teach the Geek
Business Technology PerspectivesNovember 11, 2026
36
00:23:3421.58 MB

Making Technical Expertise Understood With Teach the Geek

What happens when the person who understands the technology best struggles to explain why it matters to the people making the decisions?

On Business Technology Perspectives, I'm joined by Neil Thompson, founder of Teach the Geek, to discuss technical communication, public speaking, and the professional opportunities that can depend on being understood. Neil began this work after struggling with presentations as an engineer. A project he was working on was eventually canceled, and he still wonders whether explaining its usefulness more clearly could have changed the outcome. He does not claim communication was the only cause, but the experience prompted him to develop a skill his technical education had not prepared him for.

What interested me was the difference between feeling comfortable in front of a room and giving that room information it can use. Neil describes the curse of knowledge, where expertise makes it difficult to remember what an audience does not know. Familiar terminology starts to feel universal, and a speaker can assume that an explanation has landed because the details seem obvious to them. The questions afterward can reveal a very different experience.

We discuss a board member who tried to show she belonged by including everything she knew in her presentations. Neil says their work together began with a different question. What did she want the other board members to think or do afterward? Starting with that outcome helped her choose the supporting information and leave out material that made the presentation harder to follow. It is a useful approach for anyone preparing a project update, a budget request, or a technical recommendation.

Understanding the audience takes preparation too. Neil recalls asking executive assistants what information their managers would find useful when direct access to those leaders was difficult. The lesson is to learn what the people in the room already understand and what they need to decide before building the slides. We also discuss why visual aids can lose their purpose when speakers and audiences spend the whole session reading the same text.

Generative AI offers one practical rehearsal aid. Neil suggests recording a practice presentation, creating a transcript, and using AI to identify jargon and propose more familiar wording. The speaker still needs to judge whether a replacement preserves the technical meaning. The aim is to make an explanation easier to follow while keeping it accurate.

We also cover unexpected questions and constructive feedback. Neil recommends repeating a question in your own words to check that you understood it, then being willing to say you need to find the answer. For managers, he emphasizes checking whether someone is receptive to feedback and explaining how better communication can help them contribute and progress. Career visibility is part of the discussion, although clear speaking cannot guarantee promotion or remove every organizational barrier.

Neil's final advice is practical. Reading about communication can help, but improvement requires actually communicating. Whether you are an engineer presenting to executives or a manager trying to help expertise reach the right people, this conversation offers several things to try before the next meeting.

I'd welcome your thoughts. What has helped you make a complex technical idea understandable without losing the detail your audience needs?

Useful Links

Website | LinkedIn | Inc. Magazine articles | Clarity is Strategy

[00:00:00] Once a year, I open up a handful of places for people who are serious about launching their own podcast, but have never actually gotten around to it. And over the last 11 years, I've helped entrepreneurs, business leaders and Fortune 500 companies all launch their own shows. And here is how it works. You record your conversation on Zoom, Teams or whatever works best for you.

[00:00:23] You send me the audio, an episode title and short description, and I will handle everything else. From setting up the podcast host and distribution to getting your show on Apple Podcasts, Spotify and the many, many other podcast platforms out there. I will commit to working alongside you to help you launch your first season of 12 episodes in the bag. So you can start 2027 by ticking a season of podcasts off your bucket list.

[00:00:52] Think of me as your not just personal podcast producer, but also your accountability partner to make sure that you actually deliver those 12 episodes into podcast land. Now, I only offer this once a year with limited places available. So if you want 2027 to be the year you finally launch that podcast, head over to techtalksnetwork.com. Send me a message, send me a DM or even an audio message. I'd love to help you make it happen.

[00:01:19] Have you ever understood a technical problem perfectly? Then watched a room of decision makers struggle to follow your explanation? You might know every single minute detail of the work, but still somehow leave the meeting wondering why the questions kept coming and the support never arrived. Knowing something and making it useful to someone. These are two very different skills.

[00:01:47] And today on Business Technology Perspectives, I'm joined by Neil C. Hughes, founder of Teach the Geek. And it's his experience as an engineer, including a project that was cancelled after difficult management presentations. All this happened for a reason. It led him to help other technical professionals communicate with greater clarity and confidence.

[00:02:12] So today we're going to discuss how to work backward from the decision your audience needs to make, spot the jargon that you've stopped noticing, and handle questions when you don't have an answer. And if you've ever used your slides as somewhere to hide and use it more of a script, you're in good company. And today's conversation will hopefully give you ways to make your expertise easier to understand for a wider audience. But enough from me.

[00:02:42] Let me introduce you to him now. So a massive warm welcome to the show, Neil. Can you tell everyone listening a little about who you are and what you do? Sure. I started a business called Teach the Geek, and it stemmed from my struggles as an engineer having to give presentations in front of management. And this was something that I had to do, wasn't something that I chose to do. And those first two presentations I gave were terrible, Neil.

[00:03:08] And they didn't get all that much better after I gave that first one. In fact, my project ended up being cancelled during one of these meetings. And it was then that I realized that perhaps speaking in front of people is something I needed to get better at. And I ended up joining Toastmasters. For those of you all that don't know, it's an organization with chapters all over the world, and you can practice public speaking. And I got a lot better at public speaking over time. And essentially, when I started Teach the Geek, it was to help people like myself,

[00:03:38] people that have technical roles and have to speak in front of others. At first, Teach the Geek was about becoming more comfortable speaking in front of others. But eventually, it evolved into more than that. Because as a technical person, you're speaking so that others can make decisions based on what you say. So in addition to being comfortable speaking in front of others, which is necessary, communicating in a way that is useful to others is just as important as well. So that's essentially what Teach the Geek is.

[00:04:07] I have a podcast also called the Teach the Geek podcast, in which I have technical leaders as guests, and they talk about the challenges that technical people have in communicating with non-technical people. I have a YouTube channel too, and I offer tips there on how to get better in communicating with others as a technical person. And then I go into organizations and work with their technical people on their communication skills. So that's Teach the Geek in a nutshell. Kudos to you for creating this. And it is so important.

[00:04:36] And I would argue that there's two skills that are required here. There's the first skill of public speaking, which is incredibly difficult. I would say most people struggle with. And then not only that, there's also the ability to change your tone and change the language when speaking with stakeholders that don't understand tech acronyms and everything. And being able to be that bridge between the two worlds is also a huge skill.

[00:05:01] But why is it you think that highly technical people often, they know their subjects so well, they know it inside out, but they still struggle to explain it to a non-technical audience. Why is that? What do you see and hear here from the people that you talk with? I think it starts with what some would call the curse of knowledge. Yeah. You learn all these things in school. And then you take on these technical roles.

[00:05:26] And year after year, you gain more and more expertise in what your role is. And you just assume that when you speak to other people, they know what you're talking about because you know what you're talking about so well. But I think what a lot of technical people need to realize is you weren't always that expert. As I said, you went to school, you got this education, you took on these roles, you got this expertise, but you weren't always that person. Who were you before you took on this role and before you got that technical degree?

[00:05:55] What kind of information could you have understood back then? And I think that a lot of us as technical people, we forget. And then we give these presentations and we use all the jargon. We talk about all these complex concepts and just assume people understand. And, you know, when I was giving those presentations, I knew people didn't understand after that first presentation. And I knew that because I get a whole lot of questions after the presentation that I thought I'd answer during it. But I didn't make any kind of modification for that next presentation, Neil.

[00:06:24] In fact, as I said, my project eventually got canceled. And this happened over 15 years ago. And I still look back on that time and think, man, if I was just better at communicating the usefulness of what I was working on, perhaps the company could have this product out there making good money for it. I guess we'll never know. It's an incredible journey you've been on here. Going from day one, you had that presentation. You thought you'd answered everyone's questions. The project got canceled because of it. It was a bit of a nightmare. Everything went wrong. But then since then, you've been on this journey.

[00:06:53] You're teaching the geeks and you've had huge success yourself. But to bring to life that journey from where you were to where you are now, are you able to share a story of a presentation that maybe changed once the speaker stopped trying to prove expertise and actually started solving the audience's problem? Do you have any stories around that? Oh, sure. I mean, I've worked with numerous engineers and technical people over the years since I started Teach the Geek.

[00:07:18] One that stands out is a technical person working with an organization. She was on the board. And I suppose she was new to the board, too. So she really wanted to show that she belonged there because everyone else on the board had been there for quite some time. And her presentations, she found out, were very difficult to follow. But she was trying to cram everything that she knew into her presentation to prove, as I said earlier, that she belonged on the board.

[00:07:45] And what she ended up doing, at least what we worked on, is figuring out what the call to action is for her presentations. What did you want people to think or do after the presentation? And then once you have the answer to that, work backwards. What kind of points do you need to make that will naturally lead to that call to action? And what that does is it eliminates any extra information that you would have included in the presentation. You're not hitting everybody with the kitchen sink of everything that you know. That's not necessary.

[00:08:14] And so once she did that, her presentations became much easier to follow. She didn't ramble as much. She didn't try to over-explain everything. And she was telling the other board members what they needed to know so that they could make decisions. And she had to look back. Love it.

[00:08:32] And if we do have, let's say, a few techies listening that often feel frustrated in corporate environments with how complex technology is now dumbed down and how non-techies can stand up in front of an audience and talk confidently about things that they really don't know much about. So for that technical person, what should they be learning about the people in the room before deciding what to include and prepare their presentation? When I first started giving those presentations in front of management, I knew how I was speaking in front of.

[00:09:02] CEO, CTO, COO, C, fill in the blank, O, all these C-level people. And I was tasked to talk about project status. But I never thought about what they knew already and what they needed to know. I would just get up there. I'd read slides. I'd try to get it out there as quickly as possible. But I never did because, as I mentioned earlier, I'd get a whole lot of questions afterwards that I thought I'd answer during the presentation. What I ended up doing eventually is I would go to their administrative assistants.

[00:09:30] It was difficult to get time with the C-level people. They're busy. But I'd go to their admins and ask them, what kind of information do I need to have in this presentation that'd be useful to your boss? And then I'd make sure that that information was in the presentation. So, essentially, what I was doing is I was going to them to figure out, if I were to give this presentation, to keep these people's attention so that they can make those decisions. Because if they're not paying attention, then obviously they can't make decisions based on what you said. What do I need to have in the presentation?

[00:10:00] And then, as I said, I just make sure that that information was there. And, again, for someone listening, how can they better simplify a very complex idea but without making it inaccurate or we're still patronizing? How do they make it more relatable and will ensure that it will resonate with their audience? Yeah, it's about thinking about that jargon. As I mentioned earlier, I think most technical people forget that we didn't always know the jargon. But now that we have generative AI, it's become way easier.

[00:10:26] So, we could speak even just a bit of our presentation. You know, we want to practice our presentations anyway. So, then you would give a, you know, you do your presentation as you're practicing it, get the transcript of it. And then you can use generative AI to identify jargon and then perhaps some more commonly used words that you could use instead of using the jargon. I've done this numerous times. I've suggested others use this as well. Because in a lot of cases, you may not even recognize what the jargon is anymore because you use it so often.

[00:10:56] But if you use generative AI to point it out, you might think, oh yeah, that kind of is jargon, isn't it? But here's some more commonly used words that we could use instead that the people in the audience would more likely understand. And regardless on what side of the fence everyone is listening and yourself and me here, I think one thing that we've all experienced, and that is death by PowerPoint.

[00:11:20] And slides themselves often become almost a safety net for nervous speakers who can very often just read the words on the slide that everybody in the audience is reading. So, what is it that makes a visual aid useful rather than a script on a screen? Any advice there? Oh yeah. Don't have it so that you can easily read the slide and then move on to the next slide. Because if you do that, the people in the audience are doing the exact same thing.

[00:11:46] And while they're doing this, they may very well be thinking to themselves, why am I here? You could just send me the slides and I could read them at my own leisure. Yet here I am listening to you read, even though I can read. And ultimately, it's all about public speaking, Neil, not public reading. So, if you are going to use slides, try to make it so that you don't have as many words on the slide. So, it eliminates the opportunity for the speaker to simply just read the slides.

[00:12:12] And it also eliminates the opportunity for the audience members to just read the slides. They either are going to listen to what you're saying or they're going to ignore you. And hopefully, you're doing a good enough job so that they don't ignore you. And I was laughing as you were talking about that there because I myself had been that guy. I've been the guy reading the slides. It makes me cringe thinking about it. And I think it's something we all might have done in the past. At present presenting, I'm not a big fan of it myself. It does make me incredibly nervous too. It's very real out there.

[00:12:42] So, what practical techniques could help an expert answer maybe an unexpected question as well without automatically retreating into jargon, which is their safe space? When it comes to those unexpected questions, it's interesting you asked that. I actually wrote a piece about that a couple of years ago. The first thing you should do is repeat back the question. In so many instances, we may not even have heard the question that was asked. And then we start talking and we're not even answering the question that was asked.

[00:13:10] So, repeat the question back in your own words and get confirmation from the person asking the question that that was the question that was indeed asked. Now, let's just say there's a confirmation. You understand the question, but you still don't know the answer. I think a lot of us technical people, we are enamored with being seen as that subject matter expert and that we will have the answers, but no one has all the answers. That's just something that we have to come to grips with. So, a lot of us need to become more comfortable saying we don't know.

[00:13:38] I don't know, but I'll find out the answer, especially if you're speaking to these non-technical decision makers like I was when I was giving those presentations. Just saying, I don't know. Well, that's definitely not good enough in front of the CEO, but I don't know, but I'll find out. That's more than acceptable, especially if you're in situations like I was when this is a monthly thing. You're going to see these people again in a month and hopefully you'll have answers by then. Yeah, completely agree with you.

[00:14:03] And elsewhere, how should managers give feedback when the problem is not the employee's knowledge, but the way that they're communicating the knowledge? Because it can be difficult for managers to give that feedback without offending or even lowering the self-esteem of someone that wants to be presenting. Is there a best way of tackling that issue too, to try and empower rather than remove the confidence? Yeah.

[00:14:29] So firstly, you have to figure out whether this person's even open to feedback and hopefully that is the case. But then after that, if they are, you can either just let them know that this isn't coming from a bad place. It's coming from a place where they want to help you get better and move up within an organization. And even as a technical person, if you're paying attention, you can see who those people are, those ones who move up within organizations. I remember this has happened a few years ago now.

[00:14:57] I was speaking to a patent attorney, but before she was a patent attorney, she was an engineer. And she said that when she worked as an engineer, she would notice the people who moved up within her organization. And she was annoyed by the fact that they were moving up and not her. And she thought that they had the brown notes. They had to suck up the people to move up. But as I saw it, I remember her saying this, and this is an older woman. I'm old enough to do my mother.

[00:15:25] And I remember thinking to myself, I hope you got past that at some point. Because when you're working within an organization, you can't assume that people just know what you're doing. You have to communicate your usefulness or your value to an organization. That's not brown-nosing. That's just being smart and appealing to the appropriate people so they know what you're doing, so that they know whether you're the type of person they want to see move up within their organization.

[00:15:52] So then when it comes to the feedback, going back to the feedback, what's really important is just, again, making sure that person is open to it. And then even pointing out other people within the organization and seeing these are the types of people that move up because they do X, Y, and Z. And so if you do X, Y, and Z, you have a much better shot of moving up within the organization too. But as I said earlier, if you're someone who's paying attention, you probably can see this anyway. Yeah.

[00:16:19] And in your answer there, it's clear, it's such a huge problem, not just on both sides of the pond. I'm here in the UK, you're in the US, and it's something that I think we've both seen a lot of. And just to highlight what huge problem it actually is, what kind of career opportunities do you think technical professionals listening could be missing when their work is so valuable and they have so much expertise, but decision makers just don't understand its impact or they don't see them in front of stakeholders, in front of a business.

[00:16:49] How damaging is that to a career? I mean, those are the types of people that are miserable. Those are the people who are disgruntled sitting at their desk thinking that there are opportunities that they were primed for, but they didn't get them. But who did get them? The visible people. And who are the visible people? The people who are the better communicators. In fact, now that I think about it, this reminds me of a conference I attended a couple of years ago, a technical conference here in San Diego where I live.

[00:17:17] And there was a breakout session and there was a business development person who gave a presentation. And afterwards, he got a whole lot of questions that he couldn't answer. Luckily, there were two engineers from his company who were in the audience and they answered all the questions from their seats. And I just remember thinking to myself, why didn't one of them at least co-present with that business development person? And could it be because they just weren't comfortable being up in front of others, even though everyone else in the audience were other engineers? So I mean, if you were going to use the jargon, this is people to use it with because they're

[00:17:47] likely going to understand it. But then those are the types of people that tend to miss out on the opportunities. Those are the ones who are seated in the audience, answering questions from their seats. People will often forget about them after the presentation since they were the people in front. Their organizations won't think of them as the people in front because they don't offer to be the people in front. And so they don't get those types of opportunities. And I mean, this applied to me as well.

[00:18:14] Once I got better at communicating with others, opportunities just seemed to just show up. I ended up, I remember at this one job, they sent me to present in Venice, never been to Europe before. And I got to go and eat real pizza, just only because I got better at communicating with others. Do you need AI agents that you can trust? Well, with an AI data layer providing real-time connection within your data platforms, you can

[00:18:43] trust your agents to provide accurate solutions. So scale your business by trusting your agentic AI accurately getting the work done for you. Trust its capabilities with Denodo. And you can do that by simply visiting denodo.com to learn more. And I think it's also important to highlight that that non-techie up there that appears to have all the confidence that the techies would desire and really want deep down.

[00:19:12] That non-techie is also terrified that he or she is going to get a technical question thrown in their direction. So I think it's great to remember that as well. Don't be fooled by what you see on stage. And I think that is why, I mean, a great point a moment ago about co-presenting where you've got the best of both worlds up there, where the non-techie can fire all the questions for stakeholders and answer them all day long and business value.

[00:19:37] And equally, you'll have the techie that can handle the more technical aspects of that. But for people listening, so much of what you've said resonates with them. They are the person that is sat in the office feeling disgruntled and frustrated that their opinions are not taken on board. If they're listening and they want to maybe start 2027 by overcoming these challenges and being a better version of themselves in the workplace, any tips or advice that you would offer to that person listening that's been nodding their head throughout our conversation

[00:20:07] tonight? Oh, yeah, sure. First, it's you got to start somewhere and you can read all the books, watch all the podcast episodes or listen to all the podcast episodes, watch all the YouTube videos. But you don't get better at communicating with others until you start communicating with others. And to get those kinds of tips, certainly you can go to my YouTube channel. That's youtube.teachthegeek.com. And I think I also mentioned my podcast earlier.

[00:20:33] And I asked quite some interesting questions to my guests, like the communication gaps. What do they typically see? What are the outcomes of those gaps? What organizations can do to help their technical staff in addressing those communication gaps, even questions like how to communicate with mixed audiences? Because that could be a difficult scenario to be in. You're talking to super technical people. You're talking to non-technical people. You're talking to everybody in between. How do you go about doing that?

[00:21:01] And to check out those interviews, you can go to podcast.teachthegeek.com. But ultimately, it starts with you. It starts with you understanding that that's something you want to get better at. And just it starts with starting. Awesome. And I will include links to everything there, the YouTube channel, the podcast, the website. If someone just wants to start a conversation with you and see where that might lead, where can they find you online to? Oh, yeah. They can go to teachthegeek.com. Awesome.

[00:21:29] I'll include that along with your LinkedIn profile. So important, the issues that you've raised today. And I love the journey that you've been on. And I suspect many people would have been on a similar journey. I would include myself in this, but I've not done anything about it. Well, the fact that you've gone out there and it's impacted you and you've made a difference and also helping others, giving back those incredibly cool. So thank you for sharing your story today. Thanks for having me, Neil.

[00:21:55] I think one of the many things I'm taking away from this conversation today is the importance of preparing a presentation around what the audience needs to decide. Sounds straightforward, but it's easy to fill the time with everything we know and leave the useful point somewhere near slide 27. And his advice, I think, also offers a great place to start. Ask what people already understand.

[00:22:22] Decide what you want them to think or do and keep the information that helps get them there and practice saying it out loud. Check for jargon. People outside of IT do not like acronyms. And possibly most importantly, give yourself permission to follow up when an answer needs some work. From there, confidence can grow through that process rather than having to arrive before it.

[00:22:47] So a big thank you to Neil Thompson from Teach the Geek for joining me. If anything resonated with you, his website, podcast and YouTube channel, you will find them all in the show notes. But please share your thoughts. What would you change about your next technical presentation to make any decision clearer for everyone in the room? techtalksnetwork.com. Let me know. I'll be back again soon with another guest, but lots to think about there. I'd love to hear from you. So I'll speak with you again soon. Bye for now.