It’s not just “Scope Creep”

What I've learned over the many (so many) years I've been doing this is that this drift is more than simple scope creep or a slip. Those are part of it, of course, along with the accretion-based shifts, emergent issues, development problems, and all the other issues we face in our day-to-day work.

So, more specifically, the drift is when we set a baseline for a milestone and plan to deliver A, B, and C. But by the time we deliver the milestone, we've done A, concepted B, realized we can't do C until we do D, which is now about halfway done, and we managed to get a jump on M, which is now nearly done.

I believe all this can be mitigated and managed, but I don't think it can be avoided. It's inherent to the creative work. There's simply so much we don't know when we start a milestone. The core issue is, regardless of the drift, there's still work to finish, gates to clear, and a ship date to hit.

The challenge is, while we can get a sense that drift is happening, and we can adjust our tasks and user stories (ideally sprint-by-sprint, but we know how it goes sometimes) to manage through it, but we often lose the big picture.

The Firehose

Even with good process and flow, there's just so much information coming in via slack, email, meeting notes, documentation, playtest feedback, telepathy, Morse code, singing telegrams, and a thousand other things that we can lose the thread. Leaving the team to try to reconstruct the changes, decisions, and shifts so that the next milestone can build on that to keep the project as a whole, headed in the right direction - towards the gates and ship.

You Can’t Just “Out Process” It.

In my experience, the fix isn't more process (believe me, I've tried). It's keeping a good record of what changed and (crucially) why it changed - kept up-to-date as those changes happen (or get discovered) so that there's clarity, good old-fashioned alignment, and a means to help keep the most critical aspects of a milestone on rails, so you can keep the game on track to actually ship.

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 built DriftWarden for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.

Subscribe now

The Mismatch

I realized it's because in my world, the Accountability element is often split between the director and the producer. Generally, the director is accountable that the work is good, and the producer is accountable that it's delivered on time.

I've found it doesn't usually divide that cleanly. Good directors and good producers have some reach and impact in the other domain. Good directors have some sense of the cost, risk, and time of what they ask for, and good producers have the sense and taste to help ensure the work is hitting the quality bar. I think this crossover is incredibly useful when done well, but it does make things more complicated.

After banging my head against it for… a while. I finally figured out that what helps is having the duo build a shared definition of done for the work that accounts for both the quality bar and target AND deliverable timing and requirements. And that is built collaboratively with each other and the team.

The Complication

Nowadays, that is still applicable, but it's often only part of the solve. When we add co-dev partners to the equation, it adds (surprise) yet another layer of complexity. Because this same split is mirrored within the co-dev partner, meaning all those challenges of shared, but split, accountability are multiplied.

I've seen folks try to solve this with raw brute force documentation. I've found that it typically starts okay but goes to cra… er, goes downhill… fast. The documentation gets out of date as decisions are made, actions are taken, and the project moves forward. It can work, of course, but only if the documentation is treated as a "living thing" that is updated (and refocused) regularly so that it at least resembles reality.

Communication Is The Key

Documentation is one approach, but fundamentally, communication (in whatever form it needs) is what's critical.

Regardless, whatever process you use, the key is to make sure everyone on the team - including co-dev and outsource partners - are aware of what "good", "delivered", and "done" look like, and they stay updated as those change.

Which is admittedly harder than it sounds.

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 built DriftWarden for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.

The Problem.

The issue (aside from that that approach completely eroding trust and psychological safety) is that it doesn’t actually get you anywhere, improve things, or course correct. It’s just a full stop, which is gonna lead to stalls, frustration, confusion, and host of other “very bad things”.

For clarity, the problem isn’t the “No”. Artfully saying “no” is a key part of our jobs, it’s how we can keep our production on track. But, that “No” alone is not enough to get the best input from your stakeholders, best work from your team, and the best deliverables from your partners.

Look Beyond The Ask

While I’ll go into some specific approaches, there’s an important first step common to all of them. And that’s taking a moment “look beyond the ask”. And I get it. I know what it’s like to be 3 days from a deliverable and someone asks to just “add this one small thing.” I know the frustration there. In that very moment, you can feel that “no” bubbling up, ready to detonate in an explosion of exhaustion and fury.

But stop. Take a deep breath (or three) and get curious. Why does this person want to add this “one thing?” What’s that trying to solve? What’s it trying to do? There’s almost always a reasonable rationale behind the ask (even if the timing isn’t rational) besides “but it would be sooo coooolllll”

Understanding that underlying “why” can make it much easier to say “no” in an artful, constructive, and collaborative way - that won’t make the person hearing “no” want to immediately set you on fire.

Subscribe now

What’s Needed When Speaking to Stakeholders

Okay, let’s focus on what’s needed when we have to say “No” to our stakeholders. This, often, is not easy. So, from my experience, you want to come with a frame of options and consequences.

So, let’s say your stakeholder comes to you 3 days before your deadline and wants the team to add a whole new character class. After the horrible realization that they’re not kidding settles in, you can approach them with the consequences.

“We can do that, but we’ll either need to delay the milestone by 2 weeks, or we can punt the combat work, but that will still likely push the milestone by at least 1 week.”

Then, bring in some options.

“As some options, we could front-load the new class to the beginning of the next milestone, and it will be in for a playtest in about 2 more weeks. Or, we could likely get some initial design and concept work started now, with minimal disruption to the current milestone. Or, we could finalize the latest combat update we’re doing, run those playtests on the current classes, and see if that impacts what you want to do with the next one.”

If you know the “why” behind their ask, it helps you tune those options so they address the fundamental concern (or likely concerns) that your stakeholders have.

What’s Needed When Speaking to the Team and Partners

When you have to say “no” to your team or to your partners, the main thing you need to frame is context. This drives a couple of important things.

First, it helps surface miscommunication or misunderstanding. When you heard them say “We want to fix the fighter class, you may have envisioned a ton of work to refactor, rebalance, and iterate. What they actually meant was, “we just want to fix the name so it says ‘warrior’ rather than ‘fighter’ in the class selection UI. Those are two very VERY different scopes of work.

