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 / 4 completed
1 / 4
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 / 4
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 / 4
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 / 4
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