How to share status updates

“Sharing status” is a common workplace term for communicating project progress. This progress allows for better collaboration and understanding in the workplace. Effective communication allows for effective project management and delivery, yielding effective company and career outcomes when planned correctly.

This blog post is meant to help developers and managers make project status updates so that teams succeed in their projects and make grantable requests, such as setting up a new server or being recognized for the completed work.

What is in a status update?

A typical status update includes work completed, to be completed, and any upcoming concerns. For new projects, a status update will sometime include an overview of the project, project timelines, the stakeholders, and the target outcomes. Regardless of the project, your goal in sharing a status update is to relate the project tasks to the goals familiar to the target audience. If your target audience knows nothing about the project, you’ll need to provide an overview. If your target audience needs to contribute to the project, they should have enough context to contribute to their portion of the solution.

For this blog post, we’ll focus on regular status updates. I’ll include a few status updates I provided this past week on behalf of my team.

This week we eliminated edge cases in commerce inventory labeling by integrating the OpenAiIs Curie model into the Purchase Intent Model training. Previously they were anywhere from 10–20 items that were not getting classified (of the 5000 commerce items used for training) due to limited context/knowledge available. Curie provides an underlying knowledge graph of products like “SnoreRx,” allowing the model to classify and understand commerce activity on a vast set of inventory that may require industry (in this case, medical) knowledge.

We’re currently blocked on the project since we’re awaiting availability from the ____ team to integrate the Purchase Intent Model into ____.

In this example, I bounded my status update to a time frame, shared what happened, and then shared the work’s impact. When I discuss the impact of the work, I frame it in a sentence concerning the before and after of the system. Previously, we had this bottleneck and solved this problem with this solution. Sometimes you’ll have to share the status of a project with an incomplete approach or solution, and that’s when you’ll share what you’re going to be doing next.

We performing some preliminary engineering work to auto-scale the ____ service for increased traffic, coming in the next few weeks.

I included an example of a shorter status update. Depending on your role and who you’re talking to, you may want to go into further detail to discuss the engineering approach. I tailor the level of detail based on the situation and time duration of a conversation. For example, some details are better left in a technical deep dive versus a short 15-minute call.

Data engineering-wise, we’re putting the final touches on the migration of ____ data jobs out of the _____ system.

If you’re working on smaller projects that are not time bounded, you can also bound status updates to domains of work, like data engineering. Sometimes, it’s a good idea to bind a status update to a domain of work when making requests to other teams.

How do I share a status update?

Aside from verbal communication during meetings or discussions, structured written updates can be another form of sharing status. When sharing this, you can decide the length and detail. For example, my team has multiple joint projects and stakeholders, so I use written updates to avoid wasting time in one-off meetings with various stakeholders who need the same information. In this written outline, I share key themes, accomplishments, upcoming themes, impediments, and open questions.

This example contains all the work done by my team. Ideally, this outline serves as a more extensive outline that gets filtered for relevancy and sent out to specific stakeholders.

Effective Strategies for Gathering the Details

The common challenge in sharing status at work is gathering details. Even if you know how to construct a good status update, you may not have all the details to speak to every possible stakeholder, scenario, and need. I’ll share some strategies for this since this is normal.

The first is consistently include other people on my team in conversations where they may be able to add more context to the conversation. This is delegating, and it’s a skill that gets better with time as you understand the roles that are part of work projects. I still get this wrong, and that’s okay, especially since it’s not one person’s responsibility to understand the roles of a project or to fill those gaps. Even if you had all the people and understanding, delegating requires trustworthy, collaborative, and effective team members.

The second strategy is to leverage conversations and match your status updates effectively to who you are speaking to and who you may be speaking to. If you’re in a meeting and someone is discussing work items, ensure to index and ask questions with the expectation that you’ll need to share status on the topic later. If you’re a manager, the range of topics is wider than the range for the individual contributors and developers on your team. If you’re a director, VP, or CTO, the range of topics is even wider. Different people like to operate with context to different ranges. Be aware of this. Most engineers and developers interact with other engineers and developers, and so many effective engineers ask questions about the implementation, tooling, and approach of the work. It fits, and it works. If you’re the only engineer in a company, your conversations and questions will differ.

And the last strategy is the confirm and affirm. It’s great if you can come into work with the assumption of “good intent” that everyone here is ready to make the project succeed. It doesn’t happen every time, and even on good teams, communication can be weird sometimes. If you’re reading this and spending time and effort to represent and advocate for the success of your project, share it with others. Share it with your team, and share it with your team members. I like to send snippets and screenshots of my updates because it shows that I’m proud of our work. I also often communicate the themes in planning meetings with my team. I find that they can quickly affirm, enhance, or correct the thoughts that I have and how I speak about the projects. If the project details inspire the people I trust, it’s inspiring beyond that circle of people, and I’ve confirmed it.

Summary

That’s everything that I wanted to share about status updates for now! I hope that it was useful to anyone wanting to understand the nature of workplace projects and how to stand out a bit more through some effective strategies. I shared some examples of how and why I do share project status updates. Catch you in the next blog!