Second, it can help surface easier solutions. An outsource partner, for example, might want to get a jump start on a new NPC, they want to shuffle things around so they can start concepting now. But, that’s not actually necessary because your core team has an entire NPC kit, lore, and concept art already ready to go - your partner just wasn’t aware.

Always remember. Communication is hard.

Anyway, framing the “no” with context can often help you find better solutions and line up better approaches than the “no” by itself. In short, it fosters collaboration, rather than shutting it down.

Which leads me to…

Collaborate Don’t Dictate

In both cases (talking with stakeholders and talking with your team & partners) you want to find a way to collaborate to find the actual best outcome. In the case of your stakeholders, there may be strategic elements driving their ask you’re unaware of; similarly, in the case of your team and your partners, it’s almost assured that they will know, better than you, the specifics of implementation.

So, it’s not really in your (or your project’s) best interest to simply dictate the answer. This seems straightforward, but in the moment it can feel like “decision”. It’s not. Not really. It’s a mandate.

A Mandate is:

No, we can’t do X, we’re going to do Y.

A Decision is:

No, we can’t do X. I’ve listened carefully to your thoughts, I think I understand what you’re trying to do, given all that, we’re going to do Y.

The outcome is the same, but when making a decision (rather than dropping a mandate) the others are part of the process - and you at least are making a decision with as much information as you can get.

But… Keep Goals and Requirements In Mind

Now, one thing I’ve fallen victim to (many many times) is getting so caught up in figuring out “how and when” to do a thing, that I don’t stop to really figure out IF we should do a thing. You can find the absolute perfect plan to squeeze in time to improve the texturing and normal maps on the exterior of a building. But, if that building only shows up in the background, in the skybox, blurred by depth of field, in one shot of a cut scene, that lasts less than one second… Should you find the absolute perfect plan to squeeze in the time?

Takeaways

So, if you take nothing else away from this, take this: “No” isn’t a complete sentence, but it can be a complete conversation.

Get curious before you get to "no." That flash of exhaustion-fury is real, but it's a bad advisor. Take a breath (or three), and ask why. There's almost always a reasonable rationale behind the ask, even when the timing is nuts. Find that "why" and everything after it gets easier.

Match your frame to your audience. For stakeholders, lead with options and consequences — show them the fork in the road instead of a brick wall. For your team and partners, lead with context — it surfaces the miscommunications and the easier solutions you'd never find otherwise. Same "no," but two very very different toolkits.

Make a decision, not a mandate. The outcome can be identical — “we’re going to do Y” — but how you get there is the whole game. A mandate shuts people out. A decision brings them in, and gets you the best information you can possibly have before you commit.

Check the “if” before the “how.” Don’t fall into the trap I fall into constantly: building the perfect plan to squeeze in work that shouldn’t happen at all. Before you figure out how and when, stop and ask should we. Protecting your team’s time from low-value work is just as much a part of the job as protecting the timeline. (Sorry, one-second skybox building. You’re not getting new normal maps.)

Lastly. Yes. This is more work.

Framing a “no” well takes more effort up front than just saying it. But a blunt “no” burns trust to buy a little short-term relief, and you pay that back later with interest — in rework, in stalls, in people who stop bringing you the good stuff. The framed “no” costs you a few minutes now and saves you all of that.

So next time you feel that “no” bubbling up, ready to detonate — catch it. Ask one “why.” Then watch how different the conversation goes.

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 built DriftWarden for creative leaders who need to turn ambiguous direction into execution plans their teams can actually use. You can connect with me on LinkedIn.

Take an ask like this: Can we improve combat readability?

I’d be careful dismissing that as scope creep, particularly if combat is part of the milestone. It might be the exact right question or feedback. It’s also the kind of thing that’s hard to see until a build can be played, and harder to solve without knowing what’s actually broken.

So the co-dev studio says yes.

Of course they do. They want to be a good partner. They probably agree with the feedback — chances are they already saw the problem. And in that moment, the ask still feels close enough to the milestone that nobody wants to make a formal thing out of it/

Then the work starts. And so does the pain.

Subscribe now

As they start “responding to the feedback”- mid-milestone - “Improve readability” turns out to mean adjusting animation timing and VFX. Then, that uncovers that enemy silhouettes need more clarity. So, they fix that, and attention shifts to camera distance, encounter layout, tuning, lighting, UI support, audio cues… (and tigers, oh my!)

The sneaky, infuriating thing is that this doesn’t happen all at once — that would at least allow for obvious, clear, plan changes. But, nope. It arrives one reasonable discovery at a time, coming in as an innocuous line in Slack or a fraction of an update in a meeting. Nobody did anything unreasonable. But the milestone shifted.

That’s what I mean by Iterative Drift. All those changes that look small, legitimate, and basically in scope — but the iteration required to satisfy them uncovers more work, more questions, and more decisions than the milestone was originally holding.

The problem isn’t the feedback or the ask. It’s the missing “why.”

As I’ve said, “Improve readability” is reasonable feedback. But… It is not enough context to make a good production decision.

Digging deeper, the actual core issue - Players missing attack animations, muddied VFX, and/or combat that’s simply too dense are three completely different problems with three completely different fixes. If the co-dev team only has the surface request, they can still do the work — it’ll just take longer and stands a much better chance of missing, because nobody equipped them with the detail they needed.

This cuts both ways. Co-dev studios sometimes under-ask for direction; I understand the pressure, because nobody wants to sound defensive or turn every note into a negotiation. And core teams — and by “sometimes” here I mean “most times” — under-communicate the reasoning behind the feedback in the first place.

The “why” is critical production information. The biggest impact usually isn’t in saying no. It’s in making the yes more informed.

The milestone changes before anyone calls it changed

Here’s the part that really bites: we rarely stop to acknowledge that the milestone has actually changed. And that gets easier to miss the more distributed the work is.

As an industry, we’re leaning harder into co-dev, and that makes the org chart of a single milestone genuinely complicated. The core team owns product direction. The co-dev studio owns a meaningful slice of implementation. Another partner owns art or UI or audio. And the feedback itself might come from a publisher, an exec group, or a creative director who wasn’t in the room when the milestone was shaped.

