This transcript was produced by robots and left as-is. Accuracy and elegance are not guaranteed.

The last few episodes were about relationships and visibility. The last one closed on making your work legible to the people who route decisions, recognition and opportunity. But visibility is necessary, not sufficient. If people can see your work and can’t use what you hand them, visibility has done its job and nothing else has. So these next few episodes are about what happens after they’re looking, after you’ve got their attention and you’ve gained that visibility, whether what they see is something they can actually use. And today, we’re starting with one of the most common places this breaks down. When you answer a question nobody asked.

Picture this. Somebody asks you something. Yes, you know the answer. You also know the context around the answer, the caveats, the edge cases, the history, all the gory details. And to understand the answer properly, you feel that context is required. So you give them all of it. You open the fire hose, not to show off. It’s just that leaving something out feels wrong.

This is a typical engineering instinct. It’s correct and required for the rigor of design reviews, drawings, specifications. Detail is the language in that context and is absolutely required. But in leadership, that same instinct is a problem. Here’s why. The person who asked the question wasn’t requesting a briefing. They’re trying to make a decision. When you deliver more than they asked for, you don’t look thorough. You look like someone who can’t tell what matters from what doesn’t. The actual answer, the one they needed, is now buried somewhere in your response, and they have to extract it. If they have to extract the signal, you didn’t communicate it. You delivered a file.

I had this happen years ago with one of my direct reports. Technically brilliant man, a walking Wikipedia knew more about more than I’ll ever legitimately understand. And he was not afraid to share it, whether you wanted it or not. I’d ask him a question and I’d have to wade through piles of details to extract the signal. Sometimes halfway through the explanation, I’d forgotten what I’d even asked.

Now the context of the relationship was that I was doing business development and sales. I was interacting with clients and finding solutions. I needed to know what was technically feasible versus what the client was dreaming up. I didn’t want to sell something the technical team couldn’t actually execute. But for the longest time, I couldn’t get a straight answer. So I had to make a change. I got to the point where when I’d ask him a question, I would stop him. I’d say stop. This is a yes or no answer. When I need the details, I’ll ask. Can we do this or not?

Well, initially, his reaction was a little bit sulky, but I would get the yes or no. And I always knew that I could come back for the details if I needed them. And those times when I did, it’s definitely something that made his day, letting him exude his knowledge and bury me in details. Now from his perspective, he wanted to provide the context. But in that moment, the only thing I needed was the yes or no. In that case, completeness wasn’t the goal. The right level of detail was. And this is common.

Now, yes, it feels like dumbing down your answer, but it isn’t. It’s a different design target. You’re tailoring the answer to what the receiver actually needs, not what you think you need to deliver. The precision is still there. It’s held in reserve, ready if they ask. It’s just not the default output.

This is where engineers tend to resist. And there’s two reasons. First, if you leave something out and they needed it, you look unprepared, or at least you feel like you do. That’s just plain wrong. Delivering what they asked for at the level they asked for it is the most rigorous thing you can do. You have to know the full picture to strip it down correctly. That takes more work, not less. Second, giving less feels less professional, less rigorous. That’s also wrong. Lincoln supposedly said if he had six hours to cut down a tree, he’d spend the first four sharpening the ax. Pascal supposedly said if he’d had more time, he’d have written a shorter letter. Neither actually said those things, but the point holds. Stripping it down properly is a skill. It takes more work, not less.

So here’s the active move. Before your next significant response, spoken or written, pause and ask one question. What decision is this person actually trying to make? Then, design your answer for that decision. Not for the full context of what you know, not for what you think they need to know, but for the decision they’re trying to make. If they need more, they’ll ask, and you’ll be ready. Your job is to make it easy for them, not to front load everything and force them to sift through the details to find their answer.

Today was the real-time version. It’s the meeting, the hallway chat, that quick question, the moment where you at least get to read the room and course correct. This is where you can notice glazed over eyes. And a quick hint, those glazed eyes don’t mean they want more data. They mean they need less. Next episode, we’ll talk about the same failure mode, but in writing where there’s no course correction, where the document sits on someone’s desk or in someone’s inbox and either works or it doesn’t. It is read or it’s ignored. Information that exists but can’t be extracted hasn’t been communicated. It’s been filed.