Understanding Technical Debt as a tool for growth

The word ‘debt’ is almost universally negative. It conjures up thoughts of maxed-out credit cards, overdue business loans, stretched financials, and a struggling business. Of course, that’s not always the case – many companies are innovative about borrowing, using funds to boost growth and repaying their debts with eventual profits.

Technical debt is a way to explain the lag between developing a product and optimising it – it’s the rework and back-dating that needs to happen when your business grows quickly. In many ways, it’s similar to financial debt. The name sounds negative, but it’s often a necessary tool to help businesses in rapid growth phases. And, much like financial debt, technical debt can be harmful if it doesn’t result in increased market share or profitability.

Here’s how to define technical debt – and why it’s a vital tool for startups and software companies.

Defining technical debt

You incur technical debt when your business must reach a certain point quickly. Instead of working through every angle, ticking every box and providing an optimised final product, you take shortcuts, cut requirements down to the basics, and just get the product out there in some form. The debt is the time and cost of returning to fix problems, rewrite code and develop more features to flesh out the final product.

Every software developer has skipped writing a unit test, implemented some quick-and-dirty code in a time crunch, or written workarounds instead of getting to the root of a problem in the system. It’s like using a credit card to cover small business expenses – it’s easy and quick, and you don’t need to worry about the consequences until later.

Why technical debt is a must-have

When a business starts or develops a new product, time is of the essence. The more time you spend developing, refining and optimising, the more you spend on a completely unproven product. That’s why getting a product in front of your customers is crucial – even if it’s not the perfect end result you have in mind.

For example, a business developing a time-tracking software solution might release an early-stage product with minimal features – basic time-tracking for individual employees – sign up customers and then push out new features in the development phases. Phase two could involve introducing project management features; phase three might include reporting functionality. Developers also have the chance to fix bugs and resolve issues as they arise – early customers are the ideal testers for a new product.

It’s about making trade-offs. In most cases, taking on technical debt can help reduce the financial debt incurred by a long and potentially fruitless development phase. Speeding up the development process means getting an MVP to market and testing product-market fit sooner. If the product isn’t viable or doesn’t have the expected market impact, you’ve spent less time, money and energy on development, and you’re in a better position to move on to the next solution. If the product is viable, you can start onboarding users and pitching to investors, then work on repaying your technical debt. 

The problem with premature optimisation 

Product perfection and a complete lack of technical debt can sometimes be seen as red flags. It may be a sign that your business is scaling and developing slower than it could be. Investors want to see their investments come to fruition as quickly as possible – they don’t want their money tied up in a never-ending development stage.

Fully realised, optimised products are the dream – but they also require a lot of energy and time to develop. Premature optimisation happens when a business builds and implements a functional, robust, feature-heavy system without market validation. The product may be scalable for user load and functionality, technically perfect and beautiful, and completely technical-debt-free – but it’s all an expensive waste of effort without a market.

Instead, smart software startups use technical debt as they do financial funding. It’s an investment in the future of the business that helps get them to market sooner, increasing future value and allowing them to optimise later. While it may be frustrating for some developers to push out a less-than-perfect product, it’s a necessary part of the development process, particularly in the SaaS environment.

Identifying tech debt

To get perspective on your technical debt, put yourself in the shoes of a VC looking to invest in your business. What would they think if they were to look at your system architecture and rummage around in your code? Is your technical debt mounting up, or are you remediating it constantly? Have you been putting off significant technical debt for a long time? Do you have a plan to reduce ‘bad’ technical debt and fix old issues?

You make technical decisions with the knowledge you have at any given point. As much as you’d like to, you can’t see into the future, and often, shortcomings or missing features only emerge as your business grows and needs change. You might make some decisions knowing you’ll have to go back and rework, while others can seem like the best choice until new information comes to light.

For example, a business could choose to build its software on a database that works for the initial system load, and then find that it can’t keep up with growth. While this may seem like a major error in judgement, the decision was made with the information available. Why invest in a high-performance, costly platform for a product that hasn’t been tested in the market? With a proven market and growing customer base, the business can shift to a new platform, repaying its technical debt with its newfound success.

Getting your head around tech debt

One difference between technical and financial debt? Visibility. In most businesses, financial debt is crystal clear, with a clear timeline for repayment and obvious consequences if the debt is not repaid. Technical debt can be murkier – there’s not always a way to see messy code or missing features, and it can be difficult to plan your technical ‘repayment schedule’. It’s easy for technical debt to pile up, too, with bad code on top of bad code, workarounds taking up more and more time and no plan for a complete reboot of a faulty system.

However, these aren’t reasons to avoid technical debt – they’re reasons to be savvy about the process. It’s crucial to understand the level of debt you’re taking on and how long it will take to pay back. If you take on technical debt thoughtfully, the returns should be greater than the work needed to repay it. It’s important to make sure you are managing your technical debt effectively. In our next blog, we will look at good debt, bad debt and strategies to make debt work for you.

Are you getting your head around your tech debt? Talk to the Parallo team and we can lend a hand.