On Bad Status Updates

Every Friday afternoon, I get a terrible status update email from the Seattle Department of Transportation (SDOT). These emails are so bad, in fact, I am compelled to write this article about bad status updates and how to avoid sending them.

For those who don’t know, West Seattle has essentially been an island since Spring of 2020, due to the West Seattle Bridge being closed for repairs. “Luckily” this coincided with the beginning of the Pandemic, and subsequently a reduction in the need for daily commutes, but has still been a pain in the ass of thousands of residents (myself included).

Here is the table of contents from the offending email:

SDOT Email Table of Contents

I care about exactly zero of these bullet points. You know what I do care about?

WHEN THE F$*& IS IT GOING TO BE DONE?!?

And yet, there’s nothing about a target completion date and how we’re doing against that date. They go on and on about how things are being done, but nothing about when. They even provide a cute little chart, which also manages to tell me nothing useful — but this time in a visual format!

And maybe the worst part about this email is this: there’s a link to a page that has slightly different information, which actually does contain a target date buried toward the bottom of the page. I mean, what kind of clown sends useless status updates like this?

Actually, wait… the real worst part is that it reminds me I am the kind of clown who sends useless status updates like this. Throughout my career as a PM, I have absolutely sent (and still sometimes send) status updates with a bunch of filler that no one cares about, while avoiding the actual content people care about (LIKE DATES!).

So, why do I (and other PMs) send bad and/or useless status updates?

I mean, we all know this is a problem and yet we keep doing it. There have to be good reasons for this, right? Well… yeah. While occasionally it may just be an inexperienced PM not giving the people what they want, it’s generally to avoid delivering bad news.

Here are the common permutations of this avoidance I can think of, along with some advice (for you and for myself) on how to do better.

I have no idea when the project / next milestone will be done

When a project is in flight, a PM will generally know when it will be done (or at least will know what the schedule says), but sometimes there is just not enough information to predict the delivery date. This isn’t necessarily bad or good — especially in an agile environment. A “done” date for a suite of features that your PM calls a “project” just isn’t feasible (or reasonable) to calculate at the beginning of development cycles.

We’ve all been burned by giving dates when they’re just a guess, so we avoid committing to them until we actually have a good idea of when it’ll be done or, in unfortunate cases, we are coerced into throwing a date out there.

Advice: this is where being transparent is helpful — you should call out that this is a known-unknown, and you’ll publish a date when one is available.

I sorta have an idea of when the project / next milestone will be done, and it’s not looking good, but I haven’t exhausted all my options to fix it yet and don’t want to cause panic

We’ve also all been burned by the question “… and what are you going to do about it?” when we report a problem without potential solutions. One of the first lessons a PM should learn is to always tie the reporting and escalation of a problem with:

1. The reason(s) why it happened
2. What you’ve done to fix it so far
3. What the mitigation plans are (or next steps to figure them out)

If you’re between steps 1 and 2 above, it’s reasonable to hesitate before sounding the alarm when it might be a non-issue. More importantly, you don’t want to cause more work for yourself and the team by answering panicked questions instead of, you know, working on the mitigation plan or the fix.

Advice: In the cases above, I suggest having offline conversations with your manager/director to give them the heads up that you’re on it. If they trust you, they’ll generally either get out of the way or ask if they can help without doing more harm than good. If you’re a manager/director reading this, foster an environment where this candor is possible and be prepared to provide cover while the plans are adjusted.

(Did I just kick the vague status problem up the chain? Absolutely, I did.)

It’s bad news, but reporting it would make the team look bad and I don’t want to throw anyone under the bus and/or ruin relationships

This one is tricky, and frustrating. Being a PM is a social, high EQ job. You can’t just yell at or fire people when they’re not doing what you want them to, and you generally can’t step in and just do it yourself.

Sometimes the team did their best and couldn’t hit the goal — remember, sometimes deadlines were never feasible to begin with. But, yeah, other times the team just underperformed. Either way, it’s never a good idea to blame your team in public; it’s a bad look and it doesn’t work.

Advice: First, take steps to avoid this situation. Interrogate the plan you created to make sure the deadline was reasonable, knowing what you know now, and adjust accordingly — then publish that update.

Next, if the team is actually underperforming, there are parallel paths to take:

1. Feedback: Provide the team feedback in the form of quick check-ins (two-week sprints in software development are helpful for this) and metrics about how they’re performing against the plan. It could be that they don’t know they’re falling behind or what is expected of them. If you suspect a personnel problem and you have a decent relationship with them, grab coffee and chat about it. If necessary, talk to their boss about your concerns and see if you can help.
2. Messaging: Use accurate, but blameless language in your status updates. We are behind as a team due to falling short of n-metrics.

It’s bad news, but reporting it would make management look bad and I don’t want to be inflammatory and/or get fired

This is pretty hard. Sometimes situations are out of our control due to decisions made above our heads, and yet we’re responsible for delivering the message. Blaming a leader, regardless of whether they are directly above you or in another department, in front of their peers is a career-limiting move.

Advice: Uhhh… good luck?

Seriously, though, have a tough conversation with the people this might affect and ask them for advice on how to message. If you can help them identify and address the problem, they will (or should) value that feedback. If you can’t do this, you might want to get out while you can.

What’s not on the list that I think is worth calling out?

I’m scared to say when I screw up

I’d wager this is rarely the reason why statuses are vague. A PM worth their salt will own their mistakes in a public forum. There’s a good, primary reason for this, and a subtle, secondary reason for this.

1. Good reason: It’s the right thing to do. It shows you’re ethical and willing to own your mistakes (again, this should come with a plan on how to fix it and/or a promise of a post-mortem, if applicable).
2. Subtle reason: When you have consistently and publicly owned when a problem is your fault, then the next time a problem comes up and you don’t attribute blame anywhere, people will assume it’s not your fault.

There’s bad news, but we have a plan to fix it

One of the things that brings me joy as a PM is the ability to report a problem that is on track to be solved. If I can deliver the “the team encountered a problem, but we’re on track to crushing it — stand by for date updates” it means I’m doing my job as a PM. The true work isn’t creating a perfect plan that goes off without a hitch — it’s getting a plan together fix the inevitable problems when they occur.

Final Thoughts

1. Bad status updates hurt more than they help. No news, when news is expected, is actually worse than bad news
2. Be brave in your willingness to deliver the truth
3. They really gotta fix that damn bridge soon

Kayvon Ghaffari is some guy whose article you just skimmed