Today is the 25th anniversary of Bob Ross passing away. I watch The Joy of Painting pretty often as it's one of my favorite ways to relax. Among the many important life lessons that Bob shares, there is one that is especially relevant to me. Learn how to use your tools. I also appreciate how much Bob is able to communicate what he's doing as he works. In that spirit, I want to talk about a particular communication tool. There is no more important tool in your toolkit than the status update.
A good status update inspires confidence in the work being done. A good status update keeps other people from constantly pinging you and your team with questions. A good status update will save you time in unnecessary meetings. And yet too many people never learn how to write a good status update. Most organizations default to a meeting culture because we expect a status update to be bad or non-existent. My goal is to share some tips for good status updates in the hopes it saves you time in the future.
A status update can be about anything that requires coordination or accountability on a team. It could be for a long or short running project. It could be during an incident or outage. It can be for a hiring process or team event. It can be for anything where the results of the work are interesting to others less aware or not actively involved.
First, it’s important to explain why you’re giving this update. The right context sets up the rest of the update to be read and understood accurately. There are a few tactics but my personal favorite is to include a quick section at the top. Something of the form:
Goal: Ship the widget builder 2.0 so that users can start building mini-widgets Timeline: ETA July 1 Status: On Track
That’s about 20 words but it conveys so much information to the reader. They now understand the context, a frame of reference for other dates in the update, and whether they should be concerned because of the status.
A good status update is shared at the right cadence. When you're thinking about how often to send the update out, consider a few of the questions. How often does new information surface? How often do engineers complete work and move to new work? When are your stakeholders required to give their status updates up the chain of command? Are there any dependencies that would enjoy an update at a particular time? For example, what if there is another team that prioritizes work at a certain cadence? Would it make sense to share a status update at a time where they can use that update to change their own work-in-progress?
Once you understand what the best cadence for updates is, send it slightly earlier. Keep your team from waiting for your update and have it in front of their eyes the moment they are ready to think about it. Often times a good status update will come in the morning to start your day or evening to end your day. Sometimes you can include the next update time in the current update. For example, if this a status update for an ongoing incident, it might be important to convey the status and say something like “next update one hour”. That way your stakeholders won’t be interrupting your work. They'll know that the next time there will be meaningful information is in an hour.
If a status update is shared but no one knows it exists, is it really useful? Make sure the update is shared in a predictable place like a public Slack channel or emailed to a specific list of people. The status update should exist beyond the moment you share it. That means sharing a status update in an ephemeral place like a zoom chat is not a good practice. Similarly, using a resource that is hard to discover like a private google doc can be problematic (though this depends on context). The location should allow for reading the status update asynchronously.
A status update should be short enough that it’s easily digestible by someone who doesn’t have enough time to understand all the complexities. That’s why a layered approach can be handy. In the layered approach, the main status update is shared in a public place that is very visible. Then it has links to other sources of information that may be able to answer more in-depth questions. You might share that the widget builder is to enable virtual widgets and then add a link that explains what a virtual widget is. Most of the folks reading will likely know what a virtual widget is. This allows a stakeholder who might be less involved to pull the information at will.
I strongly believe that all work should be owned by one person and that person handles the status update. This also implies that the owner is keeping tabs on all work so that they can give a status update. This person may not be the one doing all the work but they’ve had a strong hand in planning and will ultimately be accountable for the success of the project. This doesn’t have to be a formal leader with a formal title. Anyone can own a project and anyone can the leader on a project. Getting good at giving a status update is an important skill for a junior person to grow into a formal leader.
The audience of the status update is anyone who may need to know something about the project now or in the future. Unless there is a reason why the information should not be circulated, it’s better to bias towards over-sharing than under-sharing. Often times, a status update can trigger a thought in a person who might not have been part of planning. It can lead to exposing new risks or work that might be unnecessary. It’s not always necessary but I like having defined groups to make it easier for each update. Instead of typing out 30 names in an email, send it to firstname.lastname@example.org and you won’t need to worry about missing someone.
This also leads to an important by-product of the status update. Celebrating individual hard at work completing tasks. This is a great place to show appreciation and shout out someone who hit their milestone. It can be for anyone that did something important for the success of the project. Don’t overdo it or seem artificial. Just add a small note so that others can appreciate their work as well. Giving someone praise and credit in public is one of the easiest and most important parts of leadership.
So here’s where we get to the meat and potatoes of the update. What do you put in it? We added a first part that explains why this update is happening. Implicitly the sender and the audience comprise our second piece of information. Now we need to fill out the content.
I prefer a line item for each task being worked on of the form:
What needs to happen - Who owns it - Current status - (Optional) When does it need to get done with (Optional) risks
Here’s a more concrete example with weird formatting to emphasize the point (in reality I’d make it more human-readable).
Build the widget marketing page - @Bob - In-Progress - Likely will be ready for QA on Monday if we get the theme from Design by Friday
That one sentence is enough for everyone to understand this particular task's status. Also, I’d add a link to the ticket itself with more information and potentially a visual marker of the form green/yellow/red for confidence or status. But, you’ll want to limit how much visual treatment you add to keep it from being overwhelming. If the update is long, you might want to split it into sections either by status, by person, or by milestone. It often depends on the project itself and what is visually easiest to understand.
When it comes to dates, you want to be very conservative when giving time and risk estimates. Don’t use the status update to commit to any work or times without consulting the team first. You want to avoid having the person doing the work comment publicly that the timeline doesn’t make sense. It is detrimental to the confidence of your stakeholders if you appear not to be speaking for the team.
You’ll also want to highlight certain tasks that are either going off track or have significant risk. Stakeholders should be directed towards those items because they are the most important for them to understand. It’s critical to point out which parts of the update are significant because of new information or risks discovered since the last update.
Finally, the update is a great place to add the next steps section. This section will let your stakeholders understand what is being planned and where this project is headed. It is often the most important section left out of the project. It's also the most likely information you’ll get pinged about in private.
(See what I did there)
Hopefully, this has been helpful in giving you some suggestions on how to give your own status updates. There are many other helpful techniques I haven’t included here but could be of value to your team. The most important take-away is not how to write a perfect status update but to give one. Over time, you’ll refine your own practices as new questions arise that you haven’t been able to answer. You’ll also start training your stakeholders to expect an update instead of going to you or someone else every time. This will translate to less meetings, more focused work time for you and others, and a happier team.