There is a conversation that happens in almost every engineering team:
An engineer wants to fix something. The system is getting slow, the code is becoming hard to maintain, or there is a security gap that has not been addressed. But when it gets brought up in prioritization discussions, the answer is almost always the same: "not now, let's focus on features."
And on the other side, there are engineers who spend entire sprints on refactoring that changes nothing from the user's or business's perspective.
Both are problems. The first ignores technical debt until it comes due with interest. The second burns team capacity on technical satisfaction that delivers no real value.
The question is not "is this improvement technically good?" The question is: when is a technical improvement actually worth prioritizing?
---
One Simple Rule
Do the improvement if it impacts at least one of these three things:
If an improvement cannot be traced back to at least one of these, it is not a priority — at least not right now.
This does not mean the improvement is unimportant. But in a business with limited resources, every decision is a trade-off. And a good trade-off requires clear criteria.
---
Increase Revenue: When Technical Problems Erode Income
Not every technical problem looks like a business problem. But some of them quietly affect revenue — and you only find out after it is too late.
Example: the system has no rate limiting.
Without rate limiting, bots can hit your product pricing endpoints hundreds of times per minute. Competitors using such bots can monitor your prices in real time and automatically undercut you — dropping their prices just below yours every time you update.
This is not a technical attack. It is a business attack executed through a technical gap.
Adding rate limiting is not purely about security. It is about protecting competitive advantage — and competitive advantage is the foundation of revenue.
How to frame it for stakeholders: "Without this, competitors can know our pricing changes within minutes and adjust their prices before our users even see our best offer."
---
Lower Cost: When Skipping the Improvement Is More Expensive Than Doing It
Some improvements look like expenses, but they are actually preventing expenses that are far larger.
Example: no database backup.
Imagine a server crash. No backup exists. The team has to reconstruct data from logs, from partial exports, from memory. That process can take three working days of a senior engineer's time.
Calculate the cost: three days × a senior engineer's daily rate. Add the opportunity cost — during those three days, no features were built, no other bugs were fixed. Add the risk of data that cannot be fully recovered.
Now compare that to the cost of automated backups: a few dollars per month for storage, one day of engineering time for initial setup.
These numbers do not need to be precise to make a strong argument. Even a rough estimate is enough to reframe the conversation: "We are saving a few hundred dollars a month at the risk of a loss that could cost us tens of thousands in a single incident."
Lowering cost is not only about cheaper infrastructure. It is about avoiding large costs that have not happened yet — but could.
---
Achieve Compliance: When Regulation Is the Minimum Bar
Compliance is often treated as a formality — something done because it has to be, not because anyone wants to. But that mindset is dangerous, because regulations are not just about audits. There are fines, reputational damage, and sometimes legal consequences.
Example: storing user data without encryption.
If a breach occurs — whether from an external attack or an internal mistake — and user data leaks in plaintext, the consequences can stack up:
Here, risk and compliance overlap directly. Fixing it is not about being cautious — it is because the cost of not fixing it can already be calculated, and the number is large.
How to frame it for stakeholders: "Regulations require us to encrypt user data. If a breach occurs and we are not compliant, the fine alone could exceed this quarter's total revenue."
---
What About Risk?
Risk deserves its own consideration when the impact is real but cannot be directly traced to money or regulation — and nothing external is forcing the issue.
For example: the system has no circuit breaker for third-party APIs. If the payment gateway goes down unexpectedly, the entire application hangs. No revenue is being lost right now, no compliance is being violated, no fine is looming. But if it happens, the impact could halt the business for hours.
This is what can be called operational risk — risk to the business's ability to keep operating at all. It is not about profit or compliance, but about whether the business can still execute on the other three points.
In this situation, risk is worth treating as a fourth justification — but with one condition: the impact must be describable concretely. Not "this might become a problem", but "if this happens, here is what stops working, and here is an estimate of the impact."
Risk that cannot be described concretely is still worth logging — but it is not yet strong enough to become a priority.
---
Every Problem Needs to Be Known. Not Every Problem Needs to Be Solved Right Now.
This distinction matters: ignoring a problem and deferring a problem are two very different things.
Ignoring means not knowing or not caring. Deferring means knowing, having weighed it, and deciding that something else is more urgent right now — with the risk understood.
Healthy teams do the latter. They have a visible, categorized technical backlog that gets reviewed regularly. Every item has an estimated impact. When capacity opens up, they can immediately pick what is most valuable to work on — not just what is most technically irritating.
---
Passed the Filter — Now How Do You Order Them?
Once an improvement passes the three-category filter, the next problem appears: more than one thing passed. Which gets done first?
This is where three follow-up questions help:
Budget — is there capacity to address it?
Capacity is not just money. Engineer time, sprint capacity, and team focus are all forms of budget. Even the highest-impact improvement cannot be done if there is no one available to do it right now.
The important thing is to be honest about this. If budget is not available now, schedule it — do not let it float indefinitely. Improvements that keep getting deferred without a concrete date almost never get done.
Impact — what happens if it is not fixed?
This is about the magnitude of the consequence. Two improvements can both fall under "lower cost," but one prevents a loss of $1,000 and the other prevents a loss of $100,000. The order is clear.
Make the impact concrete. Not "the system could become unstable" — but "on average, we have X hours of preventable downtime per month, and each hour of downtime means Y failed transactions." A rough estimate is more useful than no number at all.
Urgency — when does the impact start to be felt?
A large impact that lands five years from now is not always more urgent than a smaller impact that lands next month. Urgency determines when you start paying the price for not doing the improvement.
Signs of high urgency: the problem is actively occurring, a regulatory deadline is approaching, or a triggering event (a small breach, a near-miss incident) has shown the risk is no longer hypothetical.
---
Using all three together:
This is not a mathematical formula — it is a conversation framework. When two improvements are competing for the same slot, ask: which one has budget available now, which one has the larger impact, which one is more urgent. The answers to those three questions are usually enough to make a decision that can be explained to anyone.
---
A Thinking Template
Before bringing a technical improvement to stakeholders, answer these three questions:
1. What happens if it is not fixed? Make it concrete. Not "the system becomes unstable" — but "on average, X hours of preventable downtime occur every week."
2. Which category does it fall into? Revenue, cost, compliance, or operational risk? If it cannot be placed into one of these, ask again whether this is a priority or just a technical preference.
3. What is the cost comparison? The cost of fixing it vs. the cost of not fixing it. It does not need to be precise — an honest estimate is far better than no number at all.
These three questions shift the conversation from "please trust me, this matters" to "here is the data, let's decide together."
And that is a far more productive conversation.