That can absolutely work. But it means the agreement now lives across a lot of people who each see a different slice through a different lens.

So even when Jira or Asana gets updated with the new tasks, the *reason* behind the change doesn’t. The decision trail lives in half-remembered conversations and buried Slack threads — which, I probably don’t need to tell you, isn’t great.

That’s not a swipe at anyone’s memory. Memory is just a bad place to store production agreements. People retain the part of a conversation that mattered most to the problem *they* were carrying. Then review day arrives, and the team isn’t just asking whether the milestone was delivered. They’re trying to reconstruct what “delivered” even came to mean.

A sharper question than “is this in scope?”

“Is this in scope?” isn’t a bad question. It’s just not always sharp enough. In game dev, a request can be technically in scope and still change the amount of iteration, risk, or review expectation enough to matter.

So here’s the question I’d add:

Does this change what the milestone is being asked to prove?

If no, keep moving. Don’t turn it into paperwork.

If yes, then for the love of all that is sweet and pure, make the decision visible. Using the running example, that might sound like: Yes, we can improve readability — but if the goal is player comprehension, there’s a simpler path than pushing this all the way to final presentation.”

That sentence is exactly the kind of thing co-dev teams should feel empowered to say more often. The combat note might be essential to proving the loop — great, do it. Or it might quietly move the milestone from “prove the loop works” to “show the loop at a higher presentation quality than we planned for this stage.” That may still be the right call. It just needs to be a call, not a drift.

The lightweight fix: a two-minute decision record

None of this requires a change-control ceremony. I know we, as production leaders, have enough of that kind of thing on our plates, we don’t need more. Besides, ceremony like that is the version of milestone discipline creative teams rightly hate — the one that treats the original plan like sacred text and turns every idea into a form to fill out. Iteration isn’t a nice-to-have in game development; it’s the job. A baseline that stops the work from changing is worse than useless.

The baseline isn’t a brake. It’s a reference point — the thing that tells you whether you’re iterating inside the milestone or changing it.

So when an ask or feedback clears the “does this change what we’re proving?” bar, I just capture three lines:

• What changed: Pushing combat readability past comprehension toward presentation polish.

• Why: Playtest review flagged players missing telegraphs; publisher wants it demo-ready.

• What it now proves: Loop clarity and first-pass combat feel — up from loop clarity alone.

That’s it. Thirty seconds to a couple of minutes. It gives the next reviewer the context they’d otherwise be missing, it gives the partner studio a sharper target, and it gives you something better than memory when the milestone gets reviewed two weeks later.

The trigger for writing one is simple: if the change touches acceptance, test time, partner dependencies, review expectations, payment, or follow-on work, it’s earned three lines.

The takeaway

Iterative drift isn’t a failure of collaboration. It’s usually a side effect of collaboration moving faster than the record of what was agreed. The fix isn’t to make teams less responsive.

It’s to get precise about the one moment that matters: when a reasonable ask quietly becomes a changed commitment — and to write down the “why” while everyone still remembers 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 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.

I’ve done this enough that I should have known that it wouldn’t be as simple as that. Sure, it looked like a pretty clean line in a scope document. It’s clear, simple, and seemingly straightforward. Design can explore a few ideas, throw out the ones that are obviously too large, and move the remaining options into implementation.

We try a few, then throw them out because they’re terrible. Then, finally, one of those abilities shows promise, and we get it to something like 80%.

Yay. It works. The base idea is there, demonstrable and reviewable. But once the team can actually try it… It begins…

We see the ability needs one small new thing to make it read properly. Nothing especially alarming on its own, so the team starts working through it.

But that, then, creates three more things.

Now I have engineering needs that were not in the original plan, new animation and visual-effects work, and another balance pass. The player strategy around the ability changes too, which starts affecting how it fits with other parts of the game.

Here’s the tricksy part - The team is still building two hero abilities. Nobody added a third. On paper (or, more likely, a spreadsheet somewhere) the scope hasn’t changed.

The work and requirements, though, absolutely have.

Subscribe now

The two abilities are still two abilities

And here, we get a first hand view of what makes scope difficult in creative work. We tend to describe it through the visible units: two abilities, three concepts, one campaign direction, a prototype, a trailer cut, a set of launch assets.

Those units are useful for planning… And are also a fairly incomplete description of what the team is being asked to solve.

Looking at the abilities, for example. Design was trying to hit the goal and trying to stay within the lines. Two abilities. None started just adding or building random features. We ideated, playtested, and the team learned something by making and trying the work. An idea that seemed contained in planning turned out to need more support before it could do its job.

That is normal. Honestly, I think it is rare that the exact right decision or boundary is defined at kickoff. The initial definition gives the team somewhere useful to start. Then the work teaches us things.

Where we can fail on the leadership side is not seeing or acknowledging that the assignment and plan changed based on what we learned.

If the additional engineering, animation, effects, balance, and strategy work is necessary for the ability to succeed, taking it on may be the right call. But it is still a call. The cost does not disappear because the new work arrived one reasonable piece at a time - though, admittedly, it can make it much harder to see.

This is why I have a hard time treating scope as a project management activity. Production can show the schedule impact, track the additional work, and help the team understand what is moving. Someone still has to decide whether the new work belongs in the current commitment.

That decision is leadership.

Scope is the agreement we keep updating

We need to stay focused on clearly asking what is in and what is out. We really need to be asking that consistently across a deliverable, phase, or milestone.

That seems nice and clear-cut in a sentence. In reality, though, for creative leadership, it’s super messy. The in/out boundary depends on several other agreements: what the current work is meant to help us decide, what level of quality that decision requires, which risk we are trying to expose, and what we are deliberately willing to leave unresolved.

Those agreements do not need to be perfect at kickoff (I’m not sure they can be). They do need to be visible enough that we can tell when new information has changed them.

Going back to my ability example, “make it read properly” might be essential. If players cannot understand what the ability is doing, the team may not be able to evaluate whether the design works at all.

Or that extra readability could be a finish problem attached to an ability whose central idea has not earned more investment yet.

Both are possible. The task list alone will not tell us which one is true.

