The dashboard was green on Friday.
By Monday morning, it was a five-alarm incident. Three engineers on a bridge call, leadership looped in. The explanation that followed started the same way every postmortem starts: nobody saw it coming.
That’s not what the signals said. The signals had been saying something was wrong for at least three weeks. Nobody read them as a pattern. They’d been reading the status reports instead.
Status reports don’t lie. They optimize.
Every person who writes a weekly update is making a series of micro-decisions about their relationship with the reader. What to lead with. What to bury. What to frame as “in progress” rather than “at risk.” What to omit because explaining it would take too long, raise questions the format can’t handle or create the impression that something is less under control than it is. None of this is dishonesty. It’s rational. It’s the incentive structure working exactly as designed: the writer is managing a relationship, not reporting a system state.
A team lead who surfaces a dependency risk in week one, mentions it again in week three and gets no response, will probably stop surfacing it in week seven. Not because it went away. Because they learned, correctly, that this channel doesn’t address that kind of risk. They adapted to the incentive structure. The report became less accurate and more legible at the same time (I’ve watched this play out more than once. Nobody names the pattern while it’s happening.)
Once you understand what a status report is optimizing for, you can start reading it correctly. Until then, you’re receiving managed information and calling it data.
I spent years at Netflix building OSINT-driven tooling to detect credential theft and account abuse. The job wasn’t to look at what the system reported. It was to learn the difference between what was being detected and what was being manufactured. A clean SIEM isn’t a safe network. It might mean your detection is working. It might mean your detection is broken and nothing is surfacing. Those two states look identical from the outside. Most people see the green light and feel reassured. The forensic instinct asks: why is it green, and what would have to be true for it to stay green while something was wrong?
Status reports are the same problem.
The signals that turned that dashboard red on Monday were in the Friday report. They were described as “some ongoing challenges we’re monitoring” or “a few items we’re still working to close.” Maybe they weren’t there at all: cut for length, cut because the format doesn’t reward ambiguity, cut because three weeks of raising the same issue with no response teaches you something about what gets heard. The report said green. The system had a different read.
The Forensic Read
Most leaders read status reports for confirmation: things are on track, or they aren’t. The forensic read is different. It looks at what’s in the report and what’s missing from it.
The omissions are almost always more useful.
When a risk item stops appearing in updates after being mentioned for two weeks, that’s rarely resolution. It’s more often avoidance: the writer learned the issue wasn’t getting traction and stopped raising it. Percentage completions with no definition of “complete” are precision in the service of ambiguity (and I’ve watched entire quarterly reviews built on that particular evasion). A team lead writing “we’re working through some challenges” with no timeline attached: the missing timeline is the actual data point.
Look for hedging language that changed. If last week’s update was flat and direct, and this week’s has more qualification in it, something shifted. The writer knows something they haven’t figured out how to say yet. Sometimes they’ve figured it out and decided this isn’t the document to say it in, which is a different problem. That change in register is worth a conversation.
This isn’t about suspicion. It’s calibration. The report is produced under specific pressures: time, format, hierarchy, relationship management. Reading it forensically means understanding those pressures and adjusting for them, the way you’d adjust for the known limitations of any instrumentation.
The question isn’t “is this accurate?” It’s “what is this document doing, and what does it not have room for?”
Better-Written, Same Problem
AI-generated status summaries are already showing up in some organizations. They’ll become standard. The early versions are more consistent than human ones: cleaner structure, tighter sentences, no hedging buried in paragraph five.
They’ll also optimize for the same thing.
The incentive structure isn’t in the human; it’s in the data being summarized. If the underlying project is at risk and the inputs to the AI summary don’t capture that risk explicitly, the AI will produce a cleaner version of the same managed information. Better-written. Same problem.
The organizations that run into trouble will be the ones that mistake legibility for accuracy. A well-formatted green light reads more convincingly than a confused one. That’s not an improvement. It’s a more credible version of the same signal problem.
The One Practice
One conversation a week that isn’t a report.
Not a check-in. Not a status sync. A specific question: “What would you have put in last week’s update that you decided not to?” (I started asking this about eight years into managing. Should have started in year two.)
The pause before the answer is the data. What surfaces there is the stuff that was too complicated for the format, too uncertain to commit to writing, too politically charged to send up the chain. That’s almost always where the actual system state lives: the unformatted version, before anyone decided what it meant for you to know.
You don’t need to run this with everyone. Pick the two or three people whose reports have the most influence on your decisions. Ask them that question, once a week, in a 10-minute conversation. What you hear will change how you read the written version.
The status report tells you what the sender needs you to believe. A conversation tells you what’s actually happening. If you’re managing entirely through reports, you’re managing the narrative, not the system.
Hey man, did you just get to Substack?