Institute a rotating per-team deep dive at the Tuesday staff meeting, anchored on empirically measurable metrics co-designed in the room

July 24, 2026 at 8:18 PMoperationalhigh

Situation

Peter gave the same instruction independently to Chris Wolford and Steve Wallace on 7/23. Each org lead will take roughly 45 minutes of the Tuesday staff meeting on a five-week rotation. Three parts: a functional overview or demo of what the team delivered in the last month and is working on next; a project-plan view with milestones, tracking, who is on what, and how team time is being spent; and a set of empirically measurable metrics. The metrics do not have to be right the first time - the explicit purpose of doing it in front of peers is to argue out which metrics are the correct ones for each org. Metrics differ by domain: on the Linux side Peter wants automation measures such as the percentage of PRs auto-approved by Nerf versus human-approved; on PIC Chris proposed PR volume and the rate at which releases require bug fixes over time. Chris Wolford presents first, Tuesday.

Reasoning

Peter told Steve plainly that Steves org is not the problem - this is primarily to give him instrumentation to drive the Linux side of the house - but he is applying it everywhere because it is decent hygiene and because it also solves Steves own complaint about lacking visibility into his org, notably the SRE team being a black box with underused skills. Doing it in a peer forum rather than in 1:1s is the point: Peter wants the metric set itself contested and tuned collectively so that the org converges on how it should be evaluated, rather than Peter dictating metrics from outside. He explicitly told Chris the metrics can make you look good or make you look challenged - it does not matter - which removes the incentive to game the first submission.

Additional Context

Extends the 7/7 decision to restructure the Tuesday staff meeting to org-by-org TPS ownership. The new element is metrics: routine empirical reporting to the peer group, with the metric definitions themselves as the object of discussion. Peter tied the Linux metric choice to a related conviction - humans should review tests, which live forever, not individual PRs, which are transient - so auto-approval rate is a proxy for test quality.

Observed Evidence

Two independent 1:1 transcripts on the same day carrying the same three-part structure, the same five-week cadence, and the same framing that metric selection is the discussion. Steve 1:1 also supplies the motive - to help me drive the Linux side of the house - and the secondary benefit for Steves own visibility problem.

Matching Patterns

40%
Protect Engineering Focus Through Process(process/cadence keyword match, same category (operational), creates a regular cadence that gives engineering influence rather than externally imposed restrictions)
32%
Metrics Must Follow Strategy(pairs a priority shift with explicit new metrics, forceful about establishing what the metrics are)

Confidence Breakdown

34/35
Evidence
26/30
Pattern
20/20
Source
13/15
Corroboration

Reasoning Depth Analysis

Org Signal:Being measured is now normal and non-punitive, and the leads own defining the measure. It also signals that Peters attention is unevenly distributed and he will say so out loud - Steve was told directly he is not the problem, which builds trust while still applying the process uniformly.
Who Affected:Nathan Blackham most of all - the Linux automation metrics are aimed at his org even though the instruction went out through Steve and Chris. Sarah Almaraz owns the scheduling rotation. Every org lead inherits a recurring 45-minute preparation obligation.
Precedent:Metric definitions are debated in the peer forum, not handed down. That makes future metric changes a group act and much harder for any single lead to dismiss as arbitrary.
Consequences:Real and recurring - a standing agenda structure with a named first presenter, not an aspiration.
Timing:Now because the re-leveling exercise and the Jira date/confidence push both need an empirical basis, and because Peter is still triangulating team quality off one or two peoples opinions - he said as much to Ryan about needing a perspective that is more than just one or two people.

Source

reflection

AI Confidence

93%

Related Context

🎥
Steve <> Peter Weekly 1:1 - 7/23

fathom

the part I really care about is some sort of empirically measurable metrics. And you dont have to get them perfect the first time. Some of what I want the discussion to be about with all of us peers together is, are these the right metrics... Youre not my big problem. This is more to help me drive the Linux side of the house, but I figure its good, decent hygiene to do everywhere.

🎥
Chris W <> Peter Weekly 1:1 - 7/23

fathom

for Tuesdays staff meeting, we would love you to do a deep dive... with sort of an expectation that youre doing this every five weeks. And then some flavor of metrics... They can make you look good. They can make you look challenged. It doesnt matter. On the Linux side, Im going to make it more about automation, percentage of PRs that are Nerf auto approved versus human approved.

Outcome

Rotation is running - Engineering Weekly Sync: Nathan on Aug 4 and Engineering Weekly Sync: Steve on Aug 11, both on the calendar with the full leadership group.

Rating: 4/5

Decision ID: 8dd650b1-deab-4a1b-bb13-e4ea1838a200