Project-based feedback: review the project, not the person

The week after a project ships, a manager schedules a meeting and calls it a "project debrief" or "post-mortem" or "retrospective." Halfway through the meeting, it stops being about the project. It's about who made which call, who pushed back too late, who should have spoken up earlier. The person who shipped the work is now sitting in a meeting that started as a learning exercise and ended as a soft performance review. They walked in willing to share what they'd do differently. They walk out having heard their judgment questioned in front of three peers. Next time, they won't share what they'd do differently.

The fix isn't more psychological safety lectures. The fix is a structural one — keep the project debrief and the performance conversation in different rooms, on different days, with different framings. Conflating them is what makes most small-team retros either useless or quietly damaging.

Why "review the project, not the person" actually matters

The principle sounds like a slogan. Treated as one, it stays decorative. Treated as a structural rule, it changes what conversations are possible.

Three things go wrong when project debrief and performance review get fused into one meeting.

The project loses the actual lessons. A real project review involves looking honestly at the decisions made — which assumptions held up, which scope cuts cost you, where the timeline slipped and what triggered it, where the team coordinated well and where it didn't. Each of those lessons applies to the next project. Folded into a performance review, those same observations become evaluative ammunition. "We slipped the timeline because we under-scoped" becomes "you under-scoped." One sentence is a lesson available to the whole team. The other is a critique aimed at one person. The lesson version travels. The critique version makes everyone defensive next time.

The person loses the actual feedback. A performance conversation should be about patterns over many projects, behaviors that are reproducible, growth areas the person can choose to work on. When you compress it into a single-project debrief, you're evaluating the person on the basis of one observation window. That isn't fair to them — most of what shows up in any one project is situational — and it isn't useful to you, because you're not actually getting feedback on whether they're growing.

The team loses the willingness to debrief honestly next time. This is the most expensive cost. The team watches one project review get turned into a performance critique. They draw the correct conclusion: in the next retro, don't volunteer anything that could be used against you. Two retros later, the retro has become a ritual of vague acknowledgments. The team isn't lying. They've just calibrated to the room.

The Pixar Braintrust framing

The clearest articulation of "review the project, not the person" comes out of Pixar. Ed Catmull, in Creativity, Inc., describes the Braintrust — the standing group that gives notes on Pixar films in progress — and names the principle explicitly. The Braintrust has two operational rules. First, the notes are about the movie, not the director. Second, the director isn't obligated to take any specific note — but they are obligated to listen.

The first rule does most of the work. When a note says "the third-act pacing is dragging," that's a property of the movie, not a judgment of the director. The director can engage with it cleanly: agree, disagree, propose an alternative, ask for more specificity. Compare that to "you're letting the third act drag." Same observation, different recipient. The first one points at the film. The second points at the person. The first invites craft. The second invites defense.

The same shift works at scale on a small team. "The kickoff communication didn't quite land — half the team I talked to thought we were optimizing for X, the other half thought Y" is a project observation. "You didn't communicate the kickoff clearly" is a performance observation. The information content is similar. The conversation that follows is wildly different.

It also matters who's in the room. The Braintrust is curated specifically to be people who can give the note without making the director's job feel personally threatened. Pixar's deliberate design choice is that this isn't a meeting where evaluation happens — it's a meeting where the movie gets stress-tested. Evaluations of directors happen elsewhere, with different people, on a different cadence.

What "the project, not the person" actually looks like in a debrief

Three concrete moves separate a real project review from a covert performance review.

Talk about decisions, not decision-makers. Phrase every observation as something the project did or didn't do, not as something a person did or didn't do. "The timeline assumed three weeks for the API redesign and it took five — what did we miss in the estimate?" beats "you under-estimated the API redesign." The first is something the whole team can engage with. The second is something one person has to defend. The first might surface that three people misread the same complexity signal. The second pins it on whoever owned the spreadsheet.

Anchor to artifacts, not memory. Bring the actual decision documents into the room — the kickoff brief, the scope cut decisions, the timeline at week one vs week six. Discussing what the artifact said and what actually happened is structurally different from discussing what someone should have known or done. Artifacts don't get defensive. Engineering teams have institutionalized this pattern as the "blameless post-mortem," popularized by Etsy's John Allspaw — the same operational logic applies to projects in any function.

