Hidden Powers of Weekly Reports

Introduction

This article describes a weekly exercise that takes only 30 minutes yet improves personal productivity, team efficiency, and the manager’s ability to help the team. It’s a weekly report, with specific sections, that is consistently shared with the team and manager. I have used it with great success in organizations ranging from 8-person startups to 70-person teams at Amazon. The method is easy to roll out, takes a few weeks to fine-tune, and yields results almost immediately.

The structure of the article is as follows. First, I’ll briefly describe each section, Then I’ll outline the benefits I have observed after implementing the process. With that context, we’ll take a deeper dive into each section, followed by overall best practices. We’ll then review a recommended step by step deployment guide. Finally, I’ll share a few specific case studies to ground the discussion.

The article is written from the point of view of a manager, but I would recommend adopting the practice yourself even if you are an individual contributor.

The report consists of five sections:

1. Progress Last Week. What you accomplished last week, ideally with some lessons learned.

2. Plans for Next Week. What you are planning to achieve next week, framed in completable units of work.

3. Needs from Others. What you need from specific other people next week.

4. Risks and Concerns. What risks you see to the project, and other non-project related concerns.

5. Kudos. Who you are grateful to for help over the past week and why.

The report should be about one to one and a half pages long. Anything longer would take over 30 minutes to write.

Benefits to Author and Team

A written weekly report has multiple benefits to the author and their team. It provides an opportunity to reflect on the accomplishments of the past week, and thus improve the planning for the upcoming week. It saves the author time by eliminating multiple verbal updates during the week. In a distributed team environment, a written update helps keep remote team members informed. Written reports enable partner teams who may not need daily updates to review progress asynchronously. When these reports are captured in a collaborative communication framework (Google docs, Workspace, Basecamp), they become searchable by other team members and reduce interruptions.

Written reports also reduce the need for group round-robin status meetings, by enabling asynchronous review and commenting. Group meetings will have more time for participatory discussions.

There are two secondary benefits to the author. First, when written in a narrative format, the report provides weekly practice in condensed, crisp writing. This skill will serve the writer in their career for when they write design reviews, give talks, and provide status to leadership. Second, the reports provide a convenient archive for reviewing end of quarter or end of year accomplishments for performance review.

Unlike conventional status reports designed to inform the manager of individual progress, these reports are meant to help the author first, the team second, and the manager third. Having said that, each section provides different value to each reader type.

Per-Section Deep Dive

Progress Last Week

The primary goal of this section is to efficiently inform team members and other readers about important results. While there is value to the writer in reflecting on what got accomplished as a springboard to planning next week, it is secondary. To that end, the writing style should be very compact and lead with what I call the “so what?” statement.

Each bullet should start with the “result” phrase, followed by the activity description, and should answer the “so what?” question clearly. Most engineers and scientists are trained on rigorous scientific methods: do the work, gather the data, perform the analysis, and finally draw the conclusions. It is thus natural to report in the form of “performed work X, which resulted in benefit Y”. Instead, each bullet should be written as “Achieved benefit Y by performing work X”. Why? Readers who are not familiar with the exact technical work can still appreciate the impact. Readers who are familiar with the technical work can skip reading the bullet. For example, write “reduced build times from 10 minutes to 2 minutes by cleaning up dependencies” rather than “worked on the build system”.

Report only important activities. As there is limited time to write and to read the reports, focus on what the reader needs to know. For example, if you completed mandatory training, the team probably does not benefit from knowing that. On the other hand, if you spent multiple hours on interviews, that could be useful data to estimate where your time is going.

Focus on what was accomplished rather than time spent. It is very common to take multiple days to solve a tricky bug, even if the solution is one line of code. Very complex bugs may take multiple weeks. It is perfectly acceptable to report that you tried approaches X, Y, and Z, and none of them worked. Your teammates can now help you even better after they know what didn’t work. The report is not a time card and you do not need to account for every hour of the week.

