The judgment sync

Day 27: Replace the status standup with a judgment sync

Your standup has probably turned into a reading club. When agents write a growing share of your code, the status your standup collects is already written down in PRs, agent logs and commits. If you keep running the old meeting, you pay with your team's most expensive time to hear those artifacts read aloud, and the spoken version is worse than what's already written. Meanwhile the few decisions that actually need a human go unmade.

The Tuesday standup

I've sat through this standup more than once. An engineer spends two minutes narrating what the agent did overnight. It migrated the orders service to the new event schema, updated 40-odd call sites, fixed the failing tests and opened a PR. Everyone nods. One browser tab over, the PR description says it better, with a file list, the test results and a link to the agent's trace. Then the round-robin moves on.

Buried in that PR was a sentence nobody mentioned. The agent had kept a nullable legacy column for backward compatibility instead of backfilling and dropping it. That's a real schema trade-off. It affects storage, query complexity and the cleanup work two sprints from now. It was the only thing in those fifteen minutes that needed a human, and nobody raised it.

That one scene shows the whole problem. The meeting passed around information that already existed and never got to the judgment call that hadn't been made yet.

The uncomfortable arithmetic

Here's a rough calculation for a team our size at PhoenixDX. Treat these as estimates to reason with, not measured data, and plug in your own numbers.

Daily status standup (estimate)
  8 people x 15 min x ~230 working days
  = 27,600 person-minutes
  = ~460 person-hours per year
  (excludes context-switch cost before and after, which is real but hard to measure)

When I went back through a few weeks of my own standup notes and sorted each item:
  'already written in a PR / ticket / agent log'  -> clearly the majority
  'needed a human decision'                       -> a small minority

Rough reading: most of those ~460 hours were spent re-reading artifacts aloud.

The exact ratio matters less than the direction it points. If most standup items already exist in writing, the meeting is a lossy copy of your repo. Spoken summaries drop detail, add the narrator's spin, and are gone as soon as the call ends.

Name the shift: status moved, judgment didn't

Status meetings exist for a good reason. For most of software's history, the most current status lived mostly in people's heads. Trackers always lagged a step behind, so if you wanted to know where the work stood, you had to ask. A daily standup was a cheap way to ask everyone at once.

Agentic workflows flip that default. An agent working through a normal PR workflow can't do anything without leaving a trail: a plan, tool calls, diffs, test runs, a PR description, commit messages. Status lands in artifacts as a side effect of the work, and nobody has to remember to report it. Judgment is still scarce. That means choosing between options, settling an ambiguous spec, or getting someone outside the team to make a call. An agent can surface those moments, but it shouldn't own them.

That gives meeting hygiene a new meaning in an AI-first team. Spend less human time passing information around and more of it making judgment calls.

What we cut, and why we didn't cut the meeting

• ▹The round-robin 'yesterday / today / blockers' format. It makes every person talk whether or not they have anything the group needs. That's where the theatre comes from.
• ▹The 'what did the agent do' narration. If the PR description is weak, fix the PR description, or the agent's instructions for writing it. A spoken summary only patches over the gap.

Our first instinct was to drop the meeting entirely and go async-only. We ran that for two weeks, and it failed in a specific way: decisions started falling through the cracks. A trade-off flagged in a PR comment would get one thumbs-up and no actual answer. An ambiguous requirement would sit in a ticket thread while two people each assumed the other was chasing the product owner. Async is very good at moving information and much worse at closing decisions, because nobody notices when a decision is due. We still needed a synchronous moment, but only for the decisions.

What replaced it: the judgment sync

The judgment sync takes about 10 minutes, three times a week. Nobody builds the agenda by hand. It's generated from PRs and tickets tagged with one of three labels:

• ▹TRADE-OFF: the agent (or engineer) chose between real options, and a human needs to ratify or reverse that choice. Example: keeping the nullable legacy column instead of backfilling it.
• ▹AMBIGUOUS: the spec can be read two ways, and each reading leads to different code. Example: should 'archived' orders show up in the customer's history or not?
• ▹BLOCKED: progress needs a person, a permission or a call from outside the team. Example: prod read access for a data migration, or a pricing decision from another department.

One rule keeps it honest: if nothing is tagged, the meeting is cancelled. A cancelled sync is a good sign. It means status is flowing through artifacts and nobody is stuck. Building the agenda takes a few lines of scripting against your tracker. Here's a sketch using the GitHub CLI:

#!/usr/bin/env bash
# Build the judgment-sync agenda from labelled PRs and issues.
for label in judgment:trade-off judgment:ambiguous judgment:blocked; do
  echo "## ${label#judgment:}"
  gh pr list    --label "$label" --state open --json number,title,url \
    --jq '.[] | "- PR #\(.number) \(.title) \(.url)"'
  gh issue list --label "$label" --state open --json number,title,url \
    --jq '.[] | "- #\(.number) \(.title) \(.url)"'
