Tell me about a time you convinced a business stakeholder to fund technical work they did not want.
answer
- name the debt in one sentence
- cost it in their currency
- tie it to a decision they own
- propose a size, not a blank cheque
- report back what it bought
basics
~10 sTests whether you can translate engineering risk into business currency. Answer with one piece of technical work, its cost stated in something the stakeholder already tracks, a sized ask, and what the investment returned.
how to answer
6 beats- the symptom the business already feltStart where the stakeholder lives, not where the code lives — the late report, the recurring incident, the slow release. Keep this short; it exists so the rest of the answer lands as a fix to a known pain rather than an engineering preference.
- what was actually wrong underneathOne or two sentences of technical diagnosis, pitched so a non-engineer could repeat it. Resist the urge to prove depth here; the interviewer is watching your translation, and excessive detail is itself the failure mode being probed.
- the number I put in front of themGive the cost in the stakeholder's own currency and say how you gathered it — counted over a quarter, timed, pulled from ticket history. This is the load-bearing beat of the whole answer, so make the measurement method explicit.
- the size of the ask and what it displacedState people, weeks, and the one thing it was meant to move, then name what slipped to pay for it and who agreed. An unbounded ask and an uncosted one both read as inexperience.
- what changed after we did itRe-measure the same number and give the after value, plus any second-order effect you did not promise. Result and reflection together are roughly a quarter of your airtime; a story with no after number is an anecdote about a meeting.
- how I keep it from rebuildingClose with the habit or mechanism that followed — sending the measurement each cycle, a budget for this class of work, an intake rule. One sentence is enough, and it is what separates a win from a practice.
your answer
5 story prompts- Pick technical work you argued for and actually got funded, not one you are still waiting on.
- Write the cost in a unit your stakeholder already tracks: money, hours, or missed commitments.
- Name the size of the ask — people and weeks — and what it displaced on the roadmap.
- Have one after number ready, measured once the work had landed.
- Note who you told the result to, and whether they had to ask you for it.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this prompt to test commercial literacy and influence across functions. They want to see whether you can express engineering risk in a unit the business already tracks, scope an ask that is approvable, and own the trade it creates. A strong answer proves you can advocate for durable system health without treating the business as an obstacle.
At a small analytics company our events table had never been partitioned, so every data correction meant a full-table rebuild. Engineering had asked for a partitioning project in three planning cycles and lost every time. I stopped pitching the project and started measuring what it cost the people saying no. Over one quarter I logged every corrective rerun: nineteen of them, each one about twenty-one hours of backfill runtime, and each one pushing the sales dashboards past the eight o'clock hand-off the account team planned their day around. That was the sentence that landed — not that the table was unpartitioned, but that their team had started nineteen mornings that quarter without numbers. Then I made the ask small enough to approve: three engineers, four weeks, one table. And I named what would slip, which was the self-serve export feature. Put side by side, the revenue lead chose the partitioning himself; I did not have to win an argument, I had to make the exchange visible. Afterwards a corrective run finished in two hours fifty. I sent the same log the following quarter — three late mornings instead of nineteen — without being asked. That follow-up mattered more than the original pitch, and it is why the next platform request took one conversation instead of three cycles.
The strength here is switching from advocacy to measurement, and expressing the cost as mornings the stakeholder's own team lost. Naming the displaced feature keeps the trade honest, and the unprompted follow-up log is what buys future credit. It would downlevel if the ask had been an unbounded rewrite or the after number were missing.
I was responsible for the data organisation across three teams when the pattern outgrew any single project. Every team carried a queue of unfundable platform work, and the business won team by team each cycle because each individual ask looked optional on its own. So I changed what we were arguing about. I got the chief executive and the two functional leads to agree on one number they would own jointly with us: the share of mornings the executive reporting set arrived after its committed hour, which was running near one morning in four. Then I proposed a mechanism instead of a project — roughly a sixth of each cycle's capacity spent on whatever moved that number, chosen by the teams, reported publicly whether it improved or not. The trade I made out loud was giving up the right to ask for extra platform time mid-cycle. The product leads cared about that predictability more than they cared about the capacity itself, and offering it is what closed the deal. Two cycles later, late mornings were near one in fourteen, and median backfill runtime across our pipelines had fallen from about nine hours to under three. The part I would repeat anywhere is making a business owner of a reliability number, rather than asking anyone to trust an engineering one.
This reads as principal because the outcome is a standing arrangement across three teams rather than one funded project, and because the concession — surrendering mid-cycle asks — is named aloud as the price of it. Publishing the number even when it worsens is the credibility move. Without the co-owned metric it would collapse to a large senior story.
Nobody expects you to have moved a roadmap. Show that you noticed a recurring cost, wrote down evidence for it — how often it happened, how long it took — and handed that to your lead in a form they could use, rather than only complaining about it in standup.
The realistic scope is one component and one planning conversation, usually inside your own team. Show you sized the work, named what it would displace in the sprint, and framed the payoff in something measurable rather than in code quality adjectives.
You are expected to sell across the table, not within it. The bar is a cost expressed in the business owner's own metric, an ask small enough to approve, an explicit trade you named yourself, and a follow-up that showed the return.
Talk about the mechanism, not the project. The signal is a durable arrangement — a standing capacity allocation, a reliability number a business leader co-owns — that survives you and stops the argument being re-fought team by team every cycle.
saying these in an interview costs you the question
- Describing the work as cleanup or refactoring with no business consequence attached
- Asking for an open-ended rewrite instead of a scoped, sized piece of work
- Quantifying nothing, so the case rests on how bad the code feels
- Blaming previous engineers or the business for the state of the system
- Never reporting back on what the investment actually returned
- Claiming the win without naming what was deprioritised to pay for it
- How did you decide how much to ask for?Show sizing judgment. Explain how you picked an ask small enough to be approvable but large enough to actually change the number — often the smallest slice that produces a visible result, deliberately chosen over the complete fix. Saying you asked for what the work truly needed and got refused is a weaker answer than saying you sequenced it.
- What did you deprioritise to make room for it?Name something real, and say who agreed to lose it. Engineers who claim the work was absorbed with no cost sound either lucky or vague. The strong version is that you put the displaced item on the table yourself so the stakeholder was trading knowingly rather than discovering the cost later.
- How did you show it paid off?Point to the same measurement, taken again after the work landed, and to the fact that you sent it unprompted. This is where credit compounds: the reason the next request is easier is that you closed the loop on this one. If the number did not move as much as you promised, say so and say what you learned about your own forecasting.
Variants of this prompt include *how do you make the case for paying down technical debt*, *tell me about a time you had to sell an unglamorous project*, *how do you explain a technical risk to a non-technical audience*, and *describe a time engineering priorities conflicted with product priorities*. They all reward the same story, so prepare one and adjust the opening clause. ### The reframe the question is built around The naive version of this answer argues that the technical work is important. The strong version never argues that at all; it shows that the technical problem is already costing the stakeholder something they measure and complain about, and that the engineering work is simply the cheapest way to stop that cost. The difference is not rhetorical polish. It changes who the decision belongs to: in the first version you are asking for a favour, in the second you are presenting a bill the business is already paying. ### Choosing the currency Every organisation has two or three numbers its leadership actually watches. Reporting that lands on time. Support tickets of a certain class. Sales cycle length. Cloud spend as a share of revenue. Time from a customer request to a shipped change. Your job before the conversation is to find which of those your technical problem touches, and then to measure the link rather than assert it. Counting is usually enough — how many corrective reruns last quarter, how many mornings a number arrived late, how many hours of engineering time an entire team spent on a recurring class of interrupt. A count you gathered over a real quarter is more persuasive than a modelled projection, because it is checkable and because it is about the past rather than a forecast. ### Size the ask so a yes is cheap A request for a rewrite invites a no, because the person approving it cannot bound the downside. The reliable shape is: a fixed number of people, a fixed number of weeks, one named component, one number it is supposed to move, and a named thing that will slip to pay for it. That last element matters more than candidates expect. Volunteering the cost yourself signals that you understand you are spending someone else's budget, and it prevents the outcome where the work is approved, the roadmap is not adjusted, and the team quietly pays with overtime. ### Weak versus strong, compressed Weak: *Our pipeline was a mess and I kept pushing for time to fix it until eventually we got a quarter to clean it up.* No cost, no size, no owner, no result — and the passive eventually hides whatever actually caused the decision. Strong: *I logged every corrective rerun for a quarter and what it did to the morning hand-off, then asked for three engineers for four weeks on one table and named the feature that would slip. The revenue lead chose it once he could see both halves.* Same project, but every element a decision-maker needs is present. ### Where levels separate Mid-level candidates win a sprint. Senior candidates win a slice of a roadmap from someone who does not report to them, and prove the return afterwards. Principal candidates stop having the argument: they turn a reliability property into a number a business leader co-owns, attach a standing share of capacity to it, and let teams choose the work. If you are targeting the top of that range, make sure your story includes a trade you gave up in exchange — a mechanism that costs the engineering side nothing is usually one that nobody actually agreed to.