How to Run a Project Review Meeting (and a Design Review)

Run a project review meeting by circulating the material at least two working days ahead, opening with the decision you need rather than a status recap, timeboxing each open question, and closing with named owners and dates. A review that ends without a decision was a status meeting with a more serious title.

Design reviews and project reviews are forward-looking: they exist to settle something before the work continues. Retrospectives and blameless postmortems look backwards at work already done and run on different rules, so nothing below applies to them.

Design review or project review: two different meetings

A design review decides whether a proposed technical approach is sound. A project review decides whether work already underway should continue as planned. Teams that treat “engineering review” as one meeting end up with a room half full of people who have no stake in the question.

	Design review	Project review
Question it settles	Is this the right way to build it?	Should this carry on as planned?
Called by	The engineer or team proposing the design	The person accountable for delivery
Core attendees	Author, owners of the systems it touches, one approver	Delivery owner, one voice per workstream, whoever controls budget or people
Pre-read	The design document	Progress against plan, risks, decisions needed
Typical length	45 to 60 minutes	30 to 45 minutes
Exit conditions	Approved, approved with conditions, or rework with named concerns	Continue, change scope, change the date, or stop
Cadence	Per significant design	Fixed interval, or at phase boundaries

The exit conditions are the part worth copying. A meeting with no defined ways to end will find one anyway, usually “let’s pick this up next week”, which is the only exit that costs a fortnight.

Who calls a review, who can block it, and who decides

Four roles need naming before the invite goes out: the caller, the required reviewers, whoever holds a block, and the single person who decides when the room does not agree. Most advice stops at “get the right people in the room”, which is precisely the part nobody can act on.

The caller is whoever wants something decided. They own the pre-read, the agenda and the follow-up. This is not a rotating chair duty handed to whoever is free that week.

Required reviewers are the people whose absence means the meeting is rescheduled. Everyone else is optional and should be told so in plain words. An invite listing twelve people and requiring none of them is the reason none of them prepare.

Blocking rights should be narrow and written down. A reviewer can reasonably block on security, data protection, backwards compatibility, on-call burden, or a commitment already made externally. Personal taste and “I would have done it differently” are comments, not blocks. Require that a blocking objection state what would resolve it. An objection with no stated remedy is an opinion with a veto attached.

The decider is named before the argument, not after it. Consensus is a good outcome and a poor mechanism, because when it fails the decision defaults to whoever is most senior or most persistent, and neither correlates with being right. On a design review it is usually the team who will operate the thing once it ships, not the manager who booked the room.

Put those four names on the invite. It tells everyone what their attendance means.

How to run a project review meeting

1. Write down the decision the meeting exists to make. One sentence, in the invite. If you cannot write it, what you want is a status update, and a status update should be a document.
2. Circulate the pre-read two working days out. Include the specific question each required reviewer is being asked. “Please review” gets skimmed on a phone; “Priya, does the migration window clash with the billing freeze?” gets answered.
3. Open with the decision, not the recap. Spend the first two minutes on where the meeting has to get to and what happens if it does not.
4. Timebox each open question and hold the box. When a discussion needs data nobody has, park it with an owner and a date rather than reasoning your way through it live.
5. Take a position from each required reviewer. Approve, approve with conditions, or block with the condition that would clear it. Silence recorded as agreement is how a reviewer ends up objecting in a pull request three weeks later.
6. Record decisions as they are made. Decision, decider, date, and the options rejected with the reason.
7. Close the loop within a day. Actions go into the tracker with owners, not into a notes document only the author reopens.

Step six is where teams leak the most value. A record written afterwards is written by one person from memory, and the reviewers who disagreed are no longer there to argue with it. Some teams move the capture into the channel where the argument already happens: Projan, for instance, presses for a named owner and a date against each unresolved concern during the discussion, then exports the agreed actions to Jira or Linear. Either way, a working decision log beats polished minutes.

Who performs design reviews?

Design reviews are performed by the engineers who will have to live with the design, plus at least one person senior enough to say no. Not by a committee, and not by the author’s manager alone, which tests for career risk rather than design risk. A workable room:

• The author, presenting and answering
• One owner from each system the design calls, changes or depends on
• A staff engineer or tech lead with authority to approve
• Security, where the design touches authentication, personal data or a new external surface
• Whoever carries the pager for the affected service
• Anyone who wants to learn, on the explicit basis that they do not block

Six or seven people is comfortable. Past ten, the meeting becomes a performance and the quiet reviewer with the real objection stays quiet. Where a written process already exists for larger proposals, the review sits at the end of it, and the RFC process sets out who signs.

What to do when nobody has read the pre-read

If more than one or two required reviewers arrive unprepared, convert the first fifteen minutes into silent reading with comments open. Reading a design document aloud is the most expensive method of file distribution ever invented, and it buys agreement from a room that has had four minutes to think.

Four things reduce the problem:

• Cap the length. A design document beyond about six pages will not be read by busy people. Put the decision and the trade-offs at the top, detail in appendices.
• Ask each reviewer a specific question, in the invite, by name. Generic requests get generic attention.
• Make the reading block permanent if the team consistently arrives cold. It is cheaper than a second meeting and much cheaper than a bad decision.
• Fix the list rather than the people. A required reviewer who never reads is not a required reviewer. Change what is expected of them, or take them off the list.

The temptation is to treat this as a discipline problem. Usually it is a scheduling one.

Who is responsible for API testing?

The team that owns the API is responsible for testing it. QA can design the approach, build tooling and add coverage, but accountability for a broken contract sits with the service team, not with whoever last ran the suite.

The layers split like this:

• Unit and contract tests: the implementing engineer, in the same pull request as the change
• Consumer-driven contract tests: owned by the provider, with consumers publishing their expectations
• Integration and end-to-end: shared, with a named owner per suite, otherwise nobody fixes the flakes
• Load and security testing: often specialist support, still signed off by the service owner
• Exploratory and release regression: QA where the function exists, the team where it does not

Settle this in the design review rather than at release. Ask which layers will exist and who writes them, because “QA will cover it” names no one. It belongs in an API design review alongside versioning and deprecation.

Frequently asked questions

How do you conduct a review meeting without it drifting into status? Chair it against the decision, not the agenda. State the decision at the top, hold each item to its timebox, and when a discussion needs data nobody has, park it with an owner and move on. Ask for positions rather than opinions. If the decision is made in the first ten minutes, end the meeting there.

How long should a design review be? Forty five to sixty minutes for a design of real consequence, with the document circulated beforehand. Anything shorter tends to approve on vibes; anything longer usually means the design was not ready or the room was too big. If you need a second session, book it for a specific unresolved question rather than a general continuation.

Can a design review be done asynchronously? Yes, and most should be. Circulate the document with a comment deadline and a named approver. Call a synchronous session when the comments start disagreeing with each other rather than with the author, when the decision is expensive to reverse, or when a reviewer has raised a blocking concern that needs negotiating rather than answering.

What should the written record of a review contain? Four things: the decision, the person who made it, the date, and the options rejected with the reason. Add any conditions attached to an approval, and the owner of each one. Discussion summaries age badly and nobody reads them. A reader six months later needs to know what was decided and what was ruled out.

Review meetings fail on ownership far more often than on agenda design. Name the caller, the required reviewers, the people who can block and the one person who decides, then hold the meeting to an exit condition rather than to the end of the hour.