BA 34/52: The System For Grand Alignment (Status Reports)

This piece is part of an ongoing stream of thought on Systems of Work. Together, these individual pieces form a playbook on how TPMs can leverage their skills to help teams do the work of doing work effectively.

---

Every system (including teams) starts out as a singular. Then, it grows into doubles, triples, quadruples. Before you know it, a single person or even a single team is now multiple people and/or multiple teams.

Pick up any book or written content, the primary challenge of scale is communication across the ever expanding organization. How do we make sure everyone knows what everyone is doing?

For better or for worse, status reporting is primarily the most common and arguably the most effective method, to date, that can be employed to keep all the teams aware, informed, connected with its ever expanding self.

Now, Status Reports can take many shapes and forms with numerous attributes:

• Structured (template with headings) or Unstructured (bullet points of what is important in the moment)

• Written (weekly status report, newsletters, slide decks) or Recorded (recorded video updates, audio updates, demo walkthroughs of new features).

• Regular (weekly, biweekly, quarterly) Or On-Demand (sporadic, generated upon request)

Ultimately, a great status report, no matter how often, or in what format it is done, answers the following 4 Ws:

• What happened? (Wins, Losses, Progress, Changes)

• What is next? (Upcoming tasks, Milestones, Next Steps)

• What needs attention? (Blockers, Decisions, Call to Action)

• Why it all matters? (Roadmap Context)

I know, more than anything else, status reporting is probably in the top things engineers hate about the admin overhead with software development projects. I would agree with them.

I have never been a fan of Status Reports.

I lived through two Status Report styles at Apple, both a lengthy week long affair that involved dozens of people, repeated weekly like clockwork:

• The Scott Forstall: Every iOS feature with its tasks, etas, and status updates were rolled up every Friday, in an extremely prescribed manner sent to Scott as a lengthy email (use only Blueberry Blue for the font for writing feature updates versus Gray font color for no updates). Every Sunday, Scott would read the entirety of the status report and fire off emails to DRIs with key leaders cc'ed on Sunday night, expecting a reply by Monday end of day.

• The Craig Fedrighi: Craig was less worried about the details and more interested in the high-level status for key tentpoles. Rightfully so as unlike Scott, Craig was responsible for both iOS and macOS, and now tvOS, watchOS, iPadOS. The timelines for the status roll up were similar to that of Scott's except Craig only reads the exec summary for each tentpole feature.

Then, I lived through an absence of any formal status writing at Google in the Android Things team. Followed by the most regimented of status roll ups at Nike.

Somewhere along the way in my career, I have come to appreciate a certain rule in the TPM Playbook: Sometimes the pain of a particular process is outweighed by the actual benefit generated by the process output.

Status Reports remain the best tool in the TPM Playbook for keeping an organization aligned with its many parts.

---

Why should I care about this?

I think ultimately, what engineering and product teams fight is not the act or purpose of Status but the manner in which it is rolled up - the system's mechanics is the issue.

So, when you find that you can no longer just look over to your colleague or huddle quickly as a team in a manner of minutes or can’t hold the count of your software organization on two hands, you need to start considering rolling up Status. Instead of wasting your time fighting the need for it, focus instead on how you can make the process of rolling up Status easier.

John Culter in his post this week talks about (Dis)incentives - instead of focusing on incentivizing good work, focus on making the environment and systems better to support making it easy to do the work.

That is what I want you to focus on. Make it easy to write status.

I know this is all obvious and trivial but like all things obvious & trivial, these are often the last things we do as leaders. We do not always approach problems, that don't need code written, with a systems thinking mindset.

Homework for you: If you roll up status today, do a full flowchart, end to end, of who is involved and how status reports are generated at your company or organization. Can you find at least 3 low hanging things you can fix to make it easier (ex: reduce the steps in the process) to roll up status? See what impact that has on the engineering and product teams' opinion about Status reporting. Share in the comments section on what changes you see as a result. Did things get better? Or stay the same with status reports?

Until next time 👋!

-Aadil

---

P.S. A Shoutout!

One of the things I love the most is discovering new newsletters and reading sources.

I want to give a shoutout to Jakob Greenfeld and his Business Brainstorms newsletter which helps fellow entrepreneurs level up their entrepreneurial game. Each email includes paint points, trends, and frameworks specifically for founders looking for better business ideas.

Join more than 7000 creators and solopreneurs getting the free Business Brainstorms newsletter. Level up your entrepreneurial game and get high quality paint points, trends, and frameworks delivered straight to your inbox.

---

How was this week’s newsletter?

🤯 Amazing | 😁 Good | 😊 Okay