Saying No Professionally — Vocabulary and Language
Learn vocabulary for declining requests professionally: pushback language, alternative proposals, and diplomatic boundary-setting.
0 / 12 completed
1 / 12
What is the 'acknowledge, decline, offer alternative' structure for saying no?
Structure: 'I understand why this is important for your Q3 deadline (acknowledge). Unfortunately our team is fully committed to the platform migration through Q3 and cannot take on additional work (decline). That said, we could scope a lighter version that addresses your core need — would [alternative] work? (offer alternative).' Preserves the relationship, stays honest about capacity.
2 / 12
What is 'prioritization language' when declining a request?
Prioritization framing: 'Given our current commitments to [Project A] and [Project B], we're not able to take on [Request C] this quarter without deprioritizing something else. If you can help align with [Manager] on what should be deprioritized, we'd be happy to take this on.' This makes the refusal a resourcing conversation, not a personal one.
3 / 12
What is 'borrowing from the future' in commitment language?
Borrowing from the future: 'We cannot do this in Q2, but I have put it in our Q3 backlog at high priority.' This is more satisfying than a flat no — the requester has a timeline and knows it will be addressed. The risk: you must actually follow through. Only use this when you genuinely intend to deliver in the stated future period.
4 / 12
What is 'explaining trade-offs' when declining additional work?
Trade-off language: 'We can add that feature, but it would push back the API redesign by 4 weeks. The API redesign is blocking three other teams. Would you like me to discuss this trade-off with [stakeholder] so we can make an informed decision?' This avoids unilateral refusal — you present the real choice and involve the right decision-makers.
5 / 12
What is 'protected time' or 'focus time' language in professional boundaries?
Protected time communication: 'Our team has committed delivery work from 9-12 daily where we avoid interruptions. I will respond to this request at 2pm. For urgent issues affecting production, use the #incident-response channel.' This sets expectations professionally — declining to be constantly interruptible without refusing to help.
6 / 12
Sarah (Senior Developer) sends you this Slack message: 'Hey, can you take a look at the new user authentication flow? It's kinda broken.' What's the most professional response, acknowledging her request while setting a boundary?
This question tests acknowledging a request without immediately committing. Option 1 politely acknowledges Sarah's message and offers a brief timeframe, demonstrating respect while managing your workload. Options A & C are dismissive; option D lacks any consideration for Sarah's time or the complexity of her request – it's crucial to balance empathy with realistic boundaries.
7 / 12
You're reviewing a PR submitted by Mark. He's added a complex new algorithm for data compression but hasn't included any tests. Your comment should be: 'The algorithm looks interesting, but I need to see some unit tests before merging.' What phrasing best communicates this concern?
Option 1 directly and clearly states your need for testing. It avoids overly positive or negative language and focuses on the crucial aspect of ensuring code quality. Options A & C are too permissive; option B is polite but doesn't explicitly highlight the critical missing element (tests). This demonstrates effective communication regarding technical requirements.
8 / 12
Alex (Lead Engineer) asks you via Slack: 'Could you quickly help me debug this intermittent issue with the API gateway? It's impacting performance.' You need to politely decline. Which response best demonstrates professional boundaries while acknowledging his concern?
Option 1 correctly uses prioritization language by explaining your current commitment and offering a helpful resource (documentation). Options 2 and 3 are overly agreeable and don't establish boundaries. Option 4 deflects responsibility without providing any support.
9 / 12
You're writing the description for a Pull Request you've submitted to David (Senior Developer) that implements a new feature. He asks if you can add more details about the technical rationale behind your design choices. What's the most appropriate phrasing?
Option 1 is terse and unhelpful. Option 2 provides valuable context by explaining *why* you made the design choices – this demonstrates professionalism and helps David understand your work. Options 3 and 4 are dismissive and fail to contribute to a constructive code review.
10 / 12
Ben (Junior Developer) asks you if you can help him refactor a large section of legacy code. You're already under significant pressure to meet a deadline. Which response is most professional and sets appropriate expectations?
Option 1 clearly indicates your priority. Option 2 politely declines while suggesting an alternative discussion point – this is crucial for managing expectations and preventing overcommitment. Options 3 and 4 are overly enthusiastic or simply avoid the issue.
11 / 12
During a standup meeting, Chloe (Product Manager) asks you to investigate a potential performance bottleneck in a key feature. You realize this will require significant time and resources. What's the best way to respond?
Option 1 is a commitment that you might not be able to deliver on. Option 2 requests clarification – essential for understanding the request's scope and potential impact. Options 3 and 4 are dismissive and fail to acknowledge the request.
12 / 12
You've been asked by Frank (Stakeholder) to add a new feature to an existing project. You explain that this will require significant rework and could delay the release date. He responds with: 'Just do it! It's important for the user experience.' What is the most professional way to respond, while still advocating for responsible development?
Option 1 acknowledges his request but clearly sets a boundary by proposing a timeline and outlining the impact of adding the feature. It demonstrates professionalism and manages expectations. Options 2 is overly assertive, while option 3 and 4 are passive and avoid addressing the core issue.
What will I learn from the "Saying No Professionally — Vocabulary and Language" exercise?
Learn vocabulary for declining requests professionally: pushback language, alternative proposals, and diplomatic boundary-setting.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall required.
How many questions are in this exercise?
This set contains 12 multiple-choice questions, each with a detailed explanation shown after you answer.
Do I need to create an account to track my progress?
No account is required. Your progress bar and score reset each time you reload the page, but you can retry the exercise as many times as you like.
Who is this Stakeholder Management exercise for?
This exercise is built for IT professionals and non-native English speakers who need to read, write, and discuss stakeholder management topics confidently at work.
What happens if I answer a question incorrectly?
You will see the correct answer highlighted along with a detailed explanation of why it is correct -- so every wrong answer becomes a learning moment, not just a lost point.
Can I retry this exercise?
Yes -- click "Try again" on the results screen at any time to reset your score and go through all the questions again.
How long does this exercise take to complete?
Most learners finish all 12 questions in under 10 minutes, since each question is answered by clicking a single option.
Where can I find more Stakeholder Management exercises?
See the full Stakeholder Management exercises hub for more vocabulary drills on this topic.
Is this exercise mobile-friendly?
Yes -- the exercise works on any device with a modern browser, including phones and tablets, with no app download required.