Advocating for Tech Debt / Engineering Investment

Every senior engineer has been asked “why are we slowing down for tech debt when we could be shipping features?” The strong answer turns this into a conversation about cost, risk, and trade-offs rather than a fight.

What they’re really asking

Can you make a business case for engineering investment, not just an emotional one?
Do you know when tech debt is worth paying down and when it’s not?
Will you push back when leadership wants only features, or just comply?
Can you negotiate with non-technical stakeholders?
Do you have judgment about which debt matters?

What this question is NOT

“Tell me about a time you fought management and won.”

Don’t make this adversarial. The strongest answers show you and product / leadership reached agreement on something neither would have gotten on their own.

The STAR structure

Situation: specific tech debt or engineering investment that you advocated for. Concrete: “our flaky CI was costing the team ~8 hours/week in retried builds.”

Task: what you wanted to do, what you needed from leadership.

Action: how you made the case — the conversations, the data, the proposal.

Result: what was agreed, what was shipped, what changed measurably.

Example template

Situation: Mid-2023, our test suite was flaky. We had ~15% of CI builds fail and need retry on green code. Most engineers had developed habits like “always run twice” or “if it failed, click rerun.” Time cost: I estimated 6-8 hours/engineer/week across a team of 12 = 72-96 engineer-hours/week of friction.

Task: I wanted to spend a sprint (2 weeks) on a flake-reduction project. Product had a backlog of features they wanted that quarter; this would push them out by 2 weeks.

What I did:

Quantified the cost. Pulled CI metrics from Buildkite — calculated avg builds per PR, retry rate, time wasted. Turned 8 hours/week into “$8k/week in engineering time” at typical loaded rate.

Identified the top causes. Spent 4 hours analyzing failed builds. 80% of flakes came from 5 specific tests (timing-sensitive integration tests).

Proposed a scoped fix. Not “rewrite the test suite” — “fix these 5 specific tests + add a pytest-rerunfailures policy that flags vs silently retries.” Estimated 2 weeks, 1 engineer.

Made the trade-off explicit. “If we don’t do this, every feature ships ~10% slower for the next year. If we do this, the next feature ships 2 weeks later but everything after is faster.” Sent it as a 1-page doc to my manager + the PM.

Asked for the meeting, but came with a recommendation. “Here’s what I’d do. What I need: 2-week green light. Open to: scope cuts if you see a smaller version.”

Result: Got the green light. Spent 2 weeks. Flake rate dropped from 15% to 2%. The PM tracked the team’s velocity for the following quarter and confirmed it was visibly faster afterward. The “make the cost explicit” approach became something other engineers on the team started using for their own tech-debt proposals.

Lesson: Leadership rarely says “no” to tech debt as a category. They say no to “we should fix tech debt” because that’s a feature-shaped ask without a feature-shaped trade-off. Once you frame it as “spend $X now to save $Y over Z months,” the conversation changes.

What this answer signals

Quantification. Not “the team feels frustrated.” Real numbers — 15%, $8k/week, 80%.
Scoping. Not “rewrite everything.” A specific, achievable 2-week project with clear deliverables.
Empathy for the other side. You understand why they’d hesitate; you frame the cost in their terms.
Pre-committed recommendation. You don’t ask “what should we do?” You say “here’s what I’d do; tell me what concerns you have.”
Followup data. PM confirmed the speedup. Closes the loop.
Transferable pattern. Other engineers adopted the approach. Multiplier effect.

The trap to avoid

The purist fight

“Our codebase is full of debt. We need to spend a quarter cleaning it up.” Predictably gets a “no.”

Why: too vague, too expensive, too risky. Leadership has no way to evaluate the ask.

The whining frame

“We can’t ship faster because of all this debt.” Doesn’t propose a path forward; just complains.

Better: “Here’s the specific debt that’s costing us most; here’s the scoped fix; here’s what it’d save.”

The “we’ll do it on the side” trap

“We’ll just sneak refactoring into feature work.” Sometimes works; often results in features taking longer than expected and unhappy PMs.

Better: explicit allocation. “Sprint X is for feature; sprint Y has 30% capacity for refactor.”

The 0-or-100 trade-off

“Either we do this tech debt project or we ship the feature, not both.” Forces a no-win choice.

Better: “Here’s a 2-week version that gets us 80%. We can defer the remaining 20% to next quarter.”

Patterns for the conversation

1. Translate to business cost

Time wasted → engineer-hours → dollar cost.
Outages / bugs → user impact → revenue / NPS / on-call burden.
Slow builds / deploys → feature lead time → competitive disadvantage.

2. Scope to the minimum viable fix

Don’t propose “fix all flaky tests.” Propose “fix the top 5 most-flaking tests.”
Don’t propose “rewrite the legacy module.” Propose “extract the 2 most-painful interfaces.”

3. Pre-write the proposal

A one-page doc:

The problem (with data).
The proposed scope (with timeline).
The trade-off (what features are delayed).
The expected return (with how you’ll measure).

Make it easy to say yes.

4. Find the natural moment

After an incident is the best time to propose related debt fixes. After a successful launch with capacity to spare is the second best. Mid-crunch is the worst.

5. Track the outcome

If you got the green light, prove it was worth it. “Last quarter we spent 2 weeks on X; here’s the measured impact.” Builds credibility for the next ask.

When NOT to fight for tech debt

The codebase is being deprecated soon.
The thing isn’t actually costing anyone time.
You’re proposing to fix it because you don’t like it aesthetically.
The fix is bigger than the pain.
You can’t quantify the cost.
You don’t have a scoped version of the fix.

Senior engineers know which debt to leave alone. “We could refactor X” doesn’t mean “we should.” Capacity to recognize that is part of the signal.

Anti-pattern in the answer

“We had a lot of legacy code that was painful. I kept pushing management to let us refactor it but they wouldn’t listen.”

Why it fails: no specifics, no proposal, no quantification, no plan. Sounds like complaining.

A great answer is collaborative

Frame the result as “we agreed on” rather than “I convinced them.” The product/engineering trade-off is real; nobody’s wrong. The skill is in navigating it.

Variations

“Tell me about a time you advocated for a non-feature engineering investment.” Same shape — could be tooling, observability, testing infra, security.

“How do you balance shipping features and paying down debt?” Talk about explicit allocation: 80/20, fixed sprint cadence, or “every Nth sprint is investment.” Senior engineers operationalize this.

“What’s the worst tech debt you’ve inherited?” Tells what you noticed and how you prioritized. The answer should include “and here’s what I left alone because it wasn’t worth fixing.”

Reflective practice

Pre-write your strongest tech-debt-advocacy story. Have:

The pain (quantified).
The proposal (scoped).
The conversation (concrete).
The result (measured).
The lesson (generalizable).

Have a backup story ready in case the interviewer asks for a second example.

Interview angle

Senior engineers don’t just do tech work — they negotiate for the conditions to do tech work well. The interviewer wants to see: when leadership defaults to features-only, can you make the case for investment without making it a fight? Can you spot debt that matters vs debt that doesn’t? Will you operate inside the budget you get rather than sulk that it’s not bigger?