Be transparent about mistakes; when possible convert into lessons learned. If you wasted three days implementing the wrong feature because of an unclear task, or chose a technical direction that turned out to be a dead end, both are great items to report on. Just remember to include what you would do differently next time. The price of a mistake has already been paid; the value can be maximized if your report prevents others from making the same mistakes.

Create subsections for different projects. Engineers sometimes need to work on different projects during the same week. Subsections are a kindness to readers that are only interested in some of the projects that you have worked on.

Plans for Next Week

This section sets you up for success by having you think through and then commit to goals that can be completed by the end of the week.

For each task that can’t be fully completed during the week, think of meaningful partial progress that can be marked off as completed. For example, if you are implementing an API with 10 functions, you can write “complete 3 of 10 API calls”. If you are writing a design doc that spans several weeks of work, you can write “complete system diagram, a 1-paragraph description of each component, and a short description of each interface”.

For tasks that intrinsically cannot be guaranteed to be completed, such as complex bugs, outline either time to be spent (“spend 2 days on investigating bug X”), or even better what approaches you plan to explore (“try approaches Y and Z to investigate bug X”).

One common anti-pattern is to write “work on activity A or project P”. While that brevity is fine if all you are trying to do is to inform the team or manager, you are denying yourself of the opportunity to plan the week. If you do not know how far you can get during the week, then set aside time to make a plan that you can use in the coming weeks.

A process that works for me is the following sequence:

• Look at your calendar for meetings, time off, and other non-working blocks, and compute remaining hours available for focussed work.

• Look at your formally committed tasks in whatever task system your team uses (Jira, Asana, internal tools).

• Review tasks not captured above (document reviews, interview preparation, design docs). Along the way, ideally add those to the calendar to block them off.

• Rearrange the bullet points in the section in priority order.

• As you review each goal, if you need help from other people, capture them in the Needs section.

Finally, it can be valuable to capture what you are not planning on working on next week, if there was prior expectation by other people of specific tasks.

Needs from Others

After you’ve thought through what you need to do next week, identify whose help you may need for that. Whether it’s a few hours of access to a test bench/room, or some code that you need a team member to finish, this is the place to alert them. One valid approach is to @mention the people in the plans above, but an explicit “needs from others” section is a good memory trigger to think through dependencies.

Avoid calling this section “Blockers”. Blockers is an ambiguous and passive term. The reader does not know if you’re actually stuck and need help, or whether it’s an anticipated risk where you could be blocked, or whether it’s only a delay. If it’s a delay, then mention it in the progress/next week description. If it’s a risk, put it in the risk section. If you need help getting unblocked, then it is up to you to think through who is the rest person to unblock you and make the request in this section. If you don’t know who the right person is, then call out your manager. The ideal format for each entry is “Person X to do action Y to enable me to Z”.

Risks and Concerns

This is a section for all the items that you’re worrying about, and are willing to share publicly. They can range from mundane frustrations (my monitor is on a 3-week backorder), to observations about the engineering process (it takes an hour to build and deploy a test image), to strategic concerns (how will recent corporate change X affect my project).

Some people find it easier to start with non-controversial risks and work their way up in comfort level, but it is important to list at least one item.

Kudos

Who really helped you last week? Thank them, with about one sentence of detail as to what they did. They’ll enjoy reading about it, and will probably show it to their manager.

Organizations that have other “thank you” or “accolade” tools do not need detailed entries in this section, but it is still a reasonable placeholder for listing people who were thanked. It is also a good reminder for gratitude. Research has shown that “giving thanks can make you happier”.

An empty Kudos section usually means that either the writer is working in an area of full personal competence with no help needed, or the writer is not reflecting on who helped them.

Best Practices

The report is ideally delivered in a long-form medium that enables threaded discussions, alerting and forwarding to others, searching, and public visibility. Candidates are Google docs, Meta Workplace, Quip, and similar platforms, though internal wikis and blogs can fill in if needed. Email is a distant third choice as it does not meet many of the criteria above.

Specific guidelines for authors are:

