Your team accepted five small requests mid-quarter and the main goals are slipping. What process change do you make?

One visible prioritised commitment list; new requests come to the lead or product first and are answered with explicit trade-offs (what gets delayed, or a smaller version), with the priority owner deciding.

How do you say no without damaging the relationship?

Acknowledge why the request matters, explain the trade-off, offer alternatives (a smaller version now, the full version later, a manual workaround), and involve the priority owner in the decision.

When should a team simply say yes to a request?

When it's cheap, high-value and fits within the agreed buffer or threshold — deliberate choices, not a reputation for refusing.

Saying No and Negotiating Scope — The Team Lead Handbook

Scenario

Example team: the checkout team committed to three goals for the quarter. In six weeks, they've also accepted five "small" requests from sales, support and another product team. None of the three goals is on track, and the team works evenings.

What you see on the team

Many small commitments added mid-quarter.
Original goals slipping without anyone deciding to drop them.
The team saying yes to avoid conflict, then working overtime.
Stakeholders surprised when the main goals miss.

The common mistake

Saying yes by default (or no by default) instead of making trade-offs visible and letting the right person decide.

Why it happens

Each request looks small and reasonable on its own, and saying no feels unhelpful. The cumulative cost is invisible until goals slip. Basecamp's Shape Up frames work as an "appetite" — a fixed amount of time — with scope adjusted to fit; any new work has to fit within, or replace, existing commitments.

The playbook

Have one visible list of commitments in priority order (quarter goals plus accepted requests).

Answer requests with a trade-off, not a yes or no:

"Yes, if we drop or delay X — whose call is that?"
"Yes, a smaller version: we can do A now, B next quarter."
"Not this quarter — here's where it sits in the queue and why."

Route the decision to the owner of the priorities (usually product), with the cost made explicit.

Keep a small buffer for genuinely urgent requests (incidents, legal, security) — and protect it.

Say yes generously when it's cheap and high-value — the goal is deliberate choices, not a reputation for refusing.

What to say

To a sales lead with an urgent request:

"I understand why this matters for the deal. We can do it this sprint if we push the saved-cards work by a week — that's product's call, so let's ask Maria together. Alternatively, we could do the export as a manual CSV this week and build it properly next quarter."

To the team:

"From now on, new requests come to me or Maria first — please don't accept them directly, even small ones. I'm not trying to block anyone; I want us to choose deliberately."

Trade-offs

Routing every request through the lead can slow simple things; agree a size threshold below which engineers can just help.
Saying no can damage relationships; offering alternatives and explaining the queue keeps them intact.
Fixed scope with fixed dates rarely works; scope is usually the variable to negotiate.

Signals it's working

The commitment list is visible and current.
Goals are dropped or delayed by explicit decision, not silently.
Stakeholders get alternatives, not just refusals.
Overtime decreases; quarter goals are met more often.

Key points

Keep one visible, prioritised list of commitments.
Answer requests with trade-offs and alternatives, not reflexive yes or no.
Route priority decisions to their owner, with the cost explicit.
Protect a small buffer for genuinely urgent work.