4 exercises — making the business case for headcount, justifying tool costs with ROI, explaining TCO for infrastructure decisions, and securing budget for new platforms.
0 / 9 completed
1 / 9
You need a dedicated DevOps engineer on your team. You have been sharing one from a pool of 4. How do you make the business case for dedicated headcount?
Option C is a strong internal headcount business case because:
1. It quantifies the current cost of NOT having the resource: "4.2 days average wait, 3 deployment blockers, £90k estimated delayed revenue" — not "it would be nice to have" but "here is the ongoing cost" 2. It names the specific risk: "unqualified infra work creating security review debt" — this is a compliance/risk argument that resonates with leadership 3. It states the hire cost and the ROI together: "£65k cost vs. £90k conservative revenue impact" — makes the decision mathematically straightforward 4. It proposes a next step with the right audience: "30-minute conversation with you and the CFO" — not just asking your manager, but including the budget decision-maker
Why A fails: "We really need" is an expression of preference, not a business case
Why D fails: Social proof ("other teams have it") is weak; it doesn't address whether it's justified for your team
2 / 9
Your team needs a £24k/year test automation platform. Your manager's initial response is: "That's expensive. Can we just keep using our existing manual process?" How do you respond?
Option C handles a budget challenge with a full cost/benefit response:
1. Starts by acknowledging the challenge as "fair": not defensive — it signals you expect to justify it 2. Calculates the current cost of the status quo: "216 tester-hours × £45 = £9,700/year" — the manual process is not free; this is often invisible to managers 3. Models the savings at a conservative rate (80%) rather than the vendor's best-case claim: signals analytical rigour, not vendor-pitch thinking 4. Honestly acknowledges the breakeven is long: "3.1 years on labour alone" — integrity here makes the additional benefits more credible 5. Adds non-labour benefits: rollback reduction, earlier CI catching, freed exploratory capacity 6. Limits risk with a pilot: "2-sprint pilot, 30% of regression suite" — you can prove value before full commitment
Why A fails: "Costing us more" without the numbers
Why D fails: Relative cost comparison ("not that much for a team our size") doesn't answer whether the ROI is there
3 / 9
You want to migrate from on-premise infrastructure to a managed cloud service. Your CTO says: "We already own the servers. Why would we pay for cloud?" How do you explain the total cost of ownership difference?
Option C answers the TCO question with intellectual honesty and structure:
1. Validates the CTO's premise: "owned-servers argument is often correct" — not dismissive 2. Frames the real question: "acquisition cost vs. TCO over 3–5 years" — resets the comparison 3. Lists ALL on-prem costs, not just the obvious ones: hardware refresh, data centre rent, ops maintenance time — many people forget the time cost 4. Compares cloud cost over the same period (not monthly): "£43,200 over 2 years" vs. "£64k on-prem" — same timeframe makes the comparison honest 5. Adds the risk event cost: "emergency hardware failure = £12–15k + 5 days downtime" — hidden risk is often the deciding factor 6. Acknowledges when on-prem wins: "flat compute needs for 5+ years" — credibility through intellectual honesty 7. Asks for a modeling session, not a decision: "45 minutes to model growth scenarios" — low-stakes next step
4 / 9
You want your team to adopt a new observability platform. Your manager says: "We already have logging. Why do we need this?" How do you make the case?
Option B makes a tool adoption case effectively by:
1. Starting by validating what they have: "logging is often sufficient for simple systems, and our logging setup is good" — this is credible; you're not dismissing what exists 2. Naming the specific unsolved problem with evidence: "the March 15th incident took 3.5 hours to debug due to undocumented microservice dependency" — real event, real time cost 3. Explaining the mechanism: "distributed tracing shows the causal chain as a waterfall view" — not just "it's better" but how and why 4. Using an industry benchmark appropriately: "70–80% MTTR reduction for distributed latency issues" — qualified to the specific class of problem, not a general claim 5. Running the ROI calculation bottom-up: "2 similar events per quarter × 4 engineer-hours × £55 = £880 saved; breakeven at 2.7 events/year vs. our current frequency" — the manager can verify this easily 6. Already having a trial environment: "could you spare 20 minutes" — lowest possible ask, proves you've done the legwork
5 / 9
Sarah (Senior Backend Engineer) posts a comment on the PR describing a potential performance bottleneck caused by inefficient database queries. The original author, Mark, responds: 'Just optimize it later.' How should you respond to Mark to encourage further discussion and action?
The key here is proactive engagement and focusing on solutions. Simply stating the problem isn't enough; you need to invite Mark into a collaborative discussion about *how* to address it. Option 1 avoids responsibility, option 3 dismisses the concern, and option 4 pushes forward without addressing the identified issue. Option 2 demonstrates ownership of the technical challenge and encourages further investigation.
6 / 9
David (Product Manager) asks your team to prioritize a new feature—a real-time analytics dashboard—for the next sprint. The lead developer, Emily, replies: 'That sounds like a huge amount of work. We're already committed to finishing the user authentication module.' How do you politely push back on Emily's assessment while acknowledging her concerns?
This scenario requires balancing prioritization with understanding technical constraints. Option 1 is dismissive and doesn't address the value of the new feature. Option 3 avoids a discussion entirely, while option 2 frames the analytics dashboard as strategically important and opens the door to collaborative planning – demonstrating an understanding of both Emily's workload and the broader business objectives.
7 / 9
You're presenting a proposal for upgrading your team's CI/CD pipeline to include automated security scanning. The Head of DevOps, Ben, responds: 'We already have a manual vulnerability scan running as part of the release process.' How do you best explain the benefits of adding automated scanning?
The core argument here is about *continuous* integration and security. Manual scans are reactive; automated scanning provides proactive detection and reduces the risk of vulnerabilities slipping into production. Option 1 ignores the benefits of automation, option 3 simply accepts the status quo, and option 4 doesn't address the key difference in approach.
8 / 9
Liam (Team Lead) asks you to justify the cost of implementing a new monitoring tool that provides granular insights into application performance. Your manager replies: 'I don't see any problems with our current logging system. Let's not spend money on something we don't need.' How do you respond?
This question tests your ability to articulate the limitations of existing tools and highlight the value proposition of a new solution. Simply stating that logging is sufficient doesn't address the underlying problem – the lack of proactive performance monitoring. Option 3 just accepts the manager's stance and option 4 is too vague. Option 1 clearly explains *why* the new tool is needed, focusing on tangible benefits like reduced downtime.
9 / 9
You're discussing a potential redesign of your team's internal API with Chloe (Senior Software Engineer). She pushes back, stating: 'This new version will break all our existing integrations.' How do you respond to Chloe's concern?
Backward compatibility is a crucial consideration when redesigning APIs. Acknowledging the potential impact and proposing solutions like API versioning demonstrates proactive thinking and mitigates risk. Options 2 offers a constructive approach to addressing the challenge, while options 3 and 4 are dismissive and ignore best practices.
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.