Hi, I’m Greg 👋! I write product essays, including system “handshakes”, the expectations for workflow, and the jobs to be done for data. What is Data Operations? was the first post in the series.
This week’s toy: practice sitting up straight — researchers at McGill university have concluded it improves your decision making processes and changes your behavior.
Edition 310 of this newsletter is here - it’s August 31, 2026.
Thanks for reading! Let me know if there’s a topic you’d like me to cover.
The Big Idea
A short long-form essay about data things
⚙️ Every manager has a rubric
Responses to weekly operating updates are not random. When you analyze the shape of an excellent operating update, the comments that managers make when they give feedback sound different. Each manager is giving you a message along with their judgement about the update.
Put on your listening ears: you’ll hear additional signals along with the words.
“What are we comparing this to?” is a question about the expectation.
“Why is that surprising?” is a question about the gap between expectation and reality.
“What do we believe now?” is a question about the belief that changed.
“So what changes?” is a question about the next action.
“Will this make sense in six months?” is a question about legibility.
Nobody speaks this directly in a staff meeting. Instead we use the normal method of engaging. We nudge around the edges and call projects risky or off-track without clarifying what needs to be done to fix them. This is not because people don’t care about fixing a project or getting it back to running on all cylinders. The gap happens because you have too many projects to provide status on and you need an easily consumable status to note before moving on to the next item.
The outcome: the important work of steering the project back to good happens outside of your status meeting, so the operating update becomes even more important. The update needs to answer the specific questions of each manager (who has a different angle) when you’re not in the room.
The rubric is already there
Most organizations don’t specify a format for the update itself, so the outcome becomes a matter of preference based on feedback provided by executives. One person prefers the Bottom Line Up Front. Another wants specific details and action steps. Another wants the input and output metrics. Another wants risks separated out from the decisions being asked. Some like narrative, others like spreadsheets.
As a manager providing these operating updates, you probably learn what not to do. Don’t provide too much detail before the initial context. Don’t answer this way to that person. Don’t make too many decisions before you check in with that person. Don’t ask permission and take action instead.
This is real learning, but it’s mostly invisible and probably has a different path for everyone in the org who needs to make these updates.
If you’re a new manager, no one hands you the binder or Google Doc or Claude Skill that delivers you the operating update rubric on your first day. New managers absorb this information by reading the room, or by responding when their first efforts fall flat.
Teams infer this standard today from questions, corrections, and the occasional praise of “that’s a really great update” without additional qualification attached.
This means the difference you see in updates from teams in the same meeting is the output of many operating rubrics, all of them built on similar (but disparate) inputs. Two teams can do equally thoughtful work and leave the meeting feeling like identical off-track projects are at different points.
That wasn’t the intent of anyone in the meeting. It’s the outcome of leaving an important artifact to chance.
Feedback hides the real standard
The manager who says “this is too long” may not actually care about length. They may be reacting to the fact that the update spends five paragraphs on activity before it names the decision. The manager who says “this is too vague” may not be asking for more words. They may be noticing that the claim has no basis for comparison. The manager who says “I don’t buy the recommendation” may not disagree with the recommendation yet — they may be unable to see the belief that changed.
This is where we get into trouble. The prose becomes the battlefield because the underlying standard was never named. The writer hears a style correction; the manager meant a thinking correction.
So the next version gets shorter. You keep minimizing until the update fits in a few bullet points, or you reach for the equivalent of “computer, enhance this sentence.” Sometimes that helps. A lot of the time it just makes a weak update more efficient at hiding the same problem, because a bullet has a hard time holding the old expectation, the metric definition, whether the change is good or bad, whether the core belief moved, and what happens next. That’s a lot of signal to compress into a few words.
The goal is to make the update evaluable. An evaluable update defines one of these important criteria well enough that a reader can observe the change and decide if that outcome makes sense or needs to be challenged. It names the next action so a reader without context knows what’s happening next.
How do you know when you hit this goal? You’ll know if the expectations are testable, you know where to test them, and you have a place to look to see if the bet your team took has missed or is paying out.
These are not just comments on writing. They are compressed evaluations of learning quality.
The problem with private rubrics
Private assessments work better than not having any testable standards, but they don’t scale. If you’re always delivering an update to the same people (a small team all reporting to the same manager), you’ll land on an update style that works for your team. But that same update doesn’t necessarily work when you share it with another manager or another team.
Why does one of these handoffs or status updates with another team feel like simultaneous translation between two different dialects of project management? Because often, it is exactly that problem. Handoffs feel harder than expected because there is a hidden standard. If you ask for the runbook, there’s nowhere to find it.
Each manager is running a local evaluator on every update, so they see them differently. Whether you’re looking for risk, precision, ownership, evidence, or a contradiction of a past decision, you’ll probably find some of what you’re looking for.
All of these instincts and questions are valid. But when they aren’t compared against a shared standard, the organization loses the opportunity for an update to be evaluated consistently when the author isn’t in the figurative room.
If update quality matters, that is not enough.
Making the rubric legible
Ok, now the hard part. Making this rubric explicit does not mean “every update looks the same.”
A pricing update, a migration update, a customer escalation, and an activation update should not all have the same surface form. The uncertainty is different. The evidence is different. The audience is different. Forcing all of them into the same template would make them easier to scan and probably worse at teaching.
But the underlying judgment can be shared.
Did this update make the old belief visible? Did it show reality on a comparable basis? Did it preserve the gap? Did it explain the changed belief? Did the next action follow? Could a future reader reconstruct the learning without needing the meeting?
Those questions are not a format. They are the skeleton of the judgment managers were already making.
This changes what coaching sounds like. Instead of “this is too vague,” a manager can say, “I can’t tell what expectation this result is being compared against.” Instead of “make this more actionable,” they can say, “I don’t see how the new belief changes the next move.” Instead of “add context,” they can say, “future you will not know what activation meant when you wrote this.”
That’s a different kind of feedback. It does not only improve the next paragraph. It improves the writer’s ability to think in update form.
That’s the output we’re really seeking: the ability to ask focused questions about updates and get quality answers. It moves update quality out of personality and into practice. It gives new managers something to teach besides preference. It gives teams a way to improve without guessing what the room wanted. It lets two leaders disagree about the standard directly instead of arguing through proxies like length, tone, or formatting.
Don’t be surprised. Every experienced manager has been carrying some version of it already. They have been rewarding updates that preserve learning and pushing back on updates that make learning impossible. They have been doing it in questions, interruptions, comments, and private judgments.
That’s the part that feels important to me. We started this series with the odd fact that organizations produce operating updates constantly and have no shared theory of what makes one good. But maybe the raw material for that theory has been in the room the whole time. It was sitting inside the judgment people were already making.
If an experienced manager can evaluate an update this way, could something else?
What’s the takeaway? The standard for a great operating update was never missing; it’s been sitting in the judgment managers already make. The trick is making that judgment explicit enough that the person writing the update can apply it themselves, so their intent survives even when they’re not in the room.
Links for Reading and Sharing
These are links that caught my 👀
1/ Teaching the bots how humans reason - One of the key gaps in explaining human decisions is the process of mapping inconsistent entities (customer vs person) to each other so that the bot can suggest solutions that seem more like human solutions. Building semantic links makes this process explicit rather than implicit.
2/ A primer for Vibe Coders … - here’s a list of all of the concepts you need to consider when building an app that needs to support real users.
3/ Bad news for those who switch tasks - Researchers at Berkeley remind us that switching tasks is counter-productive and that it takes a while to recover.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.