For most of my career, the project review was a fixture. A dozen people in a room or a grid of faces on a call, an hour blocked weekly, a slide deck someone built the night before. We treated it as the moment of truth, the place where a project got the scrutiny it deserved. It took me an embarrassingly long time to admit that the meeting helped almost no one. The people presenting spent more time preparing the performance than doing the work. The people watching half-listened and checked Slack. And the actual decisions, the ones that changed where a project went, almost never happened in the room. They happened afterward, in a hallway or a thread, between two people who finally had the context.
So we stopped. Not gradually, not as an experiment with an off-ramp. We killed the standing review meeting and moved the entire thing into writing, conducted on the work itself. That was eighteen months ago across roughly forty product and design projects. The quality of our reviews went up, not down, and I would not go back. What follows is how the written review process actually works, what it costs, and the mistakes we made before it clicked.
Why the meeting was the wrong container
The core problem with a live project review is that it forces synchronous attention onto asynchronous work. A project does not need feedback at 2pm on Thursday because that is when the room is booked. It needs feedback when a real decision is in front of it, and it needs that feedback from the specific people who can move it, not from whoever happens to be on the recurring invite. The meeting flattens all of that into one rhythm and one audience, and the result is a lowest-common-denominator conversation. The presenter pitches up to the least-informed person in the room. The most-informed person stays quiet because correcting the record in front of an audience feels like an ambush.
There is also a brutal arithmetic to it. A weekly hour-long review with twelve attendees is twelve hours of senior time every week, before you count the preparation. Over a year that is several hundred thousand dollars of fully loaded salary spent on a meeting where, if I am honest, two people did the thinking and ten provided ambient pressure. Good project management is not about gathering an audience for the work. It is about getting the right context to the right person at the moment a decision is live.
How a written review actually works
The unit of our review is a short document, written by the person who owns the project, attached directly to the work. Not a deck, not a status email. A structured note with four sections: what we set out to do, what is actually true now, the specific decisions I need made, and what I will do next if no one objects. That last section matters more than the others combined, and I will come back to it.
The owner posts the review and tags the three or four people whose input genuinely changes the outcome. Reviewers read it on their own time, within a stated window, usually forty-eight hours. They respond in writing, in line, on the exact sentence they are reacting to. A reviewer who disagrees has to say what they disagree with and why, in a place where everyone else can see it and build on it. There is no nodding along. There is no "looks good" that evaporates the moment the meeting ends.
We run this on Atlas because the review lives on the project itself, with the tasks, the timeline, and the prior decisions one click away. A reviewer is never reacting to a summary of the work. They are reacting to the work, with the full record in front of them. That single fact removes most of the misunderstanding that used to eat our meetings alive. If you are curious how we structure the underlying projects, I have written about that elsewhere on the blog.
The decision that defaults to yes
The most important mechanic in our async review is the disagree-and-commit default. The owner does not ask for permission. They state what they intend to do and set a deadline for objections. If no one with the standing to object does so by the deadline, the decision is made and the project moves. Silence is consent, and that is intentional.
This inverts the usual dynamic, where a project stalls waiting for a meeting that will bless it. In the old model, the absence of a decision was the safe default, so things drifted. In the written model, the absence of a decision means the owner's recommendation stands, so things move. Reviewers learn fast that if they care about an outcome, they have to engage with the writing, on time, with substance. The lurkers who used to coast through the meeting have nowhere to hide, and the people doing real thinking finally get to do it without an audience.
What we got wrong first
Our first attempt failed, and it failed in an instructive way. We told people to "write up their projects" and post them, with no structure and no deadline. What we got was a wall of unread documents. Async work without a forcing function is just procrastination with extra steps. The reviews piled up, nobody felt obligated to read them, and within a month people were quietly asking to bring the meeting back.
Two changes fixed it. First, the response window. A review with no deadline is a suggestion, and suggestions get ignored. A review with a clear "decisions land Thursday at noon" creates the same urgency the meeting used to, without the meeting. Second, we got strict about who gets tagged. Early on, owners tagged everyone, terrified of leaving someone out, and the reviews drowned in low-value comments and bystanders feeling obligated to weigh in. The discipline of naming the three people who actually matter is the whole game. Async team collaboration does not mean everyone sees everything. It means the right people see the right thing at the right time.
We also had to teach people to write. This is the unglamorous part nobody warns you about. Moving to written reviews is, in practice, a writing-skills program disguised as a process change. A muddled meeting can be saved by a sharp person talking. A muddled document just sits there, muddled. For the first quarter, the biggest lift was not the tooling, it was helping owners learn to state a recommendation clearly, surface the real risk instead of burying it, and ask for a specific decision rather than vague "thoughts." That investment paid back many times over, because clear writing is clear thinking, and a team that writes well makes better calls on everything, not just reviews.
What changed, and what I would tell you to do
The headline result is mundane and exactly what we wanted: decisions got sharper and faster, and we got dozens of hours of senior time back every week. But the effect I did not predict was on the record itself. Every decision now has a written trail showing what we knew, what we chose, and who agreed. When a project goes sideways six months later, we do not relitigate from memory. We read what we wrote. New people onboard by reading old reviews and absorbing how we think. The reviews became the institutional memory we always pretended the meeting was.
If you want to try this, do not boil the ocean. Pick one project, write one review, name three reviewers, set a forty-eight-hour window, and use the disagree-and-commit default. Resist the urge to keep the meeting "just in case," because the safety net is exactly what kills the new habit. The point of better project management is not more visibility into the work. It is fewer, better decisions, made by the people who can actually make them, with the full context in front of them and a written record left behind. A room and an hour were never going to give you that. Good writing will.