Never fake it: public speaking to further your career

Nobody teaches you this.

You go to school, get a degree, learn to code or sell or manage a P&L. You spend years getting good at the actual work. Then one day you're sitting across from a VP who asks what your team is working on, and you freeze. Not because you don't know the answer. Because you don't know which version of the answer they need.

It doesn't really matter if you're in marketing or sales or engineering or support or any other function. You could be a brilliant engineer rambling through database schemas when the CEO just wants to know if the product will ship on time. You could be a first-time marketer pitching a content strategy to the CTO using words like "brand awareness" and "thought leadership," and watching their eyes go dead. You could be a sales leader presenting pipeline numbers to the board using jargon that means nothing outside the building.

There is one kind of public speaking: the kind with stages and podiums and audiences of thousands. But what I'm talking about here is a different kind of public speaking: a Tuesday afternoon conversation. A standup. A one-on-one. A Slack thread where you have ninety seconds to make your point before the CEO scrolls past it.

These moments add up. They're how people decide whether you're someone worth listening to. Whether you belong in the room. Whether you get invited back.

The good news: audience adaptation is a learnable skill. For sure, the "public speaking" you're most familiar with also entails a form of audience adaptation. But the day-to-day quotidian conversations you have with your boss, your peers, and your customers are a different kind of public speaking that also entail a large degree of audience adaptation.

I'm going to show you exactly how it works, using one scenario played four different ways.

The bug that teaches everything

Let's say you're an engineer or product manager and your application has a critical performance bug. Under certain conditions, a poorly optimized database query causes page load times to spike from 200ms to 30 seconds. It affects about 15% of your users, but that number is growing. The query hits a table that wasn't properly indexed when the schema was designed six months ago. Fixing it requires adding indexes, rewriting the query, and potentially refactoring how the application caches this data.

Same problem. Same facts. Four completely different conversations. Kind of like Rashomon, but for nerds.

Talking to your tech lead

Your tech lead needs the details. They're going to review your code. They need to understand the technical approach and potential gotchas.

"I found the performance issue. It's the user activity query in the dashboard controller. We're doing a full table scan on the events table because we never added a composite index on user_id and created_at. Under load, this query is taking 30 seconds instead of 200ms. I want to add the index, rewrite the query to use it properly, and add query result caching with a five-minute TTL. I've tested the index addition on a staging database copy and it cuts query time to under 100ms. The cache will handle the 80% of requests that are repeat views. I can ship this today, but I need about four hours to test it properly. Can we pair on the caching implementation? I want to make sure I'm not missing any edge cases around cache invalidation."

Root cause, solution, validation, risks, and a specific ask for help. Everything a tech lead needs to say yes.

Talking to your director or VP of engineering

Your director cares about the details, but they're managing multiple teams and thinking about resource allocation and priorities. They need to understand impact and tradeoffs.

"We have a performance issue affecting about 15% of users right now. Page loads are spiking to 30 seconds because of a missing database index. I've identified the fix and tested it in staging. It's about four hours of work to implement properly. The impact is significant. We're seeing increased support tickets and our analytics show users are abandoning these slow-loading pages. If we don't fix this, it's going to affect our retention numbers this quarter. I can ship this today, but I wanted to check with you about priorities. Is this more urgent than the feature work I'm scheduled for? I think it should be, but I want to align with you on that."

You've escalated the scope. Instead of the technical problem alone, you've added business context: user impact, support load, retention risk. You've shown you understand priorities and resource tradeoffs. That demonstration of judgment matters more than the bug itself.

Talking to your CTO

Your CTO is thinking about architecture, technical strategy, and how this fits into the bigger picture. They probably don't need the implementation details, but they do need to understand if this is a symptom of a larger problem.

"I need to flag something. We have a performance bug that's affecting 15% of users and growing. It's a missing database index that's causing 30-second page loads. I can fix this specific issue today, but I'm concerned this is a symptom of a bigger problem. We don't have a systematic way to identify these performance issues before they hit production. Our database schema reviews are informal and we're not doing any query performance testing as part of our deployment process. I'd like to fix this bug today, but I think we should also schedule time to audit our other high-traffic queries and put better performance testing in place. What do you think?"

You've zoomed out. The bug is now context for a conversation about process and infrastructure. You've identified gaps in your development practices and proposed solutions. That kind of systematic thinking gets people promoted.

Talking to your CEO

Your CEO doesn't care about indexes or query optimization. They care about the business impact and what you're doing about it.

"We have a performance issue affecting our user experience. About 15% of users are experiencing very slow page loads, and that number is growing. This is driving up support costs and we're seeing it impact retention. I've identified the root cause and we can fix it today. I wanted you to know because you might see this come up in customer feedback or support metrics, but we're already handling it. Once this is fixed, I'm also going to work with the team to put better performance monitoring in place so we catch these issues earlier."

Problem, impact, solution, timeline. No technical jargon. No implementation details. Just the business facts and the assurance that it's being handled. You've also managed their expectations about metrics they might see. That shows you understand how CEOs think.

The principles behind the translation

Notice what changed in each conversation and what stayed the same. The facts never changed. You told the truth every time. What changed is emphasis: you gave each person the information they needed to make their specific decision.

Each function processes information differently too. If you want to go deeper on how engineers, marketers, and salespeople think and talk, I've written about that.

Each audience has different questions they're trying to answer. Your tech lead is asking "Is this technically sound?" Your director is asking "Is this the right priority?" Your CTO is asking "Does this indicate a bigger problem?" Your CEO is asking "Is this going to hurt the business?"

Answer the question they're asking, not the question you want to answer.

Why this matters more than your technical skills

Every other skill you have becomes more valuable when you can communicate it to the right audience. You can write the most elegant code in the world, but if you can't explain why it matters in terms your leadership understands, you won't get the resources you need. You can identify urgent problems, but if you can't make people care, those problems won't get fixed.

The good news: you can learn to do this. Pause before every important conversation and ask yourself three questions:

1. What does this person need to decide or understand?
2. What information do they need to make that decision?
3. What can I leave out because it doesn't serve that goal?

Most engineers err on the side of too much detail. We want to be thorough. We want to show our work. We think that if we just explain it properly, everyone will see what we see.

But communication doesn't work that way. Nobody needs your entire mental model. Give them exactly what they need and nothing more.

Practice makes permanent

Start small. The next time you're in a meeting with someone more senior than you, pay attention to how they communicate. Notice what they include and what they leave out. Notice how they adapt their message when different people are in the room.

Watch how your CEO talks to the board versus how they talk to the engineering team. Watch how your CTO talks to your CEO versus how they talk to you. Free masterclasses in audience adaptation, happening every week.

Then practice it yourself. Before your next one-on-one with your manager, write down what you plan to say. Then rewrite it for their boss. Then rewrite it for the CEO. You'll never deliver all three versions, but the exercise will help you understand what changes and why.

Audience adaptation separates senior engineers from staff engineers, staff engineers from principal engineers, and principal engineers from CTOs.