Never ask what the system already knows

Imagine standing in your kitchen, strapped into a fitness watch that has been quietly counting every step you've taken since 6 a.m., and asking your spouse, out loud, "how many steps have I taken today?" Your spouse doesn't know. Nobody in the room knows. The number exists, perfectly, on your own wrist, and you just spent a sentence and a half of a shared, finite resource — everyone's attention — asking a question that a two-second glance downward would have answered for free.

Now go sit in your next standup and count how many questions asked out loud are exactly this.

The tax nobody notices they're paying

"Which services are throwing the most errors this week?" Your monitoring stack knows. "Did the retry fix actually reduce timeouts?" Your telemetry knows, precisely, to the percentage point, days before anyone gets around to asking. "Who touched the billing module last?" Your commit log knows, with a timestamp. Every one of these questions has a legitimate reason to exist in someone's head — they're good questions! — and every one of them is a waste of the room's most expensive resource the moment it's asked out loud instead of looked up.

Call this the standup's hidden tax: attention spent retrieving an answer that already existed somewhere machine-readable, charged against a meeting that only has fifteen minutes to spend. It doesn't show up on any dashboard, because the cost isn't an error — it's an opportunity. Every minute spent on a question the system could have answered is a minute not spent on the one thing a standup actually needs humans in the room for: judgment about what a fact means, made by people who have context a dashboard doesn't.

A fifty-year-old idea about what to ask at all

There's a discipline for exactly this problem, and it didn't come from software — it came from a McKinsey consultant named Barbara Minto, who in the late 1960s formalized a principle now taught to nearly every strategy analyst on earth: MECE, mutually exclusive, collectively exhaustive. A well-designed set of questions covers the whole space you care about (collectively exhaustive) without any two questions asking the same thing twice (mutually exclusive). It's a discipline for question design, not answer design, and it turns out to generalize far past consulting decks.

Apply MECE to a standup's question bank and something clarifying happens immediately. Split every possible question into two buckets: things a machine can already answer and things only a human can answer. A properly designed standup only ever asks from the second bucket, on the theory that the first bucket is redundant by construction — asking it is asking the same question twice, once of the system (silently, automatically, continuously) and once of a human (out loud, expensively, in a room). MECE says: don't do that. Pick one asker per question, and for anything countable, observable, or already logged, the answer should never require a human's mouth.

What actually belongs in each bucket

The machine bucket is bigger than most teams assume, and it's worth being blunt about what's in it: which functions ran, how often, how their error rate moved against their own baseline, which commits landed since yesterday and what they touched, whether a stated deadline has a matching commit yet. None of that needs a human's memory. It needs a query.

The human bucket is smaller, and it's the valuable one precisely because it's small: what does it cost the business when this specific thing breaks. Whether a workaround feels safe to someone who's actually touched the code, versus safe in the abstract. Which of two technically-equal options a customer would actually notice. Whether the team is quietly afraid of a piece of code in a way no error rate captures yet. These are the questions where the room full of humans is doing something a query cannot — and they're exactly the questions a standup spends the least time on, because the machine-answerable ones ate the clock first.

A question whose answer is already sitting in a log file is not a coordination question. It's a lookup wearing a coordination costume, and every time it gets asked out loud, a real coordination question loses its turn.

The test: would a screenshot have done this?

Here's a fast filter for your own next standup, and you don't need any tooling to run it. For every question that gets asked out loud, ask afterward: could a single screenshot of a dashboard have answered this, with nobody's judgment required to interpret it? If yes, that question belongs in the pre-read, not the meeting — it's arithmetic, and arithmetic doesn't need fifteen people watching it happen live. If the honest answer is no — the number exists, but somebody still has to decide whether it matters — that's a real standup question, and it deserves the room's full attention rather than the leftover two minutes after the lookups ran long.

This is precisely what a pre-scrum brief is for, and it's worth naming plainly since this series keeps circling back to it: a brief generated from commits and telemetry before the meeting starts is the mechanism that empties the machine bucket before anyone walks in the door, so the fifteen minutes in the room only ever has to spend itself on the bucket that actually needs a human. CodeNSM builds exactly that brief — the "what actually changed since last time" section exists specifically so nobody has to ask it out loud. But the discipline works with a spreadsheet and an honest habit too: MECE doesn't care what tool enforces it.

The awkward part: this requires admitting the system knows more than the room does

There's a reason this is harder than it sounds, and it isn't tooling — it's status. Asking "what changed" out loud, and getting to be the person who answers it from memory, feels like contributing. Deferring to a dashboard for the same fact feels, to some people, like admitting the meeting doesn't need them as much as they'd like. That's a real, human, understandable resistance, and it's worth naming directly rather than pretending better tooling alone will dissolve it: the value a person brings to a standup was never "I remember the deploy log." It was always the harder half — judgment, priority, the cost of the thing breaking. Reclaiming the room's time from lookups isn't a demotion. It's the only way anyone gets to spend their fifteen minutes on the half of the job that was theirs to begin with.