You probably attend one or more meetings where a lot of effort goes into telling each other how things are going. The goal is to get a status update and learn where a project is going well, stalled, or needs help. Behind each update is a hope that whoever reads it will come away holding the picture in the writer’s head and exit the meeting with all of the knowledge they need to act.
Most of the time, the reader doesn’t get the key items they needed, or gets a slightly different picture than the one the writer meant to convey. The problem? No one notices the gap until it surfaces later as surprise information. It’s ironic because we often fail at the action that was the impetus for the meeting: keeping everyone informed.
So how can we make this better? We confidently write these updates today and put out the team update, the Friday email, or the skip level project update. And you’re evaluating those updates every time you see it. This one is sharp, that one is noise, this person’s I trust and that person’s I quietly re-verify before I act on it.
But ask me to define a good operating update … and I stall.
I reach for “clear” and “concise” and “actionable,” and might have a heuristic, like “moved X to Y by when,” but don’t have a bigger picture idea about the shape of the update I need to share for each audience:
-
Should it be very technical?
-
Should I focus on “big rocks”?
-
Should I tell people a red/green/yellow status with little detail?
When I see a great update, I can recognize the quality instantly and I can’t name it. It delivers the current status well and uses a data-driven narrative, but doesn’t kill you with facts.
The updates that land tend to do something quiet. They tell you what the writer expected to happen next, so you know what would count as trouble. The updates that don’t land stay limited to activity: meetings held, tickets closed, or other motions with little way to know if the project is actually moving forward.
That gap is strange, because usually when there’s a shared project in a work context we build a rubric for what “good” looks like, and then teach and test for it until we see more examples of the good outcomes. Using a golden example isn’t perfect, but orients the team from “I always update like this” to “here’s a format that works for the team to understand what’s truly important when you’re not in the room.”
The artifacts we decided to take seriously
Fortunately there are some good analogs to this process of writing updates with impact. The first one is the world of software. When you write code, you also need to get it reviewed. The art of the Pull Request is a good place to model. A great PR is small enough to consume and explains why the change happened and what is not included as well.
Engineers argue about the content of a PR. They rely on a shared object of judgment to get better at describing what’s happening in their world. As a junior engineer or a new hire in the org, you have a point of reference for “how we describe things” and can use that to get better.
Other models are a bit more obvious than engineering.
For example, Accounting wouldn’t exist without an interlocking series of updates: the double-entry ledger. A company’s financials are a periodic report on how the enterprise is doing. The profession established a system called GAAP (generally accepted accounting principles). Accountants are not the only profession to have this rubric: pilots have the checklist; doctors have the morning report.
Each of these examples represents a group of people looking at a recurring artifact and refusing to let everyone privately invent what “good” means. The operating update never got that treatment.
It may be the most frequently produced management artifact in any company — more common than the strategy doc or the performance review — and it has no shared theory of quality at all. We professionalized the writing of code and the counting of money, and left the writing of updates to instinct.
What we do instead
In the absence of a real theory of operating updates, we substitute two weaker things. The first is “good writing”. We decide a good update is a well-written one, so we coach brevity and structure. It isn’t wrong, but it aims at the wrong target.
I’ve read updates that were elegant and useless, and updates that were rough and changed a decision I was about to make. But writing isn’t the only thing. An AI model can now write a clean, terse operating update in seconds, and it still won’t be the update you needed.
The second substitute is personality. We decide some people just “give good updates,” a trait like punctuality. If good updates come from good communicators, there’s nothing to learn and nothing to build.
A capability that lives only in someone’s temperament is one the organization doesn’t actually own.
I once spent hours working on the data to provide an important update that would tell the team we were failing a segment of database customers in the mid-market. Because we didn’t have agreement on the way that I cut the segment, we ended up arguing the metric definition in the meeting rather than addressing the break in the business.
The signs that you don’t have a clear vision of operating updates are easy to spot once you look:
-
A new manager asks what a good update looks like here, and the honest answer is “you’ll get a feel for it.”
-
Two teams report on the same initiative in incompatible shapes, and the executive can’t tell whether the difference is the work or the authors.
-
A quarter opens with a goal, and by the review the definition has quietly shifted with no one flagging it, because there was never a shared expectation of what an update to that goal should preserve.
Meetings need to deliver more value than transmitting a solid update. If the update format is well known, we can focus on using meetings to drive decisions.
There’s a compounding version of this that we’re missing. We produce operating updates more than almost anything else we write, and they’re the one thing we never systematically get better at — because there’s no shared target to improve toward.
The missing discipline
Let’s agree that lacking the shared answer to “what’s a good update” is a missing discipline. We need a shared answer to “what makes this good, and why,” held firmly enough to teach and loosely enough to argue with so that we get better.
Ironically, the raw material to make these updates better is all around us.
Every experienced operator evaluates updates constantly, confidently, and fast. The judgment exists, but we haven’t established a good way to recognize what it looks like from one leader to another within the organization.
When you create a rubric for that discipline (like “a metric is defined by moving x to y by when”), you can compare updates from two different people and more objectively say “this hits the mark.” We’ve never done that for updates. We have a universal skill and no shared science of it.
An invisible standard doesn’t just fail to teach; it hands credit to the wrong people, prioritizing the confident writer over the careful thinker. So the first move isn’t to write a better update. It’s to resist the checklist.
We have an artifact we all produce, all judge, and none of us can define. We coach its prose and blame its quality on personality, and both moves let us dodge the harder question underneath. That question isn’t how an update should be written. It’s more basic, and until we answer it, every rule we invent is arbitrary.
What job is an operating update actually supposed to perform? Let’s find out.
What’s the takeaway? We write updates all the time. What’s the difference between a solid update and a great one? It turns out that we don’t have a good rubric for determining this – it’s an interesting area to explore.
