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

A client asked a simple question. What does this cost in dollars? The project manager kept answering in hours. Not because he was hiding anything, not because he did not know, because he was still speaking engineer in a room that had moved on.

We were in a project update meeting. A scope change had come up and the PM was walking the client through the added hours and the reasoning behind them.

The client stopped him and said, in effect, I do not work in hours. I work in dollars. I do not know your rates. How much will it cost? And the PM still kept coming back to hours. Finally, a senior leader in the room stepped in and translated the issue into what the client actually needed. Cost impact, schedule impact, and the decision in front of them. The room settled down almost immediately.

That is the pattern. The problem was not the analysis. The problem was the currency. He had the right information, but he was presenting it in the wrong unit for that room. And this shows up all the time. An engineer talks to another engineer and assumes they want every layer of the logic, when really, they just want the answer at the right level. An engineer presents to a client and leads with technical mechanics when the client is trying to understand cost, downtime, risk, or production impact. An engineer presents to a senior leader and walks through the plumbing of the issue, while the person across the table is really asking one question. What does this mean for us?

That’s the shift. Same issue, same facts, different room, different job. Engineers are trained to think precision lives in the underlying variables. The hours, the assumptions, the calculations, the mechanics.

And in technical work, that makes perfect sense. If you’re reviewing a design, troubleshooting a problem, or defending an approach, the pieces underneath the answer matter a lot. But once you move into client conversations, stakeholder meetings, and higher level decisions, precision has another job to do. It has to make the consequence clear. What changed? What will it cost? What will it delay? What risk does it create? What do you recommend?

If you answer in the wrong unit, you do not sound more rigorous. You sound harder to use. That’s the part engineers usually miss. They think, well, I’m being thorough. The other person is thinking, I still don’t know what this means for me.

And that gap matters because in rooms like this, people are usually not grading your explanation the way an engineering professor would. They’re not asking whether your breakdown was elegant. They’re not asking whether you thought hard enough. They’re asking whether you can help them make a good decision. That is what they hired you for. Not just to know the technical answer, but to translate it. And that translation is not fluff. It’s not dumbing it down. It is not playing politics. It’s part of the job. Actually, it is a bigger part of the job than most engineers realize.

Because the more senior the room gets, the less people need to know your workings and the more they need to know your judgment. So here’s a simple question to ask before you speak in the next important meeting. What currency does this room need? Not what currency makes the most sense to me. What currency does this room need?

Because every room has one. Internally, it might be hours, effort, resourcing, or technical feasibility. For a client, it may be dollars, timeline, and disruption. For operations, it may be downtime, production loss, reliability, or risk to the plant. For senior leadership, it is often exposure, trade-offs, recommendation, and consequence. Same issue, different currency. And if you don’t translate it, you force the other person to do the conversion work themselves. And that’s a bad bargain. If they have to convert your answer before they can use it, you’re making them do your job.

So here’s a simple structure you can use. Three parts: impact, exposure, recommendation. First, impact. What changed for them? Not the full backstory, not the whole engineering chain. What changed that they actually need to know? Second, exposure. What does this affect? Cost, risk, delay, downtime, production, consequence, and what happens if nothing gets decided? And third, recommendation. What should happen next? Not just, here’s the issue. Here is the issue and here is my recommendation. That last part matters. Because people don’t just need information. They need decision support.

Now, supporting details still matter, absolutely. But they stay in reserve unless asked for. That’s not a loss of rigor. That is disciplined communication. The rigor is still there. You’re just not dumping it on the table by default.

Let me show you the contrast. The weaker version sounds like this. We need another 60 engineering hours because the scope expanded around the controls integration. Now, technically that may be completely true. It may even be the right internal framing, but it’s weak in that room because the stakeholder still has to do the translation. What does that cost? What does that delay? Why should I care?

A stronger version sounds like this. The added scope will require about $9,000 more and will push completion by roughly one week. The main driver is the expanded controls integration work. I recommend we approve it now rather than absorb that delay later.

Same issue, same facts, different currency. And notice what happened there. The technical basis did not disappear. It just got compressed into something decision-ready. That’s the move. And once you start seeing this, you’ll notice it everywhere. Meetings that drag because nobody translated the impact. Clients pushing back because they’re being given engineering input instead of business consequences. Stakeholders losing confidence, not because the engineer is wrong, but because the engineer keeps answering in the unit that makes sense to the engineer.

That is why the title of this episode is The Room Changed. Did You? Because a lot of engineers do not update their communication when the room changes. They carry the same operating mode into every conversation. Same level of detail, same sequence, same logic chain, same currency. And then they wonder why the message is not landing.

The room changed, the job changed. The answer needed to change with it. So here’s the question I’ll leave you with. When you explain something important, are you answering in the unit that makes sense to you, or in the unit that the other person needs in order to decide?

Because if you keep using the wrong signal in the wrong rooms, people build a model of you from that. And that model will not be technically brilliant. It will be hard to use. And that is a much more expensive problem than most engineers realize.

In the next episode, we’re going to zoom out one more level because this is not just about one meeting or one answer. Over time, people build a picture of you from repeated signals. And if you’re not designing those signals deliberately, that picture gets built from whatever leaks through. And that is where we’re going next.