1. Limit text size. Keep each update item to two to three sentences. If the update becomes longer, it’ll take you longer to write and the reader longer to read. The goal is information density. Keep the overall writeup to 1 page; there should be no reason to write TL;DR.

2. Provide links to details. Provide links to any work product that someone may want to read (posts, design docs, papers you read, code reviews, or tasks). That way the reader can explore on their own rather than asking you for details.

3. Mention others. If using tools such as Workplace, Google Docs, Quip, @mention people who helped you or who you worked with. For organizations that operate via email, still list the names, but bold them so they stand out.

4. Write narrative instead of bullets. Terse bullet form updates provide insufficient information for the reader. They also reduce the practice value of writing information-dense narrative. On the other hand, bullets are occasionally acceptable if time is short. Consistency is more important than quantity for this writeup.

5. Timebox to 30 minutes. The exercise is meant to be a relatively small fraction of the week. If it takes too long to write, it will probably take too long to read. The first one or two reports will probably take 5-10 minutes longer.

6. Send on Friday afternoon. That forms a good capstone for the week, and eliminates the temptation to “catch up” over the weekend so that you can report more progress. If Fridays do not work out for personal reasons, send by mid-morning Monday at the latest.

7. Keep a consistent format with your team. If the team decides to modify the template, that’s fine, but maintaining consistency is being nice to your readers. People will be reading multiple reports from your team, and a common format streamlines their scanning.

8. Provide key information in the report. One anti-pattern of this report is only to provide a link to a ticket (Jira, Asana, internal ‘task’ tools) rather than a summary. That forces the reader to click through detailed technical information to understand progress; much of the report’s value is the author’s judgment of the key characteristics of the task.

9. Include all sections even if they are blank. The section headers are valid prompts for recollection. For example, even if there are no risks/concerns or kudos entries this week, keep the headers. By the time you finish typing in “None” you may well remember someone who helped out. Typing in “None” is also an explicit statement that you don’t have any concerns.

Deployment Guide

The most effective way that I found to roll out the process is to start with a pilot and then expand to the rest of the team, providing feedback along the way.

1. Announce and explain the process to the team. It is important to walk through some examples, ask questions, and provide motivation. Most people will be unfamiliar with weekly reports and some will question its value. The initial introductory session should take about 30 minutes in a team setting.

2. Select one team member and help them write the first report. The ideal candidate is a senior team member with good communication skills. It is important to review and edit the initial report until it meets all the best practices outlined above. Publish the report and ensure that everyone on the team reads it, ideally during the next team meeting.

3. Select another 2-3 team members and help them write. Repeat the process with a subset of the team. Ensure that you review the report drafts prior to publishing. Ask them to track how much time they are spending writing the report, and emphasize the goal of a 30-minute time box.

4. Roll out to the entire team and provide individual feedback. In this phase, many team members will need coaching and feedback. A scalable approach to improve the team writing is to have the team read all the reports prior to the team meeting. This will ideally provide good examples to pattern match. During the team meeting, call out the best examples.

Case Studies

This section describes two case studies: a) a composite of several situations across multiple companies, whose details are confidential and b) a rapidly growing team in a large tech company.

A Composite TurnAround Story

The section composite story set it in a 30-person generic web company, where I was hired to turn around the struggling engineering team. Recurring patterns in the weekly reports enabled me to quickly diagnose slow feature delivery, detect structural technical risks, and identify low performers who were dragging down the team.

When I joined, I inherited a struggling engineering team. There were several subteams: a science team working on recommendations, an ingestion team that was scraping the internet, a search and indexing team, and a front-end team that built the web applications. There was a fairly flat organizational structure, with everyone reporting to me, and senior tech leads organizing the work. All teams were using Jira and running methodical monthly sprints.

