6 tips to write effective project updates as a software engineer

Have you ever had EMs/PMs ask you for a project update, for it to then go unread?

On top of that, once you share it:

– You have to keep sharing it with additional people
– You are asked for a one-liner summary
– You are asked a bunch of additional questions
– You waste a lot of time going back and forth

What if you could write updates that provided all your stakeholders exactly what they needed in one post? 🙋‍♀️🙋‍♂️

👉🏼 A clear summary of where the project is at with additional details available if they want to dive in for additional details.

As I’ve transitioned into a tech lead as a software engineer, and started leading larger projects, I’ve seen how valuable and necessary it is to develop your skills to write clear project updates. ✅

I often give weekly updates to stakeholders when we are working on projects with tight deadlines, lots of moving pieces, or any kind of ambiguity.

It’s super helpful for eng managers and business stakeholders to not have to go into Jira to try and find out where a project is currently at.

Here are some key things to keep in mind when writing project updates.

1. Know who your stakeholders are

I’ve worked on several projects where the key stakeholders were business people. In that scenario, they don’t care about databases or ui components, they want to know when certain features will be ready. Use the language they care about.

If you are providing an update to EMs and other engineers, you can use more technical focused language.

2. Break the project into milestones

We all know about agile software engineering. Where you deliver your project in little chunks, rather than one massive dump truck load at the end of three months.

It’s the same with project updates. Break them into clear milestones. Common milestones for updates might include:

• Sprints

• Product features

• Phases of a project

• Customer releases

Rather than giving one big update for the entire project, break down each milestone of your project and give an update for that milestone.

Here’s an example of breaking a project down into sprint milestones:

This update was for my engineering manager, so I provided more technical details.

3. Provide a tldr; summary

Your stakeholders may not have time to read all the nitty gritty details of your update.

You can really help them by providing a tldr; one sentence summary of where the project is currently at, and if you are still on track or not.

Here is an example of a long running project with several smaller projects running concurrently.

Notice the summary at the top of the update to ensure stakeholders the project was still on track.

Side note: working overtime to hit a deadline is not optimal or healthy… for this particular project it was just the reality we found ourselves in, so I wanted to surface that to our business stakeholders.

4. Raise awareness when you hit blockers

If a project is running off the rails or taking longer than expected, don’t hide that.

Raise the alarm quickly and provide ideas for getting around said blockers so that your manager or other stakeholders can make a decision quickly to make sure the project is still successful with the various levers at their disposal. eg.

• add more resources

• cut scope

• move the project deadline

Good managers will always appreciate honesty and visibility into the project status, even if it’s off track.

You can really help them by not only raising blockers, but bringing potential solutions as well. 💡

5. Use bullet point format for updates

Long paragraphs of text are very hard to digest.

Breaking things down into headings for the main sections, with bullet points for the details really helps people digest your updates.

Here‘s an example of converting a multiple paragraph update into a bullet point format. Notice how much more readable and clear it is!

Which would you rather read? 🤔

6. Make sure you mention/include appropriate stakeholders

Be sure to post your update where your identified stakeholders can read your update. Directly mention specific people you want to make sure don’t miss your update – eg., your EM and/or PM.

As a general rule, including more people in your update is better than missing someone who needs to know about it.

However, don’t include everyone in the company or you start to just become noise. 🤪

- - - - - - - - - - - - - - - - - - - - - - - - - - - -

What about you – have you had to write project updates as a software engineer?

I’d love to hear any stories or tips you have.

Until next week 👇🏼

Catch me daily on LinkedIn and Twitter, where I talk about everything software engineering, startups, and growing in your engineering soft skills.