Say no by making the trade-off visible
Respond to extra work with a clear account of capacity, alternatives, and decision ownership instead of a hidden promise to work longer.
When you cannot take on extra work safely, explain which existing commitment would change and ask the responsible person to choose. Offer a realistic alternative where one exists, but do not disguise a capacity limit as a promise to work longer.
'I can investigate this today, but the planned release check would move. Which should take priority?' makes a real choice visible. Saying yes to both does not create the missing time.
An extra request rarely arrives labelled “please displace something else.” It arrives as a small favour, a quick investigation, or a supposedly urgent change. Before agreeing, identify what the request would consume and what would have to move.
Identify what the request competes with
Clarify the desired result, the deadline, and the reason for the deadline. “Could you look at this?” may mean a short opinion, a reproducible investigation, or ownership of a fix. You cannot judge capacity until you know which request you are accepting.
Then inspect your existing commitments. Include review, testing, support, and coordination, not just visible implementation tasks. An apparently empty afternoon may already be the margin needed to finish a release responsibly. The work that is easy to omit from a plan is not necessarily optional.
Managing Up and Getting to Yes offer complementary prompts: communicate expectations deliberately and examine the need behind a request. Careerstone Group’s first-hand account of prepared check-ins provides a practical example of the first. The scripts here are our own application to engineering capacity, not a negotiation guarantee.
Try the decision
A new urgent request arrives while a release fix already has a deadline.
The capacity conflict stays hidden until a commitment slips.
Next step: Surface the competing work before accepting the request.
This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.
Offer options you can actually deliver
In an illustrative example, a developer is completing a scheduled release check when a colleague requests a new export field for a demonstration. The request may be small in code, but it still needs its meaning clarified, a test, review, and coordination with the release.
The developer could say: “I can investigate the field today and give you a proposed approach, or implement it after the current release. Implementing and checking it before the demonstration would move the release work. Which outcome is most important?”
Notice the distinction between investigation and delivery. A limited look is not a commitment to a finished change. State the boundary explicitly and report what you learned when the investigation ends. Otherwise, “I will take a look” can become an accidental promise to own the whole problem.
Offer an alternative only if it is real. “Someone else can do it” is not a plan when you have not checked their capacity. A smaller scope may work, but do not propose an unchecked production change as the faster option. The guide to estimates helps explain why uncertainty and hidden work belong in the discussion.
Put the decision with the right owner
You may not have authority to move another team’s commitment. Explain the conflict to whoever owns the priority decision. Give them the consequences and your recommendation rather than forcing them to reconstruct the plan from several private conversations.
A useful statement contains the requested result, the displaced work, the meaningful risk, and the decision needed. “Both are important” may be true, but it does not resolve the conflict. Ask which result should take precedence or which additional support can actually be provided.
Once the decision is made, update the relevant plan and tell the affected people. Do not leave an old commitment appearing intact after it has been deprioritised. Owning work end to end includes those communication consequences, not only the new task you accepted.
You can still set a boundary where the request exceeds your authority, violates an important constraint, or is not something you can responsibly deliver. Making trade-offs visible is not a requirement to say yes whenever someone accepts the risk on paper.
Handle pressure without inventing capacity
A genuine emergency may justify interrupting planned work. Use the team’s incident or escalation process, clarify who is coordinating, and make the interruption visible. The emergency changes the priority; it does not make the displaced work disappear.
After the urgent work, revisit what moved and what recovery time or support is needed. Do not leave the plan pretending that everyone completed both schedules. That makes the next planning discussion depend on a false account of capacity.
If the response is repeated pressure to do everything anyway, restate the constraint calmly and keep an accurate record through appropriate work channels. A better sentence cannot fix chronic understaffing or abusive behaviour. Seek suitable organisational support rather than treating the situation as a personal failure to communicate.
Address the pattern when it keeps happening
If similar requests repeatedly interrupt the same work, examine the source. Are expectations unclear? Is a recurring support duty missing from planning? Are multiple people independently assigning work? Bring a few concrete examples, not a accusation that everyone is unreasonable.
If the recurring conflict is not mainly about capacity but about who gets to define what is technically simple, read why software work turns into stakeholder arguments. It separates technical expertise, business authority and the hidden work that makes small requests look deceptively cheap.
Use a focused conversation with your manager to agree who can set priorities and how interruptions will be handled. The useful outcome is a clearer operating arrangement, not a more elaborate script for saying no every afternoon.
A responsible no protects the truth of the plan. It states what can happen, what cannot happen at the same time, and who needs to choose. That is more useful than a cheerful yes followed by a silent missed commitment.