We have to go back to what the current work is supposed to solve, prove, or help us decide. Then we can ask whether this new thing changes that decision, supports it, or belongs to a later pass.

That is scope in practice. Not defending the original list because it was written down, and not accepting every new need because it appears valid. It is keeping the agreement current as the team learns - while also keeping an eye on the big picture and timeline.

“One small new thing” needs a conversation

To be clear, I don’t think the answer is to make teams escalate every adjustment. That would slow the work to a crawl, and most small implementation decisions really should stay with the people closest to them. It would also make myself and everyone on the team miserable, which I tend to classify as “a bad thing.”

What you want to keep your radar tuned to are phrases like “Oh, it works, we just need one more thing.”

Sometimes we do just need one more thing. But then sometimes (and by sometimes, I mean most of the time) that one thing is the beginning of a chain the team cannot see yet.

Before absorbing it, I want to understand what the new work is supposed to solve. Is there a smaller or faster version we could try? What is the smallest test that would tell us whether the idea is working? How will we recognize that we have reached a dead end rather than continuing to feed the work?

I would also want to know which design or product pillar the new work supports. If we cannot connect it to something the project has already decided matters, that does not automatically make the idea bad. It does make the decision to pursue it less obvious.

And then there is the question creative teams often avoid because it is the least fun one: what are we going to give up to get this done?

Everything is a tradeoff. Maybe the answer is time. Or, we have to settle for less polish on another part of the deliverable. It’s possible the right call is to cut or push one of the two abilities. It’s also possible, based on the playtesting, that we as a leadership group, need to settle on some schedule risk because the ability proved so promising.

The flip side is, that it’s also possible that nothing has to move. Teams sometimes have room, and not every addition creates a crisis.

But we should understand that before the work quietly becomes part of the baseline.

A change can be right and still create drift

From a leadership and production perspective, the uncomfortable reality is, we often have to accept change. But each accepted addition or change moves the milestone a little further from the target we originally planned against.

Again, that might be correct. The original target was based on what we knew before the team did the work. If implementation reveals a better answer, I do not want the team trapped by an outdated plan just so the scope document stays clean.

But every one of those changes carries something with it: more risk, schedule pressure, different deliverable content, or a change in when the milestone can actually be considered complete. Often more than one.

When we accept the change without naming those effects, we lose track of how the milestone drifted and why. A few weeks later, the work is noticeably different from the baseline, the timing no longer makes sense, and everyone has a slightly different memory of when the commitment changed.

There usually is not one dramatic scope decision to point at. There are ten small ones, each reasonable in the moment.

That’s what we as leaders and production-folks have to keep visible.

The goal is not to prevent drift at all costs. Creative work changes because teams learn, and sometimes the learning should change the plan. But, we have to understand when we have made that choice and carry its consequences into the rest of the project, and understand what that means and what the impact is (or could be).

The work is going to teach us something

A good scope gives the team a useful starting point - and, ideally, some breathing room. It names enough of the current agreement that people can make progress without waiting for leadership to answer every possible question in advance.

Then the team gets started on the plan, and reality, annoyingly, has to butt in. Stupid, stupid, reality.

Once that happens (which for the game industry is typically 4-5 pico seconds after work begins), scope becomes an ongoing leadership practice. We have to decide whether new information changes the current decision, whether a smaller test would tell us enough, what the additional work supports, and what we are willing to trade for it.

If we choose to expand the work, we should name that choice. Update the target. Show the effect on timing, risk, and the rest of the deliverable. Capture why the decision was made while people still remember.

The two hero abilities may still be the right commitment. They may even be better because the team followed what the work revealed.

But by the time one small addition has become engineering, animation, effects, balance, and strategy work, we are no longer managing the scope we wrote at kickoff. We are making a new agreement.

Leadership needs to own that agreement while there is still time for the team and the plan to respond to 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 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.

What I’ve seen happen, particularly in experienced teams that are running to a perceived goal, is that as they view that work, the deliverables, and the targets through their own lens, what they’re aiming at starts to shift. To make matters worse, from a production and creative-ops perspective, that’s not all bad. I know I’d much rather the team work to solve the problems that come up during development than to just freeze up or stall.

The downside, though, is that over time, those micro pivots and seemingly small direction shifts add up and compound. And then we end up in a meeting early Friday afternoon where your designers walked through a change they’d made — and it’s a good change. Art’s response to it also made sense, because it’s what art is supposed to do when design shifts. Engineering, meanwhile, had bumped into a small constraint they’d worked around in a way that, honestly, ended up cleaner than the original spec. Every discipline had something to report, all of it was reasonable, and none of it looked worth flagging.

Yet, by Monday morning, we feel that something is off. We’re not actually building the thing we said we were going to build.

It’s not vastly different, and shifts were subtle (but additive) so those one-to-two-degree shifts in direction now have us thirty degrees off the kickoff target - enough that if we set the current state of the work next to the original commitment, the difference is clear.

And everyone who was in the meeting helped get us there - one small good decision at a time.

Drift Isn’t the Same as Misalignment

I want to be careful with the vocabulary here, because “alignment problem” gets used to mean a bunch of different things, and they don’t all need the same fix.

There’s the clarity version — people leaving the same conversation with different interpretations of what got decided. That’s a real problem, but it’s a different one, and I want to hold it for another piece.

This specific issue is drift: a team that was genuinely aligned at kickoff and then, over the course of just doing the work, ended up somewhere they didn’t agree to go. It’s a slow-burn issue paved with good intentions the entire way, with small execution decisions. Time after time. Looked at in the moment. All ended up driving the development off course.

And I don’t think this is specific to any one kind of creative work. Anywhere different disciplines are shaping the same deliverable - brand campaigns, launch creative, animated pieces, milestone builds - the same drift is available. The artifact changes; the underlying problem doesn’t.

The Dangerous Decisions Are the Reasonable Ones

If drift only happened through bad calls, it’d honestly be a much easier problem to catch. Bad calls typically create friction, so somebody flags them and pushes back, then room (or commonly a Slack thread - or six) has a conversation, and the decision gets revisited.