After I introduced the weekly reporting process, a number of issues became apparent. First, most teams were swamped by operational issues that reduced their feature delivery velocity. This gap became readily apparent when I compared the “next week” and “last week” sections. Second, the “risks and concerns” sections consistently raised the point that the team was maintaining seven different SQL and non-SQL databases in production. As a result, operations were very fragile as only one or two people understood each subsystem and those people were effectively on-call continuously. Finally, some teams had low performers whose weeklies reflected the fact that their tasks dragged on for multiple weeks, and sometimes had to be repeated due to low quality.

I was able to understand these issues after about four weeks of reports, and began to address them. The product team had started to read the reports and agreed to defer some features until operations were stabilized. Team morale improved after on-call interruptions were reduced and we made a plan to consolidate some of the databases.

Growing Team in Big Tech: PrimeAir

I joined PrimeAir in late 2014 as the team started to rapidly evolve from a small prototyping group composed mostly of engineers to a larger organization that needed to manufacture electronic and mechanical components and therefore included technician, operations, and procurement teams. As a result of the growth, “same-room” communication methods began to fail and teams did not know what each other was doing.

I had a team of 8 engineers that grew to 70 over the course of 2 years. I introduced the weekly report practice immediately and rolled up a two-page summary of the highlights once per week. The reports were sent as an email to a subscription list that quickly grew in popularity across all of PrimeAir. Confidence grew in the engineering team’s ability to deliver circuit boards, firmware, and mechanical systems, as week by week goals were communicated and met. Leaders of other teams appreciated the transparency, as problems were highlighted early and then usually resolved. The email list expanded to include over half of the organization.

As the team grew, I introduced a hierarchical report structure, where line managers read all of their team reports, and then prepared a condensed report of the highlights to forward to me. This served as a forcing function to have each manager remain current with each of their reports’ progress. Once per week I sent a condensed summary to the PrimeAir leadership.

When PrimeAir expanded to additional international sites including Austria and Israel, remote teams appreciated the ability to stay up to date by reading our teams reports. Eventually, multiple other engineering and science teams adopted the practice.

Conclusion

In conclusion, implementing weekly reports with clear sections and consistent practices has become a game-changer for me and the teams I've worked with. Carving out 30 minutes each week to reflect on progress, plan for the future, and acknowledge team members has become a ritual I actually look forward to. It's a chance to step back and see the big picture, while also ensuring everyone's on the same page.

Over time, I've seen this practice foster a transparent and collaborative work environment. Communication improves as information flows freely, risks are mitigated by being surfaced early, and successes are celebrated together. The result is a more productive and empowered engineering team. If you're looking for a way to boost your team's efficiency and morale, give weekly reports a try. You might be surprised at the positive impact they can have.

Sample Report

This report dates from 2002 and is from a defunct startup (MicroDisplay Corporation). Contents have been anonymized slightly and are overly terse.

LAST WEEK

1. Completed simulation and performance comparison of the present ramp driver buffer with a prospective buffer (LT1220 chip).

2. Helped OJ document the product brief of the Fonda architecture with minimum features

3. Completed coding a simulation model for single and double panel superscroll characteristics.

4. Generated gamma tables with various overdrives for testing ramp streaks on EWX

5. Completed study of all fabrication processes of UMC and made preliminary estimations of layout sizes of the suitable processes. One process was chosen to be most suitable for our application.

THIS WEEK

1. Complete testing the new buffers received from LT, as well as those received by DE.

2. Add lumen calculations to super scrolling simulation code

3. Use ramp streak code to test EWX with the various gamma tables generated, and observe their effects.

HELP FROM OTHER TEAM MEMBERS

1. RS on testing the new buffers.

2. MLJ on a new better VTC so that the ramp streaks testing is more efficient. She would be working on it this week.

3. CV for the lumen calculation spreadsheets.

RISKS AND CONCERNS

1. Simulation results for the new LT buffer has shown results far inferior to the required spec. Although it has the required current capacity, the bandwidth is less than 10 MHz for a 10 nF load. Furthermore, different compensating components are required for different capacitance values at the load. If the preliminary bandwidth tests on the actual chip show the same results, it is likely to be rejected without further verification.