Transcription
Your career isn't growing, and the reason probably has nothing to do with your technical skills. It's the way that you communicate. You're building up to your point when you should be leading with it. And you're giving people everything, you know, when all they needed was two sentences.
I spent nearly 20 years at Amazon and reached principal engineer. Since leaving, I've coached thousands of engineers on this exact problem. If you're frustrated because people aren't getting what you're saying, let's fix that.
So, here's the first technique. If you do only one thing, learn this. Say your point first. Everything else comes after. Think of it like a pyramid. The point goes at the top. Everything underneath supports it. Most people build the pyramid from the bottom and then put the point on last. And by then, nobody's listening.
Instead, use a simple framework called BLUF. Bottom Line Up Front. Most people do the opposite. They build up to their conclusion. "First, I looked at the data. Then, I noticed the pattern. Then, I talked to the team. And based on all that, here's what I think we should do." The person listening is holding all of this in their head, not knowing where it's going or why they should care. By the time you get to the recommendation, they've forgotten how the sentence started. But the person listening doesn't need your journey. They need your destination. They'll ask about the journey if they care.
Let me make this concrete. Let's say your VP asks why feature delivery is slowed down this quarter. Here's how most people would answer. "So, we've been dealing with a lot of accumulated shortcuts in the codebase over the past two years. Every time we've had a tight deadline, we take the fast path instead of the clean path. That was fine at the time, but those shortcuts have been compounding. Now, every time we try to build something new, we're spending more time working around the old code than writing new code. The authentication module is probably the worst offender. It was written as a quick prototype 3 years ago and never got rebuilt. And now, six different services depend on it. Customers want SSO and multifactor authentication, but we can't add those features without entangling everything first. So, the reason features are taking longer is that we're essentially fighting the codebase every step of the way."
So, your VP asks the same question again. "Okay, but why are features taking longer?" You just told them, but they couldn't find the answer in all of that context. We do this because chronological order feels natural. You've experienced the problem, then the investigation, then the solution in that sequence. So, you explain it in that sequence, but your audience doesn't need the sequence. They need the answer.
Now, here's the BLUF version. It's the same information, but coming in at a different direction. "Feature delivery has slowed down because we've accumulated too much technical debt, especially in the authentication module. We need about six weeks of dedicated cleanup to get velocity back to where it was. I'd like to propose pausing one feature track next quarter to make that happen."
Your VP is probably going to push back. "Six weeks? Why so long? What exactly is wrong with authentication?" Good. Now you can go into the details, but now it's on their terms. You can explain that the auth module was a prototype that never got replaced, that six services depend on it, that customers are asking for SSO and MFA, and you can't deliver either without fixing the foundation first. The same details that got lost in the bottom-up version will now land because your VP already knows the headline and they're choosing to go deeper. You're not withholding information, you're just changing the order.
Next time you're about to explain something, ask yourself one question. What's my point? Say that first. If you find yourself three minutes into an explanation and you say something like, "So, basically what I'm trying to say is..." you went bottom-up. Flip it around. Practice in low-stakes situations first. The next email you write, put your ask or your conclusion as the very first sentence. It'll feel abrupt at first, but it's not.
Now, BLUF gets you to the point fast, but there's a second mistake people make even after they lead with the answer. They bury the audience in context they don't need. That's what the next technique fixes.
Speaking of getting your point across, I write a newsletter every week to nearly 40,000 people. And the hardest part isn't the writing, it's figuring out what point to make. I've got over 150 posts at this point. And some crush, some land flat. For a long time, I was spending an hour every week manually digging through the data trying to figure out the pattern. So, I built a custom agent in Notion to do it for me. Every Monday morning, it reads my newsletter database where I have the titles, views, and likes data, and it spots the trends. It gives me 10 suggested topics for the week with the specific angle for each one.
This is what was waiting for me. Like here, it noticed that my one-on-one post had the highest likes in the entire database. So, it suggested an advanced sequel, "The Five Questions That Turn a One-on-One Into a Promotion Plan." The agent read my data and found a pattern for a newsletter that I wouldn't have on my own. Instead of staring at a blank page every Monday, I start with abundance and at least 10 ideas backed by my own data. Nearly every week, it sparks a direction that I further develop. By 9:00 a.m., I'm writing instead of figuring out what to write. And setting this up took only about 3 minutes. There's no API, no code, and no separate AI tool. You describe what you want in plain English, pointed at a Notion database you already have, and set a schedule. That's it. It just runs where your data already lives. Try custom agents in Notion. The link is in the description. I built a second agent that's even more useful for my 7-figure business. I'll show you that one next video.
Our goal is to explain complicated things to people without dumbing it down. But before we get to that, we first need to talk about the right amount of context. You don't need to teach people everything that you know. You just need to give them enough to handle what's in front of them right now. I call this "just-in-time context." Most people overexplain because leaving things out feels wrong, and you understand something deeply. Giving someone a partial picture feels sloppy. You know their subtlety. You know there are caveats and edge cases. So you include all of them because what if they make a bad decision because you left something out? But a complete explanation and a useful explanation are almost never the same thing. The person that you're talking to isn't trying to reach your level of understanding. They're trying to do something like make a decision or move on to the next step. Your job is to figure out what that something is and give them exactly enough of it to do it.
Let me show you what I mean. After your BLUF conversation with the VP, your product manager pulls you aside. They've heard the term "technical debt" a dozen times, but they don't really understand what it means for your team. They need to figure out how to talk about it in their next planning meeting. Here's what most engineers would do. "Okay, so technical debt comes in a few different forms. There's deliberate debt, where you knowingly take a shortcut to hit a deadline. There's accidental debt, where you didn't realize you were creating a problem until later. And then there's bit rot, which is when code that was fine originally degrades over time because the requirements changed around it. For our team, we've got all three. The authentication module is deliberate debt from 3 years ago. The payment system has accidental debt from when we integrated the new vendor. And the notification system is bit rot because we bolted on four different channels without ever rethinking the underlying architecture."
Your PM needs to know how to talk about this in a planning meeting. They did not need a taxonomy of debt types. Here's the just-in-time version. "For our team, technical debt basically means we took a lot of shortcuts over the past couple of years to ship faster, and now those shortcuts are slowing us down. The biggest problem is the authentication module. It was supposed to be temporary, but six services depend on it. Now, today, our customers expect SSO and multifactor authentication, but those are table stakes features we should be able to ship in a few weeks. But because of how auth is built, each one is a multi-month project. That's the main thing worth bringing up in your planning meetings." It's the same knowledge but with a completely different filter. The first version communicates what you understand. The second version gives them what they need.
Before you explain something, ask yourself one question. What does this person need to do with this information? Literally write it down if you have to. "The thing this person needs to do with this information is..." Then let that sentence filter everything you say. If a piece of context doesn't serve that need, leave it out. You can always add more if they ask. Remember, the goal is to close the gap between what you say and what the other person actually understands. BLUF fixes the order. Just-in-time context strips out the layers that they don't need.
But sometimes you actually do need to go deep. This technique is how you do it without losing people. I call this the "zoomin." One thing I hear a lot is, "If I simplify, I'm dumbing things down." People worry that cutting context means cutting substance. The zoomin solves that. You take someone from what they already know to what they need to know, one layer at a time, without losing anything important. Here's how it works. You start with something that the other person already knows. That's your shared starting point. Then you go one layer deeper. You break that layer into a small number of categories. You pick the one that matters. You go deeper into just that one and you repeat until they have enough.
Let me show you with something that trips up even really smart people. Try explaining what a tensor is. If you look it up, the mathematically correct definition is that "a tensor is the tensor product of several vectors and co-vectors." Read that again. They use the word tensor to define tensor. That's technically correct, but it's completely useless unless you already know what a tensor is. That definition exists for mathematicians and physicists who need precision, but it's not built for the front-end engineer who just got moved onto your ML features team and needs to start reading PyTorch documentation by next week. They can code, they know data structures, they know what a vector is, but they do not have a math PhD.
So, zoom in, start with where they are. "So, you know what a vector is, a list of numbers. A matrix is just a bunch of vectors stacked together. That's rows and columns like a spreadsheet. Two dimensions." Zoom in. "A tensor is what happens when you keep going. Add a third dimension and now you've got a cube of numbers instead of a flat grid. You can add a fourth, a fifth. A tensor is just a container for numbers that can have any number of dimensions." Zoom in. "When PyTorch calls your data a tensor, that's all it means. It's a multi-dimensional array." The math underneath is deeper, but for reading the docs and writing code against it, that mental model gets you there. That was three zooms. They went from "I don't know what a tensor is" to a working mental model they can actually use on Monday. You didn't say anything wrong. You didn't start with tensor products and co-vectors.
Now, is that the full picture? No. If they eventually need to understand tensor contraction or co-variance, they'll need the formal version. But that's not what they need right now. Right now, they need to read the docs and not feel lost. You gave them exactly enough for that. That's the zoomin. You didn't dumb it down. You started where they were and you went one layer deep each time. The precision can come later. Understanding comes first.
Now, let's bring this back to our example. Your new engineering manager just joined from another company. They've seen the sprint metrics and they know that velocity is trending down. Zoom in. "Velocity dropped because of accumulated tech debt." Zoom in. "The debt sits in three systems. Authentication is the one that's hurting us." Zoom in. "Auth was built as a temporary prototype 3 years ago. Six services depend on it now. So any changes require coordinating across all six. Features that should take a week take three." That was three Zooms. You started where they were, not where the problem started. They now have enough to make some decisions. That's the difference between bottom-up and zoomin. Bottom-up starts from the beginning and tries to build the whole picture. Zoomin starts from shared understanding and only goes deeper where it matters.
Next time you need to explain something, ask yourself what the other person already knows. That's your starting point. Go one layer deeper. Break it into two or three categories. Pick the one that matters. Go deeper into just that one. Stop when they can take the next step. In practice, the whole thing usually takes three or four sentences. It only feels like a lot of work because I just spent a few minutes explaining the approach. Using it is fast.
By the way, this is the kind of framework that I teach inside of my coaching program. Me and my team of principal-level coaches work directly with tech professionals to maximize their performance at work. Things like communication, visibility, and getting promoted. If that sounds like something that you need, there's a link in the description.
I used all three of these communication techniques to write this video. If it felt easy to follow, that's not because the material is simple. It's because the direction was top-down the entire time. You need to start communicating the way that people listen. You should lead with the point. You should give them just enough context. And you should go deeper by starting where they are.
I've got another video on communication that goes deeper into the verbal side and how to keep from being anxious while you're talking. It covers how to sound confident, how to stop rambling, and how to hold a room. I'll link to it right here. Go watch that one next.