I worked for a long time on a product that issued credit to customers. The real USP for many of the customers was how much the product simplified the online shopping flow. It was so convenient that it was always worth using—it saved customers the hassle of getting up from the couch, fetching their card, and filling out all the necessary details. Many customers didn’t even understand it was a credit offer but rather as a service to pay after receiving the goods. It only became a credit service if they created a long-term installment plan to divide payments over time. For many, the credit that was issued and made online shopping so much easier was seen as a positive feature.
I mention this here because, in many cases, credit or debt can be something positive. It’s like oil in the machinery that keeps everything running smoothly. This concept applies to product development as well. Sometimes, being first to market or validating a hypothesis as quickly as possible is more important, and in such cases, credit is often necessary. You don’t have time to build everything perfectly, shortcuts are needed to quickly get something out to customers. What’s critical is what you do after you’ve obtained the feedback you need and how quickly you create a plan to “pay back” that debt.
Another perspective on this, beautifully summarized by my colleague who attributed it to all software developers, is the quote: “If I had known what I know now, I would have done it differently!” When we start building something, we have limited information, and we learn along the way. By the time we finish, we know far more than when we started. This is natural and unavoidable, and those project methodologies that try to mitigate it by planning everything in detail before building starts fail all the time. The key is to iterate as much as possible and have the ability to revise what’s already been built based on your new knowledge.
The product I referred to earlier didn’t accumulate much technical debt compared to others I have seen, and the way we worked helped keep it at a manageable level. We had teams with clear responsibilities for both business and technical aspects, and their broad competencies allowed them to build customer-focused solutions while maintaining good technical quality. They were empowered teams working in a customer focused product model.
However, I’ve also worked on other financial products where the concept of debt and compounding interest should have been better understood. These products often carried an enormous burden of technical debt that was largely ignored. The patterns I’ve observed in such cases typically involve companies that are either project-driven or operate with a command-and-control culture, where stakeholders dictate detailed functionality to IT teams without considering the bigger picture or listening to the teams.
Projects, by definition, are short-term efforts designed to deliver a predefined scope and then disband. This setup often discourages teams from building long-term, stable code or fixing older issues, as that risks missing project deadlines.
Command-and-control cultures or output-driven organizations, where business stakeholders order functionality from IT, also tend to fail. IT is often too weak to push back and explain what’s actually needed, and when they eventually realize a rebuild is necessary, it’s often too late and too costly.
Why do we get Technical Debt?
- Neglecting Reflection: After building something, teams fail to ask, “Given what we know now, what would we have done differently?” Instead, they move on to the next task and leave the earlier work unaddressed, with no plan to “pay back” the debt.
- Using New Technology: While adopting new technology is often the right choice to create cutting-edge solutions, it comes with a learning curve. This means that by the time the project is complete, teams may need to revisit and improve their earlier work based on what they’ve learned.
- Standing Still: If you don’t move forward, you’ll fall behind. This applies to technology as well. The requirements for systems have likely evolved since they were first built—more users, more interactions, or new frameworks. If you don’t adapt, you’ll be stuck with outdated solutions. Frameworks and tools often release new versions to fix previous issues, and failing to update leaves you vulnerable to inefficiencies and risks.
The Consequences of Ignoring Technical Debt
If you ignore technical debt, it grows. The concept of compounding interest applies here: if you don’t pay off the interest and principal, the debt will grow into an unmanageable burden. This is when IT comes forward and says everything needs to be rebuilt from scratch, but by then, it’s often too late. Large-scale rewrites frequently fail.
The result of unchecked technical debt is that everything slows down—development, deployment, and innovation—until it comes to a halt, preventing new functionality from being released.
Addressing Technical Debt
To avoid or start getting rid of your debt problems there are a few things you can do
- Avoid New Debt: Begin working iteratively and continuously improve your code.
- Tackle Existing Debt: Understand that paying it off will cost time and resources, but balancing functionality development with technical improvements can prevent total stagnation.
If you start with the following habits it will help you as well:
- Continuous Refactoring: Regularly revisit and improve your codebase.
- Automated Testing: Ensure you can refactor safely.
- Collaborative Teamwork: Use pair or mob programming to share knowledge and build better solutions from the start.
Another way to get started is to use the same pattern as for empowered teams. Divide your systems into smaller modules and start breaking things out, with clear APIs and responsibility for each module. It is then easier to refactor each of those smaller modules one by one and still living up to the API.
Iterate Beyond the MVP
A common mistake is believing a feature is “done” once the MVP is launched. Iteration doesn’t mean breaking a big task into smaller parts and building them sequentially; it means revisiting and improving what you’ve already built.
Cultural Barriers to Addressing Debt
In some organizations, there’s a reluctance to tackle technical debt or even acknowledge its existence. My suspicion—though unverified—is that it often comes from leadership’s unwillingness to admit past mistakes. For example, a long-serving manager who allowed technical debt to grow unchecked might avoid addressing it to prevent exposing earlier poor decisions. Instead, they may downplay the problem or stick to current methods, even when faced with evidence that a change is urgently needed.
Addressing technical debt requires courage, transparency, and a commitment to improvement—qualities that must start at the top.
If you want to learn more here is the list of the current inspirational seminars we hold, if you dont persuade us to talk about another topic. Give us a ping if you are interested.