Speak Like a Leader, Not Just an Engineer

Ultimize. Before you create your next presentation, do this first: write down your goal in one sentence. Not the topic, not everything you know, the goal. Because if you can't clearly state what you want your audience to understand and to do, there's almost no chance they will. That one step alone will immediately make your presentations clearer and more effective. Hi, you're entering Public Speaking for Engineers produced by Ultimize. I'm your host, TJ Walker. If you're an engineer, you've been trained to value precision, completeness, and depth. That works extremely well when you're building systems. It often fails you when you're trying to explain those systems to other people. The problem isn't that you don't know enough. The problem is you're not designing your communication the way you design everything else. By looking at the results. In this podcast, we're going to treat every presentation as an engineering challenge. This is an objective. There are constraints, there are failure points, and there is a way to design for a successful outcome. We're going to program your brain for one specific result: successful communication where people understand you, remember your message, and act on it. And just like any engineering system, you won't rely on guesswork. You will test your presentations, measure what works, and improve based on real evidence. If you're ready to stop overloading your audience and start delivering clear, effective presentations, then let's begin. This is a limited series podcast, so you don't have to listen once a week for the rest of your life. Just a handful of short episodes. You can binge the entire thing in less than 2 hours and be on your way to being a great presenter. Let's dive in. After your next presentation, ask one person who heard you the following question: What do you remember? Not what they liked, not whether you did a good job. Just ask, what do you remember? Because that answer is your real performance data, and most engineers never collect it. You're entering Public Speaking for Engineers, produced by Ultimeyes. I'm your host, TJ Walker. Let's start with something important. Engineers are not bad at communication because they lack intelligence. In fact, the very skills that make you a strong engineer are often the same ones that hurt you when you present. You've been trained to value completeness. You want all the variables accounted for. You want all the edge cases covered. You want every assumption explained and every detail documented. Fine, I get it. That's exactly what makes you good in engineering. It's also precisely what makes most engineering presentations ineffective. Because your audience is not trying to rebuild your system. They're trying to understand what truly matters. And when you give them everything, they often walk away with nothing. This is the core problem. Most engineers treat presentations like documentation. They think the goal is to transfer as much information as possible. Sorry, it's not. So they include everything, all the background, all the data, all the caveats, all the logic, and they assume that if they said everything correctly, the job is done. But communication doesn't work that way. The goal of a presentation is not to say everything. The goal is to get a specific result. That result might be approval for a budget, alignment with your goals, funding for your project, understanding, a decision, If your audience doesn't understand your key point, remember it, and act on it, then the presentation failed, no matter how accurate it was. Now, here's where we shift to an engineering mindset. In engineering, you don't assume something works, you test it. You measure the output, you analyze the results, you refine the system. You don't say, "Well, I built it, so it must work." You validate it. But when it comes to presentations, Most engineers completely abandon that mindset. They prepare once, they deliver once, and they move on. No testing, no measurement, no iteration. That means they never actually know if their communication worked. From this point forward, that changes. Every presentation you give is now a system. You are designing it and testing it. And the output is not, did I say everything correctly? Oh no. The output is, did the audience understand my key points, remember them, and take the actions I wanted? And the only way to know that is through evidence. You need feedback that reflects reality, not your assumptions. Simple, practical things. Ask someone in the audience what they remember. Notice where people look confused. Pay attention to when attention drops. Track whether your idea actually gets accepted. That is your data. And once you start collecting the data, you'll see patterns. You'll notice that when you include too much detail, people disengage. You'll notice that when your message is not clear at the beginning, people never quite catch up. You'll notice that your slides often compete with you instead of supporting you and your ideas. And most important, you'll notice that clarity Beats completeness every time. This is one of the hardest adjustments for most engineers because it feels wrong. It feels like you're leaving things out. It feels like you're oversimplifying. It feels like you're not being precise enough, but your audience doesn't need everything. If they did, they'd already have your job. They need the right things in the right order at the right level of detail. That is design. And that is where we begin treating communication as an engineering problem. You define the objective, you design the system to achieve that objective, you test it in the real world, and then you improve it based on what actually happens, not what you assume should happen. The last part is critical because most people never improve their presentations. They just repeat them. They keep using the same slides, the same structure, the same habits. And they assumed that if it didn't work, the audience just didn't get it. But if you take an engineering approach, that assumption disappears. If the audience didn't understand, the system failed. And if the system failed, you improve the system, not the audience. That is how you gain a massive advantage because most engineers never do this. They rely on guesswork. You will rely on evidence. And over time, that creates a huge gap. Your presentations become clearer. Your ideas get accepted faster. You become someone people listen to, not because you changed your personality or became charismatic or dynamic, but because you changed your system. Throughout this series, we're going to rebuild your approach step by step. We're going to simplify your thinking. We're going to structure your message. We're going to eliminate the habits that just don't work. And most important, we're going to make sure everything you do is grounded in results. Not theory, not guesswork, not assumptions, but results. In the next episode, we're going to tackle one of the biggest mistakes engineers make: why explaining more actually makes people understand less, and how to fix it. Before your next presentation, take your most important idea and explain it as if you only had 30 seconds. Not 5 minutes, not 10 minutes, but 30 seconds. Because if you can't explain it simply and quickly, you don't fully understand how to communicate it yet, and your audience definitely won't get it. Engineers deal with complexity. That's your job. You build systems with multiple components, dependencies, constraints, and interactions. You understand how all these things work at a deep level. But when you present that depth often becomes a problem because you try to transfer that entire understanding to your audience and it doesn't work. You can force and force and push, but it just doesn't work. Your audience does not need to understand everything you know. They need to understand just enough to make the decisions or take the actions you want them to. They just need to know enough to take action, enough to follow your reasoning. This is where most engineers go wrong. They assume that clarity comes from completeness. If I explain everything, give every little detail, people will understand. But clarity doesn't come from more information, more facts, more data dumping. That's not how it works. It comes from better organization and simplification. So let's break down how to explain complex ideas clearly. First, you need to identify the core of the idea. Not all the parts, not all the details, the core. What is the simplest version of what you're trying to explain? If you can't answer that, you're not ready to present. Because without that core, everything else becomes noise. Second, you need to sequence your explanation. Most engineers explain things in the order they discover them. That's natural, but it's not effective. Your audience doesn't need to go through your entire thought process. They need a clear path. Start with a high-level idea, then add one layer at a time, only as much as needed, and stop before you lose them. Third, you need to use comparisons and simple language, not because your audience is dumb, but because simple language reduces effort. Use as little jargon, use as few acronyms as possible. And when something requires less effort to understand, people are more likely to stay engaged. Instead of using technical terms immediately, you can say, "Think of it like this," and then give a simple comparison. Once they understand the concept, you can introduce more precise language if needed. Fourth, you need to pause and check understanding, not by asking, "Does this make sense?" because most people will say yes even if it doesn't. They don't want to look stupid. Instead, look for signals. Are people nodding? Are they following along? Are they sleeping? Do their questions indicate understanding or confusing? That's your data, and you use that data to adjust in real time. Now let's connect all of this to testing and evidence. How do you know if you explain something clearly? You don't guess. You test after your presentation. Ask someone, can you explain that back to me? How would you explain what I talked about today to one of your colleagues who didn't make it and was supposed to be here? If they can explain it clearly, you succeeded. If they struggle, not their problem, it's not their fault. You need to simplify further. It's always the speaker's problem if the audience doesn't get it. That's one of the most powerful tests you can run, asking someone in the audience what they actually learned and how they describe it to someone else, because it measures actual understanding, not perceived clarity. And over time, this test will change how you communicate. You'll start to notice patterns. You'll see which explanations work and which don't. You'll learn how much detail is enough. You'll develop a sense for when to stop. That's how you improve, not by adding more, by refining what works. Now let's address a common concern. Engineers often worry that simplifying complex ideas will make them seem less credible. That's not true. In fact, the opposite is true. The ability to explain something clearly is a sign of mastery. If you truly understand something, you can explain it Simply, if you can't, it usually means your understanding is still tied to complexity. Your audience doesn't evaluate your intelligence based on how complicated your explanation is. They evaluate it based on how clearly they understood you. Clarity builds trust. Confusion destroys it. Now let's bring this back to the engineering mindset. Think of your explanation as a system. The input is your idea. The process is how you present it. The output is understanding. If the output is not what you want, you don't blame the audience. You improve the process. You simplify. You restructure. You test again. That's how you get better. So from now on, identify the core idea, build your explanation in layers, use simple language and comparisons. Test understanding with real feedback, because when you do that, something important happens. Your audience starts to follow you. They stay engaged. They understand what matters, and your ideas have a much greater chance of being accepted. In the next episode, we're going to address something many engineers struggle with: confidence and how to present effectively, even if you don't feel like a natural speaker. By the way, quick question for you. Have you ever noticed how easy it is to consume content and how hard it is to actually do anything with it? I mean, you can listen to 100 episodes, read 10 books, and your habits are exactly the same. That's the gap most people never close. So if you're listening to this and thinking, yeah, I want to actually improve, go to ultimize.com. We've got free courses there for you, either on communication skills or building better habits, and it's designed to get you to actually use what you're learning, not just hear it once. No cost, no catch. Just go to ultimize.com and start. Ultimize.