Drift moves through the small, reasonable decisions - the ones that don’t feel worth escalating in the first place. Each one, in isolation, is the kind of call I’d probably approve if someone asked me. The catch is that nobody’s asking, because from where they’re sitting, the call looks small enough to just make on the fly and mention later, if it comes up at all. They’re pushing hard to their goal, and making the call lets them keep their momentum.

That’s not a criticism - it’s just how cross-discipline work has to move. If every design tweak and art pass and engineering workaround needed a leader in the loop, nothing would ship. Teams have to make these calls without you all the time, and that isn’t the problem.

The problem is that individually reasonable calls, in aggregate, absolutely change what the finished thing is going to be - not in obvious ways, just… a little. And A little at a time, across a handful of disciplines, across three or four weeks, adds up to something that no longer really matches the commitment.

By Friday, the work is still coherent. It just isn’t the work you said you were building on Monday.

Status Meetings Aren’t Built for This

Status meetings are actually pretty good at what they’re designed to do. I want to be fair about that. If you run a decent one - people report what they got done, what they’re working on, what they need - and the plan you’re tracking against is roughly current, you’ll leave the meeting knowing whether the team is on track by the definition you set.

But the definition you set is exactly the thing drift changes.

Which means a drifted team will still report on track, because from where they’re sitting, they are on track. They’re on track to deliver the thing that the accumulated decisions turned the work into. They’re just not on track to deliver the thing you all agreed to at kickoff - and nobody’s actively tracking that version anymore, so nobody sees the gap.

That’s why status is basically blind to drift. It fundamentally assumes the target hasn’t moved. Drift is the target moving.

I’ve watched teams (and, sure, run teams) where three weeks of clean green status reports lined up back to back, and the milestone review was where we all figured out together that the work no longer matched the commitment. Which is a real bad place to have that conversation. Everything about a milestone review (the audience, the expectations, the goals) is set up assuming we’re going to talk about how well we hit the target. Not renegotiating what the target actually was.

Subscribe now

What Leadership Actually Owes

The answer is less about a process fix and more about habit, and it’s uncomfortable enough that I’ve watched a lot of experienced leaders (myself included) skip it, or do it inconsistently, or do a version of it that doesn’t quite work.

It’s got to be done though. We owe it to our teams to - at some cadence, separate from status, ask a different question. Not “What did you get done this week” - we already have that answer from status. What we don’t typically probe is: “What decisions were made this week that would have been worth calling out?”

That question is uncomfortable, because on the surface it can sound like an accusation, or micromanaging. It’s not something I would likely actually vocalize. I’d use it more as a rhetorical frame when I chat with my leads. It’s a viewpoint we can use to help surface the calls that are, over time, changing what we’re all actually building.

This is not about asking anyone to escalate every decision. Just taking the time to look more deeply to notice the ones that would sound different if we all heard them for the first time now, in a kickoff meeting, rather than as one of forty little adjustments made along the way. That’s where the drift hides.

I’ll admit, I don’t have a great name for this discussion, or check-in, or whatever you want to call it. I’ve called it different things in different places, and honestly none of them have really stuck. The name isn’t the important part. The important part is that you’re working with your team to look at the work differently than pure status, and that you do this before the milestone review becomes the accidental place drift gets surfaced.

Related to this - from experience, one thing that seems small but really isn’t: You gotta capture the answers somewhere the team can find them again. Drift conversations have a way of dying inside meeting notes no one ever revisits, and then you get to have the same conversation six weeks later, at a much worse time, and it feels like you’re noticing the pattern for the first time - even though you’d actually seen it before.

What It Costs to Not Do This

The visible cost is the stuff you can measure - rework at the milestone, missed dates when the actual work has to snap back to what was committed, uncomfortable conversations with a stakeholder who’s now looking at something noticeably different from what they were pitched.

The less visible cost is trust in the plan itself, and that one is harder to catch, because you mostly notice it after it’s already gone. Teams that keep experiencing the “we’re on track… oh, wait, we aren’t” pattern don’t make a decision to stop trusting the plan. They just kind of absorb it as how things go around here. And they start protecting themselves - hedging their own commitments, treating kickoff as directional rather than binding, holding a little back so the eventual reset doesn’t hit as hard.

That’s the point at which the leadership job changes underneath you, and it’s a lot slower and harder to rebuild that trust than it was to lose it.

The Short Version

Alignment isn’t a thing you set at kickoff and verify at review. Unless you enjoy misery. It’s something you have to keep an eye on while the work is happening, because the work is going to change, and small good changes often accumulate into something no one actually agreed to.

The teams I’ve been on that handled this best weren’t the ones with the tightest status meetings. They were the ones where somebody - usually the producer, sometimes the creative lead, occasionally me on a good day - treated “what has changed about the work” as its own recurring question, separate from progress, and asked it out loud early enough that the answer was still useful.

Status will tell you whether the team is moving, but it won’t tell you where. That second question is one leadership has to keep bringing into the room deliberately, because nobody else is going to add it to the agenda for you.

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

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.

Subscribe now

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.

That, for lack of a better word… sucks. It’s easy to want to just write it off as “it wasn’t ready to show”. Which, I get, but I’ve found a lot of times, that’s not actually the issue. The work, itself, is fine - demonstrable, functioning, at quality, but… despite that, the folks in the room can’t decide to move forward, iterate, or rework. Because a lot of the decision makers, stake holders, or whatever you want to call them… They’re all evaluating through different lenses and agendas.

One person is looking at whether the direction is strong enough. Someone else is looking at whether the work is polished enough to show outside the team. A discipline lead is thinking about feasibility. A stakeholder is reacting to deliverability confidence. Production is trying to understand whether the milestone or deliverable can close.

Same content (or build). Different standards.

The problem, really, is a lack of clarity on what “done” actually means for any given situation. The team thought “done” meant one thing. Leadership thought it meant another.

Or, unfortunately, leadership had not made the meaning of “done” concrete enough for anyone to test. So the team did what good teams do: they filled in the gaps with their own judgment.

Sometimes that works, I’ve seen it happen. But… Most times it turns the review into the first moment where the real definition of done gets negotiated.

And that is a real expensive time to have that conversation.

“Done” is not just a status

