4 exercises — making requests without formal authority, influencing senior peers, rallying cross-functional teams, and raising technical disagreements assertively.
0 / 9 completed
1 / 9
You need a colleague from another team to review your security design before a launch. They are busy. How do you make the request persuasively?
Option C is a persuasive request without authority because it:
1. Opens by naming the ask and acknowledging their time constraint: "I have a favour to ask, and I want to respect your time" — signals you won't waste their time 2. Gives a specific reason why this person: "based on our last conversation about token rotation, you'd spot issues I wouldn't" — flattery grounded in actual expertise, not generic praise 3. Reduces the perceived effort: "45 minutes async, not a call — two-page summary with decisions marked, not the full spec" — eliminates two of the largest effort barriers up front 4. Provides a reciprocal benefit: "named security reviewer in the launch ticket = performance record" — incentive that costs you nothing 5. Closes with a specific ask: "Thursday or Friday?" — easier to say yes to a concrete window than a vague "when you have time"
Why A fails: "When you have time" = never, especially for a busy person with their own deadlines
Why D fails: Framing as a requirement when you have no actual authority creates resentment
2 / 9
Your team wants to change the API versioning strategy, but a senior engineer strongly prefers the current approach. How do you make your case without triggering defensiveness?
Option C makes a case to a senior peer without triggering defensiveness by:
1. Starting by validating the current approach: "has worked well and I understand why it was chosen" — not "the old way was wrong" but "the old way was right, AND here's a new problem" 2. Naming a specific, measurable problem with the current approach: "35% of clients still on deprecated version at 90 days → three blocked internal migrations" — you're not criticising the architecture, you're naming a downstream operational problem 3. Scoping the proposal narrowly: "mobile API surface only — not a wholesale change" — reduces the perceived stakes and makes it easier to agree to explore 4. Explaining the mechanism, not just the claim: "header versioning allows server-side migration without client deploys" — shows you understand the technical argument 5. Explicitly inviting critique: "Do you see constraints I'm underweighting? I may be missing something" — expresses genuine openness, which makes the senior engineer more willing to engage constructively rather than dismiss
Why A fails: "The current approach is wrong" is a direct challenge that causes defensiveness
Why D fails: "Industry standard" is an appeal to authority — for a senior engineer, this often triggers the opposite reaction
3 / 9
You need to influence a cross-functional team to adopt your proposed database schema change, but you have no authority over them. How do you structure the request?
Option C effectively influences without authority by:
1. Opening from their perspective: "this affects all three of your services and I don't want to create unplanned migration work" — the first sentence is about them, not about you 2. Explaining the motivation with specifics: "p99 latency above 800ms on preference-filtered queries" — not "performance is bad" but a measurable, specific symptom 3. De-risking the change for them specifically: "60-day parallel read window, no same-day cutover" — removes the largest objection (forced synchronous migration) before it's raised 4. Doing the work for them: "migration guide with example queries for your three services" — dramatically lowers resistance by removing effort 5. Making a minimal, specific ask: "Does the migration path work for your schedule? Are there edge cases?" — not "agree to this" but "tell me what I'm missing" — positions them as collaborators, not opponents 6. Explicitly deferring the decision: "Not asking for agreement today" — no pressure, lower resistance
4 / 9
You disagree with a technical decision made by a more senior engineer in a code review. How do you raise this diplomatically but assertively?
Option C raises a technical disagreement assertively but constructively:
1. Opens with epistemic humility without abandoning the concern: "I might be missing context, so tell me if I am" — not sycophantic capitulation but genuine openness, while still fully proceeding with the concern 2. Names the exact location of the issue: "lines 34–67" — not vague criticism, but specific enough that the senior engineer can evaluate the claim immediately 3. Uses observed data for the scenario: "p99 latency ~1.8 seconds, 20–30 concurrent requests" — grounded in real system behaviour, not hypothetical 4. Names the failure mode specifically: "thundering herd — sequential execution extending spike from seconds to minutes" — advanced technical framing demonstrates you understand distributed systems 5. Proposes a concrete alternative: "narrow the lock scope to lines 78–84, handle idempotency separately outside the lock" — not just criticism, but an actionable path 6. Closes with a question, not a declaration: "Am I reading the lock scope correctly?" — invites correction or confirmation, either of which advances the conversation
5 / 9
Alex: 'I've just deployed the new feature. It's working perfectly!'
As a senior engineer reviewing this deployment notification in Slack, you want to subtly highlight a potential performance bottleneck without sounding critical. Which of the following responses is most persuasive?
This question focuses on proactive negotiation and risk mitigation. Option 1 suggests a natural follow-up step – monitoring – while directly prompting action to identify potential issues. Options 2, 3, and 4 are too direct or assume a problem without evidence, potentially leading to defensiveness. The key is to introduce a suggestion for further investigation rather than stating a negative assessment.
6 / 9
Sarah (Product Manager) sends this PR description: 'Implemented the user profile update. This is now live.'
You're a developer reviewing this PR and notice a lack of clarity around data validation. Which of the following additions would be *most* persuasive in encouraging Sarah to address this?
This scenario tests persuasive language within a PR description. Option 1 is passive and doesn't address potential issues. Option 2 directly suggests an improvement with clear reasoning (data integrity), framing it as a beneficial addition rather than a criticism. Options 3 and 4 are simply acknowledgements or celebrations, failing to highlight the importance of robust implementation.
7 / 9
David (Lead Developer) is presenting a proposed refactoring of a legacy module to the team during a standup. He states: 'We're going to rewrite this whole thing.'
You want to encourage support for his proposal while acknowledging potential concerns about disruption. What's the most persuasive approach?
This question addresses persuasive language in a standup setting. Option 1 is overly enthusiastic without addressing potential concerns. Option 2 demonstrates active listening and encourages David to provide more details about the benefits and plan (a phased rollout mitigates risk), making it more palatable for the team. Options 3 and 4 are dismissive or encouraging haste, which can be counterproductive.
8 / 9
Emily (DevOps Engineer) responds to a Slack message about the new deployment pipeline with: 'It's just working.'
You notice that the monitoring dashboards show high latency. How do you respond in a way that encourages Emily to investigate, without accusing her of negligence?
This focuses on addressing an issue through persuasive communication. Option 1 ignores the data and defends the current state. Option 2 directly highlights the problem and requests action, providing a clear justification for investigation. Options 3 and 4 are passive and avoid responsibility, failing to address the observed latency.
9 / 9
Ben (Senior Architect) argues against using a new database schema during a design review. He says: 'We've always used this approach, and it works perfectly.'
You believe the new schema offers significant advantages in scalability but need to convince him without challenging his experience directly. Which of the following statements is most persuasive?
This explores persuasion through data-driven arguments. Option 1 concedes the current approach without acknowledging potential improvements. Option 2 presents a concrete benefit – scalability and future growth – focusing on the *outcome* rather than directly challenging Ben's experience or established practice. Options 3 and 4 are overly general or dismissive, failing to provide a compelling reason for change.
This module focuses on Negotiation English — real workplace phrasing you'll use on the job. It contains 9 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 9 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Negotiation English exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around negotiation english — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Negotiation English exercises?
See the Negotiation English hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.