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

I’d been trying to reach this client for a few days. When I finally got him on the phone, I started confirming some of the information my senior engineer had sent him weeks earlier. What came back wasn’t agreement. It wasn’t pushback. It was silence. And that silence told me everything before he said a word.

The information had been sent. None of it had landed. The conversation I thought I was about to have with him was nowhere near the one that actually unfolded.

We’d kicked off the project about 16 months earlier. I was the PM, but I’d handed the day-to-day client communication to my senior engineer. He was very thorough and the client liked him. He was sending updates and the client wasn’t responding. He read that as fine. I read that as fine. How many people hit reply instead of reply all? But nobody picked up the phone to check.

16 months. Dozens of natural moments where one call would have surfaced the gap, would have exposed that missing piece. None of them happened.

In hindsight, here’s what I missed. On a 16 month project, no news is never good news. Best case scenario, no news is no news. Worst case, you’ve got a problem brewing that you’re not even seeing yet. It’s not patience. It’s avoidance dressed up as professionalism.

Most engineers operate on a transmission model of communication. You send, therefore you’ve communicated. That works fine for technical artifacts. A drawing exists or it doesn’t. There’s no such thing as a Schrödinger drawing. A spec is delivered or it isn’t. But communication with people who have to act on the information isn’t a transmission. It needs to be a confirmed receipt. Until the other person can play back what changed, nothing has been communicated. It’s merely been filed.

We don’t operate this way in technical work. We don’t ship a design without a review. We don’t release software without a test. But we’ll send a 13 page email with a budget overrun on page 13 and call that communication.

When I went back through the record, I found the new timeline communicated. I found that the budget overrun had been identified. Both of them were there, both technically delivered. Page 13 of an email that also had photos, findings, observations, and a hodgepodge of context. The information existed. It just wasn’t extractable, at least not without a significant mining expedition.

And here’s the trap on that one. In technical work, volume feels like rigor. More context protects you because the receiver is expected to do the extraction work. That’s the deal. They’re reviewing it. They’re working through it. Client communication doesn’t work that way though. The receiver isn’t extracting, they’re scanning. Burying the critical information in volume isn’t rigor. It’s hiding behind it.

So we’d started the call with some small talk, catching up, you know, standard rapport building. Then I brought up the additional funding required to complete the work. There was genuine shock. The project was late, not complete, and needed more money. And he was hearing all three of these for the first time. The small talk turned to a firestorm in under a minute. President of the firm had to get involved. Commitments were made and the project will close.

I don’t think this client will ever come back though. 16 months of work gone because nobody confirmed receipt. And I own that one. I was the PM. I’d been reading the silence as agreement for over a year. Reports back from my engineer were that everything was great and that he’d talked to the client. I didn’t confirm that. The escalation didn’t just cost the relationship. It told everyone watching, internally and externally, that nobody on our side had been checking whether any of this was landing.

So here’s what changes. Email is the record. The phone call, that’s the communication. Anything that changes scope, cost, or timeline gets that call. And on that call, you name the change directly. Then you ask the other person to play back what they heard. If they can’t, it didn’t land, and you stay on the call until it does.

Three steps. Call, name the change, confirm the receipt. Most engineers hate this protocol because it surfaces disagreement early. That feels like creating a problem. It’s not. It’s exposing a problem that already exists while it’s still cheap to fix.

The version of this conversation I had to have with my client at month 16 would have taken 10 minutes at month four. It would have been awkward. He might have pushed back. We might have negotiated. Instead, I avoided it for a year and then it cost me the client.

You don’t get credit for sending it. You get credit for it landing.

Now the hardest version of this is communicating before you have the full picture, when you don’t actually know yet what the answer is. That’s its own problem. That’s where we’re going next.