In a lot of creative work, we talk about done as if it is a neutral state. The thing is either done or not done.

That works well enough for simple tasks. It does not hold up as cleanly for creative deliverables that exist to support a decision. And, I know for a lot of passionate creative folks, there’s a secondary issue that nothing is ever actually ‘done’. There’s always more that could be polished… But, at the end of the day, we gotta ship. So, aligning on what “shippable” means is pretty critical, and it varies based on a lot of factors.

A concept deck can be done enough to choose a direction, but nowhere near done enough to sell the work to a client. A prototype can be done enough to test a risk, but too rough to build stakeholder confidence. A trailer cut can be done enough to judge structure, but not sound, pacing, audience clarity, or final tone.

None of those are contradictions; they’re just different views. We run into problems when we do not say which view we’re using.

That is why I think “definition of done” is more useful than it sounds. I know the phrase can feel a little process-heavy. It has the vibe of someone trying to solve creative judgment with check boxes on a form, which… no thanks.

A checklist isn’t really useful for this kind of thing anyway - it’s more about leadership alignment and agreement about what the work for any given deliverable needs to accomplish.

Does it allow us to choose a direction? Or is the deliverable in a good enough state for handoff? Will it let production do a deep dive on planning? Can a stakeholder approve the next phase?

You get it. That list could go on forever. Really, behind all of that, is just knowing what done is meant to prove, solve, or answer - and that will help you define what done looks like.

A definition of done should tell the team what decision the work is here to support.

The review is often where an earlier problem becomes visible

Unfortunately, if we don’t do the hard work ot align on all that early, it tends to explode in reviews. Which, makes sense, we’re seeing actually delivered work, usually in some context of the larger project, and it’s where earlier ambiguity finally becomes visible.

The team did their best, often thinking and believing they were delivering what was asked. But, ultimately, the ask was unclear. They didn’t, really, know what they were aiming for. Or they knew, but only in broad language. “Make it polished.” “Get it ready.” “Show the direction.” “Prove the experience.”

What’s frustrating is that those phrases feel clear in the moment because everyone can nod along to them. Everyone knows what they mean, but through their own personal lens. So “make it polished” to a designer is very different than an artist.

It’s one of the reasons this is so important - and so challenging. People leave the same conversation with different assignments in their heads.

Making things worse - if the team is experienced, they may not even notice the gap right away. They will make smart assumptions on past patterns. They’ll try to protect the work from risks they know leadership usually cares about.

That can look like ownership (and to a degree it is), but when too much of the standard lives in assumption, ownership turns into guessing. Which is an express ticket to frustration all around.

Where I learned to distrust the word “ready”

I learned a lot of this in game development, especially around milestone builds and demos.

A team might say, “We need a vertical slice.” For people outside games, a vertical slice is usually a small, polished piece of the larger experience. Ideally, it shows what the finished thing could feel like. Sort of a combination demo and proof-of-concept.

It can also be a vector for misdirection and misunderstanding, because a vertical slice does several different jobs.

It needs to prove that the core player experience works. It needs to show the visual target. It might need to convince an executive group or publishing partner that the project deserves more investment. It might need to expose whether the team can actually build the thing at scale.

Sure, when viewed as a “vertical slice”, all those are close enough to sound like one goal in a meeting. They are different enough to create very different work.

So if the agreement is only “we need a vertical slice,” the team may still be missing the agreement that matters - on a lot of facets.

What really needs to be clarified is: What things does this slice need to prove?

That question travels well outside games. An agency concept presentation, an internal brand direction, a product prototype, an animation test, a campaign treatment, a rough cut… the artifact name changes, but the leadership problem is familiar.

The team is not just making a thing, they’re making something that has to support or enable a decision and, ideally, show some demonstrable progress.

If leadership does not define that decision or what progress looks and feels like, the team will still build toward what they think is being asked. It just may not be the same thing everyone else had in mind.

“Done enough” is often the more honest standard

The word “done” can also create trouble because it sounds final.

Creative work rarely moves that cleanly. A deliverable can be complete for one purpose and unfinished for another. That does not make the work sloppy. It means the team is moving through decisions in sequence. Also, as I touched on above, creative folks are passionate, driven, and want their work as perfect as it can be.

So - I find “done enough to decide” more useful.

Examples: A concept pass is done enough when leadership can choose what to develop next. A risk prototype is done enough when it has exposed the risk honestly. A stakeholder review is done enough when the right people can make the next commitment with eyes open.

That phrasing protects the team from two bad options.

One option is pretending the work is final when everyone knows it is not. The other is keeping everything open because some part of the work could still be improved.

Creative teams can lose a lot of time in that second state. There is always another improvement available, another concern worth considering, and always a smart person with a valid concern.

At some point, the leadership question becomes: does this concern affect the decision this work is here to support?

If yes, deal with it.

If no, capture it somewhere and keep moving. And, yes, the capture part is important, and in my experience, gets overlooked. Often getting buried in meeting notes that no one ever looks at again. So, make sure there’s a clear process for capturing these things. This is critical because good feedback often arrives at inconvenient times, a valid concern can still be out of scope for the current pass (I see this one a lot), and a good idea can still be too late for the decision in front of the team.

That is one of the less glamorous parts of creative leadership: protecting the work from useful input that belongs somewhere else.

The part leaders avoid

The hardest part of defining done is usually not writing the definition. It’s actually, for really realz, committing to it.

A clear definition of done forces leadership to say what matters now, what does not matter yet, and what tradeoffs the team is allowed to make. That can feel uncomfortable because it reduces optionality. Once the standard is visible, leadership can be wrong.

Keeping things vague feels safer. Particularly when you’re in more of a concepting, prototyping, or exploratory phase where the whole point is to learn what the work wants to become.

But even exploration needs a boundary.

“Explore until it feels right” is usually too vague to guide a team for long. A more useful version might be: “Get two or three directions with clear tradeoffs, and we can decide which risk we want to carry forward.”

Still flexible. Much clearer. Granted, you may realize those two or three directions are terrible and you need to revisit, but that’s then a strategic decision, not something that magically happens.