**Separate the "what" from the "who." ** When a project review surfaces something that's clearly about one specific behavior of one specific person, take that observation OUT of the project meeting and bring it into a 1:1 later. The information is real. It just doesn't belong in the room where the team is supposed to learn collectively from the project itself. Trying to address both in the same hour is what makes most retros into the muddy middle thing they become.

If you keep these three moves consistent, the team starts to trust the project debrief as a place where honest observations are safe. That trust compounds. By the third or fourth project run this way, people start bringing things up that they wouldn't have surfaced in a less safe meeting — and those are usually the most valuable observations.

How to phrase observations

The grammar of an observation is most of the work. Once you've decided what to say, the wording determines whether it lands as a project note or as a personal critique.

Use the project as the subject of the sentence. "The kickoff didn't establish clear ownership of the integrations workstream" puts the project at the center. "You didn't establish clear ownership" puts the person at the center. Same observation, different recipient. The first version is something everyone can think about. The second is something one person has to absorb alone.

Use the work, not the worker, as the object of evaluation. "The Q3 narrative was hard to follow" evaluates the artifact. "Your Q3 narrative was hard to follow" evaluates the author. Most of the time, the person who wrote the narrative knows they're the author. You don't have to name them to make the point land.

Notice the difference between description and judgment. "The team escalated the scope issue in week five" is a description. "The team escalated the scope issue too late" is a judgment. Lead with the description. Let the team draw the judgment together. Description-first observations land more cleanly because they don't ask anyone to agree with your interpretation before they can engage with the fact.

These small grammatical shifts seem like style points. They're not. They're the difference between a team that comes prepared to a debrief and a team that comes prepared to a deposition.

When the person is the problem

The principle isn't absolute. Sometimes a project went sideways because of one specific person's decision, behavior, or pattern, and pretending otherwise is dishonest. Two clarifications about when "review the project, not the person" stops applying:

Pattern beats incident. One missed call by one person in one project is a project observation. The same person making the same kind of call across three projects is a pattern, and a pattern deserves a direct conversation with that person — not in the group debrief, but in a 1:1, in plain language, named as a pattern. The principle says project debriefs aren't the right venue for that conversation. It doesn't say the conversation shouldn't happen.

Severity overrides venue rules. If something seriously wrong happened — a breach of trust, a meaningful failure of professionalism, a decision that put the team or the work at real risk — that gets addressed directly, on its own timeline, in private, by the person responsible for the relationship. It doesn't wait for the retro. Trying to make a severe issue fit into the project review format is a way of softening it past the point of meaning.

The principle is operating in the middle zone — the everyday observations about decisions, communication, scope, coordination, where most actual learning happens. That middle zone is much larger than most managers realize, and structurally protecting it is what makes the rare hard conversation easier when it has to happen.

The rhythm this fits into

Project-based feedback isn't a substitute for a rhythm of feedback overall. It's one rhythm within a small-company feedback model that has three or four rhythms running in parallel. (We've written more about the rhythm-based alternative to annual reviews — project debriefs slot into the "work cycle" rhythm there, alongside trust-capacity feedback and decision-cycle feedback. And the broader argument against the annual review ritual itself sets out what kinds of jobs reviews try to do and why none of them actually need the annual ceremony.)

In practice, the project review answers the question "what did the project teach us?" The performance conversation, run separately and on a different cadence, answers "what is this person learning and where could they grow?" Both are real questions. Neither one answers the other.

When the project review becomes a real round

For most projects, an hour-long group debrief plus a few one-to-one follow-up conversations is enough. For bigger projects — major launches, strategic initiatives, anything that ran longer than two months — the manager benefits from running a structured round in parallel: same questions to themselves about how they ran the project, same questions to a handful of people who were in the room, and a side-by-side comparison of where the views overlap and where they diverge.

That's what Mirorly fits. Our post-project retrospective template is designed exactly around the project-not-person distinction — it asks about decisions, communication moments, scope discipline, and the moments where the team either steered the project or got steered by it. You answer it about yourself first, then send it to the people who were in the work, then read the gap between your self-view and theirs. That gap is where the manager learning lives. (We've also written about how to ask for feedback after a project ends — the timing, who to ask, and the order of asking, which composes with this principle directly.)

The summary

Review the project, not the person. Most teams say it as a slogan. Pixar runs it as a structural rule. The difference is what makes the rule actually change behavior: the project is the subject of the sentence, the work is the object of evaluation, and the conversation about the person happens in a different room, on a different day. Get this separation right and your team will tell you things in retros that they would never tell you in performance reviews.