Your Boss Doesn’t Need the Director’s Cut

You spent three hours figuring out what went wrong. The status update doesn’t need to take the reader through all three.

There’s a particular kind of email you write after spending three hours troubleshooting something. You start with when the problem was reported, explain what you checked, walk through the things you ruled out, and describe the promising idea that turned out to be completely wrong. By the fourth paragraph, the reader knows almost as much about your morning as you do.

They still don’t know whether the website works.

I understand the urge to write that email. When you’ve spent half a day investigating a problem, the sequence feels important. You had good reasons for checking those things. You were methodical. There was a whole stretch where you thought it was the cache, and you would like someone to appreciate why that was a reasonable theory.

Unfortunately, the person who asked for an update probably wasn’t asking for the director’s cut.

Imagine a client emails because their website’s contact form has stopped sending inquiries to the sales team. Visitors can fill it out and get a cheerful confirmation message, but nothing arrives in the inbox. The website is essentially saying “Thank you, we’ll be in touch” on behalf of people who have no idea you exist.

You start investigating. You check the inbox rules, test the form, look through the logs, and try to work out whether yesterday’s update is involved. An hour later, the client asks how it’s going.

So you tell them. All of it. You explain that the form appears to submit correctly, that you’ve ruled out a couple of possible causes, and that you’re looking at how the site hands messages off to the email service. You include the error you found, because it seems relevant and also proves you have located an error.

The client replies, “Are we losing inquiries?”

That can feel irritating when you’ve just written a detailed explanation. You’re trying to keep them informed, and now it seems like they haven’t read it. But look at what you actually sent. You described the investigation. They’re trying to decide whether to pause an advertising campaign that is currently sending people to a broken form.

Knowing that you checked the logs doesn’t help them make that call.

A more useful update might be: “Visitors see a confirmation, but sales isn’t receiving their inquiries. I’m checking whether the site saved them; until we know, some inquiries may be lost. I recommend pausing the ads that lead to this form while we check. I’ll update you by 2 p.m., even if we’re still investigating.”

That gives the client something to do and tells them what remains uncertain. It also saves them from having to guess whether your next email is coming in twenty minutes or sometime after they’ve retired.

The details still matter. Another developer might need the exact error and the sequence of tests so they don’t spend an hour repeating your work. Keep that record. It just serves a different purpose from the email to someone deciding what to do about their advertising budget.

This comes up constantly in technical work because the investigation is where so much of the effort goes. By the time you explain it, you’ve spent hours learning which details matter. Your reader is arriving cold, between other tasks, with a question you may never have answered directly.

It’s worth taking a minute to work out what that question is. They might need to know whether customers are affected, whether a deadline will move, or whether you need their permission to do something disruptive. If you’re unsure, ask what decision they’re trying to make. That’s usually quicker than sending another four paragraphs and hoping one of them helps.

I like a very simple check before sending an update: if someone reads only the first two sentences, what will they know? If the answer is that I started investigating at 9:12 and have been extremely busy since then, I need to rewrite the opening.

And if I don’t know how bad the problem is yet, that belongs near the top too. I can explain what I’ve confirmed, what I’m checking, and when I’ll be back with more. There’s no need to bury the uncertainty under enough technical detail that everyone gets tired and stops asking.

When the client replies to the shorter email with “Okay, ads are paused. Talk at two,” it can feel almost anticlimactic. Three hours of work, a short email, one boring reply.

Then you can close your inbox and get back to finding the missing inquiries, which is probably how you wanted to spend that time anyway.

I cover this in Talking To Your Boss, my book about communicating risk, uncertainty, and status during cyber incidents.