At any rate, the point is not to eliminate creative discovery, but to stop making the team absorb ambiguity that leadership could have (and, honestly, should have) clarified.

I know from experience. I’ve made that mistake. I have walked out of meetings thinking I had given clear direction or goals, then realized later that I had mostly given clear intent. Intent helps. It is not always enough.

The team also needs to know what the next decision is, and what kind of evidence will help make it.

A practical way to start

I would not introduce this as a big new process. If you do that, you’ll hate it, the team will hate it, your stakeholders will probably hate it, and it will fall apart.

Instead, start with one recurring pain point. Look for a review that keeps going off the rails, or deliverables where the team keeps doing strong work and still ends up back in the same conversations, iterating endlessly, or reopening previous decisions without solid reasoning.

Then, before the next pass starts, get the right leads aligned on one question:

What decision does this work need to make possible or answers does it need to provide? You’ll probably need to stay there longer than feels necessary (or comfortable at first).

That question usually reveals where the gaps and misalignment are hiding. Someone will think the work is meant to secure approval, but then someone else will think it is meant to compare options. Then, you’ll find someone who thinks it’s meant to pressure-test feasibility.

This is all good. Resolving that disagreement is much cheaper before the team starts building.

Then, once the decision is clear, the definition of done can be plain language.

For example:

“This pass is done when we can choose one direction to develop, understand the main production risks, and agree on what we are deliberately not solving yet.”

I would probably say it less stiffly in an actual meeting. But that is the basic shape.

It gives the team a target. It gives reviewers a standard, and it gives leadership a way to say, “That is a fair concern, but it is not what this pass is here to answer.”

That sentence, used well, can save a lot of churn.

Of course, used badly, it can become a shield against feedback. So it requires judgment. If someone raises a concern that changes the decision, you should probably stop and deal with it. If someone raises a concern that belongs to a later decision, you should probably protect the current one.

There is no formula that handles that for you, which is why it’s often hard work.

When the target moves

And here’s the messy reality. Sometimes the definition of done changes.

The first pass can reveal something you did not understand. Sometimes a stakeholder reacts differently than expected. I’ve also seen a technical constraint suddenly go from hypothetical to real, or a whole new constraint is discovered. The work, itself, makes it clear that the original bar was wrong.

That is normal. The mistake, though, is pretending the target did not move.

In my experience, teams can handle change better than we sometimes assume. What wears people down is silent change and assumptions. Leadership sees the work, updates the standard internally, and gives feedback from that new standard as if it had been obvious all along.

That can kill the psychological safety of your team.

If the definition changes, own it. Name it. Tell the team what changed, why it changed, and what no longer applies. Be direct about the tradeoff. You do not need a grand ceremony for this. You just need to make the new agreement visible.

That kind of reset is much healthier than letting everyone continue under yesterday’s assumption while leadership grades against today’s concern.

What this gives the team

A useful definition of done does not make creative work less subjective; instead, it gives the subjectivity a job.

The team still needs taste, judgment, instinct, craft, technical creativity, and debate. All of that stays. What changes is that the debate has a clearer relationship to the decision in front of the team.

Are we debating this because it affects the next decision…

… Or are we debating it because it is visible, interesting, or someone has a strong opinion?

It’s an important distinction. A lot of creative churn comes from treating every visible issue as a current issue. Good teams can survive that for a while, but it burns energy. It makes reviews feel heavier than they need to be. It teaches people to either defend everything or wait for leadership to reveal the standard after the fact.

None of that is great.

When “done” is defined well enough, the team gets a better target and leadership carries more of the decision. That feels like the healthier split.

The work will still be messy, and there will still be judgment calls. People will still disagree. Some reviews will still be uncomfortable.

But at least the team is not spending its best thinking trying to reverse-engineer what “ready” was supposed to mean.

Shawn Ketcherside has spent 25+ years in game production and creative leadership, and is now building tools for leaders of creative teams. You can find him on LinkedIn.

This frustration runs in both directions. The team feels it — they’re pulled away from making the work to talk about the work in rooms that don’t seem to move anything forward. As leaders, we feel it too. We sit through the same meetings, have a vague sense of drift and misalignment, and end the week wondering where the time went. Both sides leave bad meetings feeling the same way: that hour should have been spent somewhere else.

The frustration is universal across creative production. Sure, the specific meeting names change between games, agencies, animation, in-house creative, and software product teams... But the experience doesn’t. The bad meeting is the same bad meeting everywhere.

The dominant response I see is some flavor of: Let’s just cut meetings; have fewer meetings; make them shorter; default to async; audit your calendar and delete anything that doesn’t earn its place. This advice is everywhere, it sounds reasonable, and it doesn’t solve much of anything.

Meetings Aren't The Problem

Creative teams need meetings because cross-discipline creative work requires the kind of in-the-moment, shared-context thinking that async communication can’t deliver. The designer, the producer, the engineer, and the director need to be in the same room sometimes. The account lead, the creative director, and the strategist need to be in the same room sometimes. There’s no Notion doc that replaces five people figuring something out together while looking at the same screen.

The cut-meetings answer treats meetings as overhead. But meetings can (and should be) a working tool — production and communication infrastructure that lets cross-discipline teams move together. Removing the tool doesn’t fix the underlying problem. It just relocates the problem into slower, more diffuse forms like longer Slack threads where context evaporates or wandering email threads that end up generating more questions and confusion than they solve.

So the real question isn’t “how do we have fewer meetings,” but “why do so many of the meetings feel pointless?”

The Missing Decision

The answer is upstream of the meeting itself.

Bad meetings are usually bad because no one decided what the meeting was actually about. The calendar invite says “Design Review” or “Sync” or “Weekly Check-in” — labels that describe a category, not a purpose or outcome. Everyone walks in with a slightly different idea of what’s about to happen. The person running the meeting often hasn’t made the call either (I can say I, myself, have made this mistake… a lot), so the meeting drifts toward whatever the loudest voice or most senior person in the room wants it to be.

This is the missing decision. What is this specific meeting’s purpose, and how am I going to run it to get that outcome?

