When I started at Zillow, one of the first things needed was creating a system of observability and accountability at the team level. What’s the status of that project? Are we prioritizing correctly? What aren’t we doing? These are basic questions that anyone in an organization should be able to answer without needing to ask someone.
Remember 
the TPM triangle? We can’t shy away from process when needed. While I have a core value that “I don’t bring process; I bring efficiency,” it’s important to know when process is needed to create efficiency. It’s also equally important not to over-engineer your solution; you need to meet your customers where they are! Which recently got me thinking about a framework to help answer this: what level of enterprise maturity is my organization at?
I’ve broken this down by answering the following question: how does one know what work is being prioritized and what is the status of prioritized work? I have found three at answers at scale at the company level:
Level 2 sounds great, but it also heavily focuses on a tool. However, without the culture that level 1 instills, the tool will not be used, instead keeping the company at level 0. I’ve observed that trying to jump from level 0 straight to level 2 doesn’t work, as it introduces too much complexity too quickly. By trying to solve all problems all at once, you create high a level of friction that prevents results (as the tool goes unused).1
Instead, you build bottom-up, which means establishing a solid foundation within each org before trying to tackle the problem across orgs.
And how should I do that if I need to? Start by focusing on the process and proving the value from it; not the tooling. Let me say that one more time for those in the back: don’t focus on the tooling first. I have seen this time after time in my career, and I have yet to see it succeed.
So, what’s the process?
You should know by now to lead with problem statements; by first focusing on the problems you want to solve, solutions then have clear success metrics. Let’s go back to the start of this post and lay out some goals:
Adapt these goals for your own needs, but these have been universal at all companies across my career. With these goals in mind, defining a process is easy. No, it’s not quarterly planning; these goals require accuracy and recency to solve. It’s not Monthly Business Reviews (MBRs) either (even though I am a fan of these). While I love documents as a form of communication, they don’t give you structured data; they don’t give clear tracking of projects line by line to see overall team health or give a breakdown of overall progress towards larger initiatives/programs broken out by team. In other words, MBRs don’t solve the second goal above. They also require a lot of time, as they are typically an hour per session. MBRs are a great tool at the organizational level (ie, one per org); but the goals above require a solution at the team level.
However, there are aspects of the MBR process we can borrow here. Through the process of having a recurring review with leadership, a forcing function for updates is created. Think how up to date you need this to be; the answer typically aligns with sprint cadence, ie two weeks. Even if you’re using Kanban and not sprints, I advise doing it fortnightly, not weekly.2 The ROI on weekly updates just isn’t high enough; you’ll get updates like “no progress was made this week as so and so was on vacation.” You also want this process to be used and not hated; you can always change the frequency, but I recommend starting here.
OK, so a fortnightly review…of what exactly? Can we talk about the tool now? Yes, now that our goals are established, we can talk about the tool.
So, what’s the tool?
Can you pay for one? Of course; I personally like Airtable for how flexible it is. But boy is it expensive with per-seat licensing! And in the days of vibe-coding, it shouldn’t be necessary, at least for Level 1.
I believe in meeting users where they are at, and usually, they’re in a spreadsheet of some kind (Quip, SmartSheet, Excel, gSheet, etc). So, introducing a new template: the recurring org review. We’ll talk about the format in a minute and how to use this template, but what I love most about gSheets in 2026 are Apps Scripts and how well Claude can be used to help create them to enable reporting views and formatting updates on a regular basis automatically.
While this template has such Apps Scripts built-in, you will need to make adjustments for your own circumstances. But that’s a feature, not a bug; iteration over time is easy, especially in something as simple as a spreadsheet.
You’ve already laid out the goals and process thinking above, so start with the Overview tab to codify this thinking. It is the first tab by design — folk will see it before anything else to understand the reason they are being asked to do this work. This keeps all content in the team tabs intentional:
There are additional tabs to the right for columns like dependencies, risks, links, and assigning matrix ownership, but the core is in the screenshot here. There are a few things to address before continuing.
What’s the difference between a strategic priority and a program?
If this adds unnecessary complexity for you, consolidate the two! However, at larger enterprise scale I’ve noticed the need for both. Strategic priorities tend to be org-specific, and programs tend to be cross-org. Sometimes, an item of work will cover both, but they are often independent of one another and are driven by different leaders.
For example, imagine an organization’s strategic priority is to enable a new platform capability, but there is also a program driving a technical migration of some kind. As the team is building the new platform capability, they are building on the new tech stack so they do not have to migrate as soon as they launch; this is an example of a single project satisfying both a strategic priority and a program at the same time.
If you don’t have strategic priorities, well, you should have a strategy. And if you’re still seething at my dig on quarterly planning earlier, it’s reasonable to assess your strategy on a quarterly basis and use this assessment to feed this process for teams to work backwards from!
Can we use alternative prioritization frameworks besides stack ranking?
I strongly advise against it. Throughout all of my career, I have never seen another prioritization framework make sense. Typically, the alternative framework is P0, P1, P2, and P3 (with inconsistent definitions). But what we are doing here is tracking work that is in flight; why would it be anything but P0 or P1? How does this help the team know what to prioritize? Hint: it doesn’t.
Stack ranking forces true prioritization decisions; you cannot have more than one #1, one #2, etc. This creates the hard conversations, but at the same time, #1 vs #2 might not matter if both are above the line and actively being worked on. What you care most about is the cut line which is clearly shown in this tool. At the same time, if an urgent request comes in, you already know which project may get bumped down below the line and/or delayed in order to handle the request.
But Straker, I also need cross-team views.
Of course — we all do! And with the power of Apps Scripts, we have them:
This is a screenshot of the global report of all work across all teams. This enables a VP of an org to quickly filter for all work that is At Risk or Needs Help, irrespective of the team (as all reports have filters built-in by default). Reports will also be generated for each strategic priority and program. Not bad, eh?
So to configure this, I…
Start by going to the Shared Data Validations tab and replacing the test values in there with real data. Rename/delete existing report tabs as needed.
Then, copy the Example Team tab and start making tabs for each team. I like to organize tabs with color-coding. For example, grouping teams by director with unique colors. Fill in the data in row 1 for each team (when possible), as now you know who you need to be involved in this process.
Let’s talk about the Apps Scripts.
This is the exciting part! You can access the scripts from the menu bar via Extensions → Apps Script. Here is what these scripts do:
To get these benefits, you need to make your own copy of the gSheet — don’t worry, Apps Scripts come with the copy. Then, you need to run createScheduledTrigger once in All Reports.gs to setup the timed run:
…which will trigger a Google authorization:
Click Advanced to proceed with that grey link at the bottom that says unsafe 😅. It’ll be your own code soon enough! Then select all permissions and continue to authorize the run. Then make sure you run createScheduledTrigger and verify that it worked by going to your triggers in the left sidebar (the stopwatch icon):
You should see the one you just created there.
Uh, why can’t I even access the Apps Script?
If you get this lovely error message when you navigate to Extensions → Apps Script:
…you’re not alone. You get this because you have multiple Google accounts and Google tries to access the Apps Script using your “default account” (I believe this is indexed), regardless of what account you are currently logged into on the page. I get around this by either switching my Chrome profile or by accessing it through a private browser window.
Are there changes I need to make to the Apps Scripts?
Yes, specifically All Reports.gs. At a high level, you need to follow the instructions at the top of this report, but we’ll walk through them here as well.
Specifically though, you need to do the following things:
What if I need to make updates after this process is live?
This is going to happen; embrace it upfront. The good news is, with the Shared Data Validations tab (which you should lock and hide), it is easy to add/change values to existing fields – just add new rows and they will be automatically taken into account in the team tabs (#ThanksGoogle). That said, you may need to update the Data validation to adjust any coloring as needed in team tabs, and transferring this to reports requires updating the All Reports.gs Apps Script.
While it’s more work to add new fields once you have a bunch of teams using this, it’s a lot easier when you use data validations (accessible from the menu bar via Data → Data validation). But if you setup your Example Team tab the way you want, you can use Copy Data Validations.gs (Apps Script) to copy the Data validations you have setup there to other team tabs!
Oops — I broke it all.
Remember, Claude is your friend. I have Clear All Conditional Formatting.gs because I needed to reset when I was making changes, but you can always make other such functions as needed! That said, once this is being used, treat it like a production system; you need a staging environment, and that environment is your Example Team tab.
Tests.gs exists to test functionality on your Example Team tab first before you make changes to all of the tabs at once. Follow this best practice to save yourself a headache in the future! And thanks to Matias Villaseca for making the Build Status tab — this improves monitoring of issues to ensure everything is working before you have a review!
Conclusion
In summary, this gSheet is a free tool to use to track work across your teams. I’ve used it (or variations of it) successfully in multiple organizations across different companies, the largest covering over 20 teams.
Leave a Comment