I was sitting in a review of what was, basically, a proof-of-concept — early work, intentionally rough. The team had built enough for us to see whether the mechanic idea held together, and the question we were supposed to answer was whether the direction was worth moving forward
I knew, precisely, what the meeting was for. I mean, I had helped set the review up, and then… In the middle of it, as we were looking at it, I started giving polish notes. On an idea we hadn’t even agree to move forward with. And, yes, I should have known better.
I could see things in the work that bothered me, and the part of my brain that has opinions just… took over. The notes were specific and, as far as the individual issues went, accurate. A lot of them would need to be addressed eventually.
But “eventually” was doing a lot of work in that sentence, and I blew right past it.
The team took the notes. They were professional about it, but I could feel the energy in the room change. They had brought rough work to get a directional read. What they heard instead was a list of reasons the rough work was not good enough.
I caught the mistake later, in the car on the way home. (I’d like to say I caught it in the room and corrected myself. I did not.)
The issues I saw were real. I had just brought a finish-quality standard into a direction review.
Accurate is Not The Same as Useful
I think we collapse those two things more often than we realize.
When someone notices a genuine problem in the work, it feels responsible to say it. That is especially true for experienced creative leaders. We have spent years building judgment around the things that go wrong, the details that undermine quality, and the risks teams sometimes miss until they are expensive.
Ideally, we’ve even taken significant pains to ensure that everyone feels safe to express concerns and issues.
So we see something, and we react.
The issue is that a correct observation is not automatically useful feedback for the decision in front of the team.
A rough concept may have weak transitions, inconsistent visual treatment, or details that would never survive a final pass. All true. But if the current question is whether the central idea is strong enough to develop, those notes may do nothing to help the team answer it. Worse, they can pull attention away from the thing the work was actually built to test.
The reverse happens too. A near-final campaign asset can come into review and someone decides it is a good time to reconsider the strategic direction. The concern may be legitimate. It may even reveal a problem leadership should have caught earlier. But the team cannot treat a foundational direction change like one more revision note and carry on. And, yes, I know from experience how trying to do that leads to a no-good-very-bad time.
Anyway, the timing and purpose of the feedback matter just as much as its accuracy.
This is where good reviewers can create bad outcomes without doing anything that looks obviously unreasonable. Each note makes sense on its own. Collectively, the notes send the team in several directions at once.
The Standard in the Reviewer’s Head
Even when a review has a clear purpose, people can still be using very different criteria to judge the work. The problem is not that anyone cares about the wrong thing. It is that the room may be protecting several different decisions at the same time.
I have seen this around milestone builds, prototypes, concept reviews, pitch materials, and early demos, mostly everything. It shows up just as easily in a campaign review. The creative team may be trying to find out whether the core direction is strong enough to develop. Brand is checking whether it stays inside the guardrails. A channel lead is already judging how it will adapt across formats. A senior stakeholder is reacting to whether they would feel comfortable showing it upward.
It is the same piece of work, but the room is applying several reasonable standards that have very little chance of reconciling themselves.
When we do not make the evaluation criteria visible, reviewers default to the standard that feels most important from where they sit. Their craft, their role, their memory of the brief, their anxiety about what could go wrong. Again… understandable. Also a fairly reliable way to hand the team a pile of notes that cannot all be true at the same time.
The team is then left to figure out which feedback actually counts and needs action.
What This Does to the Team
Rework is the visible cost. Conflicting notes produce a muddled revision, the next round comes back less coherent, and everyone gets a little more frustrated.
The damage to trust takes longer to show up.
When teams keep getting feedback from standards they were never given, they start protecting themselves from the review. They run work past individual leaders before the meeting so they will not be surprised in the room. They hedge toward safer choices. They spend time polishing things that were supposed to remain rough, because rough work has been punished before.
Eventually, the formal review stops being the place where the team honestly tests the work. It becomes the performance at the end of a series of private pre-reviews. That approach can honestly be useful for large decisions and pivots, but if you have to run that process for every review, it becomes an untenable slog.
I have watched this happen on teams where the reviewers were smart, thoughtful, and deeply invested in the quality of the work. Nobody was trying to create fear or confusion. But good intentions do not change how arbitrary feedback feels when the standard only becomes visible after the team has been judged against it.
That is usually when phrases like “the team still isn’t getting it” or “the work just isn’t there yet” start showing up.
Whenever I hear those now, I try to check the standard before assuming the team missed the direction. Did we ask them to build toward something specific enough to evaluate? Did the review use the same criteria? Or did leadership see the work, update the bar internally, and start responding from a new version of the assignment?
Sometimes the team did miss. Sometimes the work simply is not good enough. But we should be able to explain that against a standard the team recognizes, not a feeling that arrived when the work went up on the screen.
Understand Feedback’s Purpose… AND Context.
The practical move is not complicated, but it does require more than announcing, “This is a critique,” or “We are here to approve the concept.”
That tells people what kind of meeting they are in. It does not necessarily tell them what they are being asked to measure.
Before the work goes up, I would make the evaluation criteria clear in normal, non-robotic language: which judgment this version needs to support, what evidence or risks matter to that judgment, and what we are deliberately leaving for a later pass.
For that proof-of-concept review, the useful setup would have been something like: “We need to decide whether this direction creates the experience we were aiming for and whether there is enough here to justify a full execution pass. The work is intentionally rough, so let’s capture obvious finish issues, but we are not reviewing polish today.”
It tells reviewers where to spend their judgment. It also gives the person running the review a way to handle a valid note without either accepting it as current work or arguing that it is wrong.
That second part is important. A lot of review leaders only seem to have two available moves: take the note, or defend the work. There is a third option.
You can acknowledge the concern, decide whether it affects the current judgment, and route it accordingly.
If it changes the decision in front of the room, stop and deal with it. If it matters later, capture it somewhere visible with an owner or a future review point. The capture part matters because “we’ll come back to that” has a bad habit of turning into a line buried in meeting notes no one opens again.
And sometimes the feedback reveals that the agreed criteria were wrong. The work teaches us something we did not know, a technical constraint becomes real, or a stakeholder reaction changes the risk. That happens. Creative work has very little respect for the clean decision structure we planned for it.
The leadership move, then, is to say the standard changed.
“We thought this pass was enough to choose a direction. Seeing it made it clear we need another round focused on tone and feasibility before we make that call.”
That is not fun to tell a team that thought it was closing the decision. But it is much healthier than quietly grading the work against a new concern and pretending that concern was part of the assignment all along.
What I Should Have Done
I really wish I hadn’t dropped a ton of polish notes. I mean, the issues we real, but they just were not the work the team had been asked to solve yet (And the team was largely aware of them anyway, as solving them wasn’t the goal for that particular deliverable).
The next time I ran a review like that, I started by making the distinction explicit. We were there to decide whether the direction held together. Finish issues could be captured, but they were not the bar for that pass.
People still noticed rough edges, of course. Experienced reviewers do not stop seeing things because you ask nicely. But we had a shared way to decide what to do with what they saw.
That is the part I think leaders have to own.
The reviewer’s job is not simply to identify everything that could make the work better. It is to apply judgment in service of the current decision, while making sure useful concerns have somewhere appropriate to go. Occasionally that means holding back a correct note. I’ve even had to stop a review because a note changed the premise. Both require more judgment than handing the team a complete inventory of everything we noticed.
Teams can handle demanding standards. They can handle hard feedback, and they can usually handle the standard changing when the work reveals something new.
The part that damages trust is being asked to build toward one agreement, then discovering in the review that leadership was measuring against another.
The observation may be accurate. But once it is detached from the decision the work was built to support, it stops helping the team do anything useful with it.
Author note: I’ve spent my career leading and supporting cross-discipline creative teams, primarily in game development, with a focus on production clarity, alignment, and communication. I’m currently building AI-assisted planning tools for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.