One of the lines that hit me the hardest, but also helped me truly understand my role at work, is:
“We are not here to build cool software; we’re here to support the business.”
While I love using the latest technologies and writing clean, modern code, those things are only tools that help the business succeed.
Quarterly revenues must be met. Features must be released. Promises made by an overly ambitious sales team must be kept. Our purpose is to impact the bottom line, and our solutions are how we do that.
Sometimes, a “solution” may be as simple as having someone manually write on a form. You could digitize it, but that introduces something else to maintain. Is it worth it? If the form is used once a month or changes regularly, maybe not. Maintenance can quickly outweigh the benefit. When it is not kept up, the form becomes useless.
As we create technical solutions, decisions must be made. Some of these decisions do not immediately show up as dollars and cents. Product teams might see them as optional. However, defining the kind of work you are doing, why you are doing it, and how it benefits the business is essential. Here is how I have been organizing that conversation.
Not All Work Is Technical Debt
It is tempting to label all behind-the-scenes technical work as technical debt. After all, it rarely delivers visible features or direct value to users. But just because a task does not increase revenue directly does not mean it is debt.
I group this kind of work into three categories that help make sense of it:
Technical Debt – The interest you pay because of delayed or poor decisions.
Technical Maintenance – The cost of staying in business.
Technical Enablers – Today’s investments that create tomorrow’s efficiency.
Technical Debt
Here is an example that happens often. Developers finish a feature that meets the business definition of “done,” but they skip writing unit tests. A concession is made, the work goes out the door, and the missing tests are never written.
Months later, a change is needed. There are no tests, so developers must verify everything manually. It is slow, error-prone, and frustrating. That is technical debt.
Technical debt is not the same as old code. Old code can be perfectly fine. I probably have code running in production that I wrote over ten years ago. Debt happens when changes become harder and more expensive because of earlier shortcuts.
In this case, skipping automation was the shortcut. Every time we revisit that code, we spend extra time remembering edge cases and scenarios. Over time, the cost adds up until the team decides it would be easier to rewrite it from scratch.
Technical Maintenance
Ten years ago, I could not have predicted how common cloud adoption would become. Three years ago, I could not have predicted how AI would reshape our work. Three months ago, I could not have predicted the latest change in business requirements.
The world evolves, and our systems must evolve with it. Maintaining our tools and platforms ensures that we can support the business, use supported technologies, integrate cleanly, and remain secure. It also helps us retain and attract talent. Very few developers want to work on outdated technology.
Technical maintenance does not add direct revenue, but it prevents problems and allows the business to continue operating smoothly.
Technical Enablers
As businesses grow, requirements change. We want our systems to be more resilient, maintainable, and secure. Some work might not immediately affect revenue but can reduce errors, improve developer efficiency, and prevent data loss.
These improvements are technical enablers. They are investments that make future development easier, faster, and safer.
Do It Right, Even if You’re Doing it Wrong
Concessions are made every day in software development. The moment you write a line of code, you have introduced some level of debt into your system. The key is to take shortcuts strategically. Even if you accept technical debt, do it in a way that allows you to retrofit improvements later.
In the example of missing unit tests, if you are aware that debt is being introduced, at least design your code so that tests can be added later. If you are not adhering to sound coding practices, it becomes impossible to repay that debt.
Uncle Bob states, a mess is not technical debt. Technical debt involves conscious decision-making. Messy, careless code is simply a mess and requires significant cleanup. Debt can be managed; chaos cannot.
A Simple Analogy: Cars
To explain this concept to non-technical teams, I often use cars as an example. Everyone understands car maintenance and upgrades.
Technical Maintenance
You need to get oil changes, refill gas, and check tire pressure. These tasks do not make the car faster, but they keep it running. If you ignore them, the car will eventually fail.
Technical Debt
You skip oil changes because you are busy. At first, nothing happens. Later, gas mileage drops, and the engine starts making strange sounds. Eventually, the engine seizes, and you are stuck with a huge repair bill. That is the cost of ignoring maintenance and letting debt accumulate.
Technical Enablers
Think about how car keys have evolved.
My first car, built in 1996, used a metal key that I had to insert and turn. My 2005 car had a push-start button that required inserting the key fob. My 2022 car no longer requires inserting the fob at all. My next car will hopefully have remote start because winters in Chicago are cold.
Could I still drive a car with a metal key? Sure. But the newer systems make life easier and more efficient. Each upgrade represents a technical enabler.
It Is Not Always Clear-Cut
There is often overlap between these categories. Some technical enablers require maintenance. Some maintenance removes debt. Sometimes an enabler can eliminate debt entirely.
If you know you have to ship with some technical debt, be intentional about it. Identify the debt, and keep it in your backlog with a real plan to come back to it. Designs evolve, and priorities shift, but documenting known debt helps your team stay honest and transparent about trade-offs.
But your team is agile (Right, right?!). Your product team will need to understand when something must be reworked without an immediate business benefit. That is part of continuous improvement.
As you work with your teams, use these terms to clearly explain where effort and resources are going. Words matter. Use them thoughtfully. Be prudent. Keep your backlog up to date, and acknowledge technical debt when you can.
