How to level up your weekly reports
A forcing function to think
Has your manager asked you for weekly reports? Do you have a clear idea how to write them? If you want to level up your reports and get another perspective you have come to the right place.
This article is for engineering managers who want to improve their communication, work more effectively with their peers and become great with managing their own manager. I will share principles, give examples and practical guidance that I’ve learned along the way.
As an engineering manager, you probably have a technical background. Writing reports and writing code share interesting commonalities. They both act as a forcing function to think first. Written communication, like good code, is also reusable. You can go back in time and remind yourself of a topic or forward a document to help someone onboard.
Sharing information effectively becomes harder in a growing organization. The number of Slack messages, emails and news increases, and it is time-consuming to stay on top of everything. Therefore, every manager can invest a bit of their time to write a report that saves others from missing out on key information, as well as explaining context.
The weekly report can be written with different audiences in mind. This post focuses on your first team, e.g. your manager and peers. You can apply it to others too.
What your manager expects in your report
As a manager of managers I expect to find answers to the following questions:
- What value did we deliver?
- How is the work contributing to the wider goals of the department / company / business?
- Are we on track? If not, what are we doing to get back on track?
- Did we learn something new? Do we need to change course?
- What is the progress? How are we measuring it?
- What are the risks? If plan A does not work, what do we do?
- How can I dive deeper? What documents can I read?
- …And last but not least: How can I support you?
You can use this as a checklist when reviewing your report.
Principles for effective weekly reports
The value of reports increased when managers followed a set of principles:
Proof of value (outcome) over proof of work (output)
When you start writing your report, you’ll probably first think about what you’ve done last week. This is a good starting point, however it’s secondary. Proof of work is not what counts. What counts is the outcomes you have achieved with your team. That is your proof of value. An example for proof of work without value is implementing a feature that no customer uses. You want to maximize outcome, while minimizing output. The outcome has priority.
Eventually you will be measured by the outcomes you achieve and not the output you produce. It’s OK to start with the output and connect it to the outcome in the beginning. Once you get better, this will flip and you’ll start thinking about outcomes first. Then you’ll notice that there are multiple ways to achieve the outcome. Proof of work will not be that important anymore.
Brevity and high information density
Writing a report is not the transcription of speech into text. Be concise and precise in your use of words and focus on the gist. Examine every word and check whether it’s adding value—if not, remove it. You don’t need to write full sentences. Use bullet points to support your structure. Minimize the amount of words and maximize information. It’s likely that you are able to reduce your report by half while increasing information.
Let data speak about progress, not you
When highlighting progress, whether it’s outcome or output, try having data speak for itself. Writing “X is going well / on track” has low information density as long as you don’t have the meaning of “well / on track” exactly defined. It’s better to share KPIs and metrics and let them speak for themselves. Readers can interpret and judge themselves. If you think the team is not on track, you will add mitigations, which will show your judgment on the numbers.
More useful tips
The above three principles will bring you quite far. Here are some more tips to make your report even better.
Context is king
Remember to share enough context. Context is important to understand data. You will know the background of everything you write. Your manager and peers do not have the same perspective. Make it easy for them to understand what you are talking about.
Call out risks early / calls for support
If things are not on track and you need support, call it out. The earlier the better. Early awareness from your manager and peers will allow you to better mitigate risk.
Link references
If it’s possible to deep dive on a topic, include links to dashboards, docs and other references. This could be a decision document, a KPI dashboard or a Slack thread.
Share learnings
Make sure to surface learnings and share them with others. Plans are great. But if you stick with a plan for a long time, it also means that you have not learned anything that will adjust the plan. Your learnings can be important for other teams.
Examples of Weekly Reports
Let's take a look at a few excerpts of reports you might send as an engineering manager and how to make them better.
Example 1
Last week in our team we worked on rewriting the microservice from Java to Typescript. Making good progress. Probably done soon.
Last week: It’s clear from the context since it’s a weekly report.
In our team: We can assume this, too.
we worked on: It’s better to use the verb directly, e.g. only use rewrite
Making good progress: This is great, but doesn’t tell a lot.
Probably done soon: We can be more specific.
Better:
Increase maintainability of the legacy payment service
- Only 1/5 engineers has Java skills, support company-wide shift towards unified language
- 82% of classes rewritten from Java to Typescript
- Expected to finish next week
Example 2
We introduced quality metrics and want to check them every 2 weeks.
Links to references and dashboard are underlined.
Better:
Increase quality monitoring
- Introduced two metrics, updated bi-weekly
- Reduce production bugs from 5 / week → 1 / week EoQ (sheet)
- Increase test coverage from 50% → 80% in all components
- Decrease resolution time from 8 days → 3 days EoQ
- Improve support process through better JIRA support (jira report)
- Reduce production bugs from 5 / week → 1 / week EoQ (sheet)
Example 3
Finished the new microservice that integrates with another payment provider
Better:
Increased conversion rate in the booking funnel by 5% by providing customers the ability to pay with X through integrating with payment provider X
- Y payments on day one, averaging Z in the first week (dashboard)
Example 4
The team conducted 8 interviews for our Sr. Eng. position.
Better:
Hiring
- 2/4 Sr. Eng. signed. Expected to sign two more within the next 3 weeks.
- Investigating drop in interview funnel between Stage 2 and 3.
- Decreased time to hire from 12 to 10 days.
- Conducted 8 interviews with 2 interviewers. Onboarding two more engineers to distribute the load.
Structuring your report
There are multiple structures that you can use. Feel free to find out what works best for you. Here is one template you could use.
Start with the desired outcome and remind the reader what you want to achieve, e.g. proof of value. Metrics can be integrated here too.
Desired Outcome
- Output 1: proof of work, ideally including metrics on progress
- Output 2: assume this includes risks
- Risk 1: what might go wrong?
- How can we prevent it?
- What would we do in case the risk turns out?
- Risk 1: what might go wrong?
- Output 3: assume something happened
- Unexpected happening: something went wrong
- Mitigation: what are we doing about it?
- Unexpected happening: something went wrong
Your turn
Start now and implement report writing into your weekly schedule. Use some of the tips outlined here and let me know how it goes. Try to keep it brief and meaningful. Mark Twain once said: “Sorry I have written you a long letter, I didn’t have time to write you a short one.”