The Update You Don't Want to Send

You promised an update at three. It's nearly three, and the problem is still a problem.

Suppose you've told your boss you'll have an update at three. You're working through a problem with a website, and when you made that promise, three sounded comfortably far away. Plenty of time to find something useful.

It's now 2:58. You've checked several things, none of which fixed it. You have a new idea that might help, though, and sending an update right now would mean telling your boss that the website remains impressively committed to being broken.

So you give yourself another ten minutes.

This feels reasonable from your side of the screen. You're working, you've narrowed things down, and you'd rather send a useful answer than announce that you're still at your desk. If this next test works, you can send good news instead. Surely everybody would prefer that.

At 3:12, your boss messages you. A minute later, someone from the account team asks whether there's anything they can tell the client. You start answering both, lose your place in the test, and become annoyed that people keep interrupting you while you're trying to fix their problem. They had been told they'd hear from you at three.

From their side, the missed update is new information. The last thing they knew was that you were investigating and would report back at a particular time. Now that time has passed. They don't know whether you're close to a fix, completely stuck, or dealing with something worse. They might also have repeated your promised time to someone else, who is now asking them where the update is.

You don't need a breakthrough to clear up that part. You can say the problem is still present, what you've checked, and what you're trying next. You can also say that you don't yet have a reliable estimate for the fix. None of that makes the technical problem disappear, but it gives the people waiting an account of what's happening.

In this example, a short message could be enough: "The form still isn't sending confirmations. We've ruled out the settings we checked and are testing the connection to the email service next. I don't have a fix time yet. I'll update you again at four, sooner if the situation changes."

It isn't an especially satisfying message to write. There is no triumphant last sentence. But the account team can work with it, and your boss doesn't have to decide whether your silence needs investigating.

The time on that message is a promise about communication. You can keep it even when you can't predict how long the technical work will take. That distinction is useful when someone asks for a completion time you don't have. You can give them a time for the next assessment without pretending the answer will be ready by then.

Of course, sending the same vague sentence every hour won't help much either. If you're waiting on something, say what it is. If a test ruled out an explanation, say that without presenting it as a fix. And if the situation has become stable enough that less frequent updates would make sense, agree on a new schedule. Otherwise, people are left to discover the change by waiting for a message that doesn't arrive.

There are also things that shouldn't wait for the next scheduled update. If you discover that the problem affects more customers than you thought, or a commitment is going to slip, the person making decisions from your earlier message needs to know. A schedule should make routine communication predictable, not give important information somewhere to sit until four.

Back at 2:58, the new idea can still be worth testing. Send the short update, then try it. If it works at 3:07, you get to send the good news nine minutes later.

And if it doesn't work, you've already done one thing you said you would do. You can keep investigating without also having to explain where you've been.

I cover update timing and communication under pressure in Talking To Your Boss.