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?

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?

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 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

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tiffany Jachja

Software engineering manager covering topics on software, personal development, and career.