done
# Empty output? Post 'Judgment sync cancelled - nothing tagged.' and stop.

Agents can apply these tags too. Put an instruction in your agent's project rules, such as CLAUDE.md or an equivalent: 'If you choose between materially different options, label the PR judgment:trade-off and list the options you rejected.' Then the agent puts its own uncertain calls in front of a human instead of burying them in paragraph four of a PR description.

The one rule that makes it work

Every item leaves the room with a written decision, an owner, and enough clarity that you could hand it straight back to an agent. The last part is the real test. If an agent couldn't act on the outcome without asking a follow-up question, nothing was actually decided.

BEFORE (vague):
  'Discussed the legacy column. Probably fine for now, will revisit.'

AFTER (actionable):
  Item:     PR #412 - orders schema migration [TRADE-OFF]
  Decision: Keep legacy_status as nullable for one release. Do not backfill.
  Why:      Two downstream consumers still read it; backfill risks lock contention at peak.
  Owner:    <engineer name>
  Next:     Agent task - add deprecation warning on read; open ticket to drop column
            in release N+1 once consumers X and Y confirm migration.
  Revisit:  Release N+1 planning

If you know Architecture Decision Records, this is a small, fast version of one. Store each record in the PR or ticket the item came from, so the decision sits next to the code it governs.

What broke, and how we fixed it

• ▹Juniors lost their daily visibility and felt isolated. The old standup was theatre, but it was also the one place they heard how seniors think. Fix: a weekly 'show the trace' pairing session. A senior walks a junior through a real agent trace and explains why they'd accept, push back on or rewrite each step. That builds judgment, which the old standup never did.
• ▹People tagged trivia as TRADE-OFF to get airtime. Naming conventions and minor library choices started appearing on the agenda. Fix: one bar for tagging. 'Would you block the merge on this?' If not, leave a PR comment and move on.
• ▹Some items were just status with a tag on ('BLOCKED: waiting on review'). You fix a review wait by pinging the reviewer, not by holding a meeting. We kept BLOCKED for things the team can't resolve by itself.

When NOT to use this

• ▹Your artifacts are poor. If PR descriptions are empty and agent traces aren't kept, status doesn't live anywhere yet. Fix the artifacts first, or the judgment sync becomes a status meeting again under a new name.
• ▹The team is brand new or mid-incident. Early forming, onboarding weeks and live incidents need more high-bandwidth contact, not less.
• ▹Agents write only a small share of the code. The argument depends on artifacts existing by default. If most of the work still happens in people's heads, a lightweight status check may still earn its place.

Where this fits in the 30-day arc

Earlier in the series we covered delegation and decision rights: who can decide what, and which decisions an agent can make on its own. The judgment sync turns that into a ritual. The three tags mark exactly where an agent's decision rights end and a human's begin. Tomorrow takes the next obvious question. If you're no longer collecting status in a meeting, how do you, as the leader, stay informed without becoming the bottleneck or the person who reads every trace?

Do this tomorrow

• ▹Pull up your last five standups from your notes, your memory or the recording if you have one.
• ▹Mark each item as 'already in an artifact' or 'needed a human decision'.
• ▹Count the ratio. If the first column wins, pilot the judgment sync for two weeks: three 10-minute slots, an auto-built agenda, and a cancelled sync whenever nothing is tagged.
• ▹Start the 'show the trace' pairing session that same week, so juniors don't lose visibility.
• ▹After two weeks, ask the team one question: 'Were any decisions slipping that the old standup would have caught?'

JUDGMENT SYNC - TAGS (tag only if you'd block the merge on it)

  TRADE-OFF   Options were chosen between; a human must ratify or reverse.
  AMBIGUOUS   The spec has two readings that lead to different code.
  BLOCKED     Needs a person, permission or call from OUTSIDE the team.

  Nothing tagged -> meeting cancelled.

DECISION RECORD (every item leaves with this)

  Item:     <link> [TAG]
  Decision: <one sentence, unambiguous>
  Why:      <the deciding reason>
  Owner:    <one name>
  Next:     <the task, written so an agent could execute it>
  Revisit:  <date or trigger, or 'none'>

Extend your knowledge

• ▹Read Michael Nygard's original 'Documenting Architecture Decisions' post (2011). The decision record in this lesson is a lightweight ADR.
• ▹Read 'Shape Up' by Ryan Singer (Basecamp), especially the part on the betting table. It's a meeting deliberately designed for decisions only.
• ▹Re-read the sections on running meetings and managing teams in 'The Manager's Path' by Camille Fournier, and ask which pieces of its advice assume status lives in people's heads.
• ▹Audit your agent instructions file (CLAUDE.md or equivalent). Add a rule telling the agent to apply the TRADE-OFF tag and list the options it rejected whenever it makes a material choice.