The decision is small. It’s often a five-minute thought before the meeting starts, sometimes less. It’s invisible to everyone else in the room… I mean, yes, you could put it in the agenda that no one reads… But this decision is the difference between a meeting that moves the work forward and a meeting that takes an hour from twelve people and produces nothing the team can use.

As you can imagine, many folks skip this decision because they don’t realize it’s a decision. They inherited a calendar full of recurring meetings, they accepted them, and they show up to them. The meeting happens, the meeting ends, the meeting was bad, and no one’s sure why.

It was bad because the meeting didn’t have a purpose. Or it had one, but no one in the room knew what it was. Unfortunately, same outcome.

The Move

The move is to decide what job the meeting is for before it starts, and make that explicit at the top of the room.

That’s really it.

It sounds trivial, and it isn’t. The reason is that most creative meetings could be doing any of several different jobs, and those jobs require very different behaviors from everyone in the room (and often different people in the room entirely). When the purpose isn’t clear, every person in the room makes their own assumption about what the meeting is for and behaves accordingly. The meeting ends with each person feeling differently about what just happened.

Name the job and the meeting becomes runnable. Skip it and you’re hoping.

This pattern shows up in every kind of meeting a creative team has — alignment meetings, decision meetings, status meetings, kickoffs, retrospectives, stakeholder reviews. But the place it shows up worst, and the place the cost is highest, is in feedback meetings. So that’s where I want to spend the rest of this piece.

The Feedback Case

Feedback meetings — design reviews, creative crits, work-in-progress check-ins, demo days, whatever the org calls them — are the meetings where the missing decision hurts most. The team has spent days or weeks producing work. They bring it to the room expecting something specific to happen, but they don’t know what. The leaders in the room arrive with their own assumptions, also unstated (and at worst, outdated). Everyone speaks past each other for an hour. The team leaves uncertain what was agreed, what they should change, or what they should keep.

This is so common that creative leaders have stopped noticing it. They think it’s just how feedback meetings go.

It isn’t, at least it shouldn’t be. A feedback meeting could be doing one of four jobs. They look similar from the outside. They require very different behaviors from the leader, the team, and the work itself.

The gate. The meeting exists to decide whether the work moves forward as-is, moves forward with changes, or goes back. The leader’s job is to make a call. The team brings the work, presents it clearly, and answers questions. Running a gate without making the call defeats the meeting.

The critique. The meeting exists to surface specific issues with the work that the team should address. The leader is there to give detailed, specific feedback on craft — not directional notes, not “I’m not sure about this part,” but the actual notes the team can act on. The team listens, takes notes, asks clarifying questions, and resists the urge to defend. A critique that produces vague feedback isn’t a critique; it’s a meeting that wasted everyone’s time.

The exploration. The meeting exists to think together about a creative problem that the work has surfaced. Here we, as leaders, are collaborators, not deciders, and the team should bring half-formed ideas without being afraid of them. Exploration meetings die the moment a leader starts making calls — and worse, they teach the team not to bring half-formed and exploratory thinking next time… Which, in any creative field, is… “The bad”.

The alignment check. The meeting exists to make sure everyone in the room agrees on what the work is trying to do before evaluating whether it’s doing it. The leader listens for divergence and surfaces it. The team articulates the brief as they each understand it. The point is shared intent, not feedback on execution. The moment an alignment check slides into critiquing craft, it’s stopped doing its job.

These are four different purposes. The leader’s posture in each is different. The team’s posture in each is different. The success criteria are different. And each of them is a legitimate, useful meeting on its own terms.

The failure isn’t running any of these. The failure is running a meeting that’s trying to be all four at once, with no one in the room knowing which is which.

What the Move Looks Like in Practice

The leadership move in a feedback meeting is small and concrete.

Before the meeting, decide which of the four jobs this meeting is doing. Not “design review” — that’s a label. “We need to align on whether the feedback we got reflects problems worth acting on before we talk about fixes” — that’s a job with a clear outcome.

At the top of the meeting, say it out loud. “This is an alignment check. We’re going to talk about which of these observations we actually believe and whether they’re problems worth solving. We’re not going to talk about how to solve them today — that’s a different conversation, with a different group of people in the room.” Say it before anyone has a chance to start solving… Though I recommend saying it in a less robotic and terrible way than I spelled out here.

When someone in the room tries to shift the meeting into a different mode — and someone will — name it and decide whether to follow the shift or hold the line. “That’s a real question, but it’s a how question, and we agreed we were doing the if question today. Let’s note it and come back to it in the right meeting.” Most of the time, you hold the line. Occasionally, you decide the shift is the right call, and you make that explicit too: “Actually, this might mean we need a different meeting than the one I called. Let’s stop here and reset.” I’ve seen this happen too, usually when you have a planned job or outcome for the meeting, but it’s the wrong one.

This is unglamorous work. It’s not strategic vision. It’s not motivating the team. It’s the small, repeated discipline of knowing what the meeting is for and refusing to let the meeting pretend to be something else.

What Changes

The feedback case is one application of a larger pattern. Since every meeting a creative team has could be doing several different jobs, the work is to decide which job, before the meeting starts, and make the call explicit. This holds for alignment meetings, decision meetings, status meetings, kickoffs, retrospectives, stakeholder reviews. Each one of these can do real work or pretend to. The difference is whether someone decided what the meeting was for.

You don’t need to do a major overhaul of your calendar to start. You need to start asking one question before every meeting you care about: what’s the job of this meeting, and how am I going to run it to do that job? Answer it before the meeting starts. State the answer at the top of the room. Hold the room to it. This will help you not just “reduce meetings”, but make sure that the meetings you have are, you know, useful.

When leaders do this consistently, two things change. Individual meetings get noticeably better — the team leaves knowing what happened and what’s next. And the team learns to expect that clarity, which means they start asking for it when it’s missing. The whole meeting culture shifts toward purpose. Thankfully, a shift not due to any new policy (which I know from experience won’t actually help), but because people started doing the work upstream of the meeting itself.

Meetings aren’t the problem. Meetings without a purpose are. Defining that purpose and the outcome is the work.

Shawn Ketcherside has spent 25+ years in game production and creative leadership, and is now building tools for leaders of creative teams. You can find him on LinkedIn.