As much as I love the phrase, “No is a complete sentence”. It’s not true. Not for creative ops leaders.
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.
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.