Teams get stuck when quality, speed, and debt are treated as moral categories. In practice they are portfolio decisions under constraint: time, risk, customer impact, and the cost of change later.
This is how I negotiate them. It is opinion shaped by shipping production systems, not a universal law.
Define quality as operable outcomes
“Quality” is vague until you name the failure you refuse. For backend and platform work, I usually mean: correct behaviour on the hot paths, recoverable failure modes, and a change process that does not require heroics.
Tests matter. So do migrations, dashboards, and the ability to explain a production incident without archaeology. Quality that only exists in a PR checklist is incomplete.
Speed is a system property
Delivery speed is not typing speed. It is how quickly a team can go from problem to safe production change. Unclear ownership, flaky environments, and hidden coupling destroy speed more reliably than “not coding fast enough.”
When leaders ask for speed, I translate the request into: which feedback loops are slow, and which risks are we accepting to go faster?
Technical debt is a balance sheet
Debt is not every imperfect abstraction. Debt is a deferred cost with interest: slower changes, higher incident risk, or knowledge trapped in one person.
Good debt is intentional and dated—“we will revisit after launch.” Bad debt is invisible and compound. The fix for bad debt is not shame; it is making the interest visible in planning.
A simple decision filter I use:
- If the change is on a high-blast-radius path, bias toward quality and operability.