There's a moment in every planning cycle where someone walks in with a request. It's always framed as small. "Can we just add this?" "The board wants to see progress on X." "A customer asked for this — it's a quick win."
It's never a quick win.
But that's not the real problem. The real problem is what happens next. The engineering leader — you, me, whoever's in the seat — does the mental math. Can we absorb this? If the team pushes a bit harder, if we cut a corner here, if we delay that thing nobody's watching... maybe. Probably. We'll figure it out.
So you say yes. Not because you've evaluated the trade-off, but because saying yes is easier than having the conversation. The team absorbs it. They always do. And everything gets delivered a little worse than it should have been.
The sentence
I learned to replace all of that with six words:
"What do I slow down for you?"
That's it. Not "no." Not "we can't." Not a twenty-minute explanation of capacity planning and velocity metrics. Just a question that makes the trade-off visible.
Because here's what the requester usually hasn't done: they haven't looked at what's already in flight. They see their request in isolation. It exists in a vacuum — important, urgent, obvious. Of course we should do it. Why wouldn't we?
The question forces context. It says: the team is already building things. Those things were already prioritised. You're not asking me to add something — you're asking me to replace something. So which thing do you want less?
What happens next
In my experience, one of three things happens.
They back down. Half the time, the requester hears the question and realises they don't want to make that trade. Their "quick win" isn't worth displacing what's already committed. The request quietly disappears. No conflict. No drama. They made the call themselves.
They make the trade. Sometimes it is more important. Fine. Now you both know what's being deprioritised, and — critically — so does the team. The engineer who was working on the displaced feature isn't left wondering why their work got silently shelved. The decision is explicit. Everyone knows what happened and why.
They insist on having both. This is the revealing one. "I don't want to slow anything down, I just want to add this." That sentence is a test. They're telling you they believe in free capacity that doesn't exist, or they're telling you they don't care about the cost as long as they don't have to name it. Either way, you've learned something important about how this organisation makes decisions.
Why "no" doesn't work
I used to try saying no. It doesn't land. "No" makes you the obstacle. It positions engineering as the department that blocks things. The requester walks away thinking the problem is capacity or competence, not priority.
"What do I slow down for you?" does something different. It puts the decision back where it belongs — with the person who wants the change. You're not blocking. You're asking them to lead. Most people, when given that responsibility, make reasonable choices.
The ones who don't are telling you something about the org that's worth knowing.
The discipline it requires
This only works if you actually hold the line. If you ask the question, they name a trade-off, and then you deliver both anyway because the team worked weekends — you've just taught everyone that the question is theatre. The next time you ask it, they'll smile and wait for you to absorb it like you always do.
The sentence is a commitment. Not to them — to your team. It says: I will not sacrifice your evenings to avoid an uncomfortable conversation. I will not let scope creep erode the quality of your work because I didn't want to push back.
Every time you hold, you build a precedent. The organisation learns that engineering capacity is finite, that trade-offs are real, and that asking for more means choosing less. Every time you fold, you teach them that pushing works.
The quiet version of protecting your team
This isn't confrontational. That's what makes it work. You're not raising your voice. You're not escalating. You're asking a question — politely, calmly, every single time. And over a few cycles, the organisation starts to internalise the constraint. People begin arriving with their own trade-offs pre-thought. "I'd like to add X — could we push Y to next cycle?"
That's the end state. Not a team that says no, but an organisation that thinks in trade-offs. And it starts with six words, asked consistently, without flinching.
What do I slow down for you?
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.