Originally published under Neap For Startups

How You Can Leverage Technical Debt & Why You Should

“There ain’t no good debt, only different types. A cunning hacker is one who leverages some debt, in some circumstances, to create good opportunities.”

At my previous company, our codebase was fraught with technical debt. That was a rather large company, and we had enough resources to reflect on how to mitigate it. At that time, I was convinced that technical debt was pure evil, and the result of inexperienced or sloppy developers. I believed that spending more time engineering the best code was better than cutting corners. I was wrong!

In a startup, technical debt is neither good nor bad; It is just a risk that you should learn to leverage.

In this great article Conceptual Debt is Worse than Technical Debt, Nicolae Rusan explains that technical debt is even costlier if the underlying concept behind a set of features is wrong by design. There are many more great articles about other types of technical debt (I’ve listed some of the more interesting ones here). However, though it is critical to be able to understand the nefarious effects of technical debt, it is even more important to start with understanding the context inside which that technical debt has been contracted. Because a large company is very different from an early stage startup, the causes and effects of technical debt are also very different. The only phenomenon that similarly contrives them is TIME. Both of them want to save time, i.e. reducing the time they waste on errands in order to reinvest that time in what matters. In that context, the old adage “Time is money” couldn’t be more adequate.

Large companies spend money to save time to make more money. Early stage startups spend money to hack time to find insights.

In the case of a large company there is a focus on optimization, and execution. In that context, technical debt is one of those nasty things that must be eradicated as much as possible. The case of your early stage startup is fundamentally different. Your early stage startup should be testing the validity of its business model. You probably operate with very limited funds, which means you only have a very limited amount of trial and error before you either run out of money, or hopefully find serious insights that could validate a repeatable and scalable business model. That does not mean that your startup does not seek to earn money; it just means that in its early stage, your focus should be on de-risking your business model, so you can focus on making serious money later.

Three years ago, I accepted my first job in a startup. In comparison to my previous experience in large companies, the environment was an order of magnitude faster, more vibrant, and more engaging. I was the first employee, and as the lead architect, in order to support the startup’s vision and strategies, my main goal was to enable to move fast from ideation to production. A few months later, we hired a front-end dev, and a few months later another middleware dev. Since then, we have acquired and shared a ridiculous amount of knowledge and new skills (which I think is the most exciting part in the startup journey, and one of the core missions at Neap). Very early on, we realized one fundamental principle:

Technical debt is a tool to grow your early stage startup faster.

That realization was a simple corollary of the following 2 rules:

1. Do not waste time over-engineering features that are testing your riskiest assumption. If your assumption is wrong, depending on the type of pivot, you may have to restart from scratch. At that point, your debt might simply be written off.
2. Speed up your Build-Measure-Learn iteration cycles as much as possible. If a hack allows you to deliver an minimum viable feature in a week instead of three, then there may be a huge benefit in contracting some debt, especially if that feature is testing one of the riskiest assumptions.

However, pay a lot of attention to the second point for it is particularly tricky to manage. Indeed, at the beginning, early hacks may speed up your iterative cycles, but over time, abusing hacks may accumulate too much technical debt, which could jeopardize your ability to iterate efficiently.

Smart hacking is essentially wise management of your technical debt to enable faster iteration cycles.

In an early stage startup, that represents a huge part of what hacking is. Your hack has a risk associated to it, but you and your team are hoping that this will enable you to produce an outcome that will cover the cost of that risk. Once your hack has allowed you to test your assumption, then based on the results, you could choose to manage your technical debt in one of two ways:

1. Paying your debt back: If your assumption was right, you’ll either refactor your feature, or completely rebuilt it.
2. Writing off your debt: If your assumption was wrong, ideally, you could write your debt off, and start working on another set of assumptions.

However, do not expect to be able to manage the above as an afterthought.

Not planning your technical debt is bad news.

Here are some techniques that can help you to get your technical debt under control:

• Make it as contained as possible. You want to prevent negative side-effects from leaking into the parts of your product/service that are healthy. That will also ease the refactoring process, or make it trivial to write it off.
• Make it reversible. A typical hack would be to hard-code some logic for a specific set of clients in your codebase. You could create a git branch from master containing those changes in a single commit. It would then become trivial to revert your hack in case you want to write your debt off.
• Make it traceable. Either document it, or wrap the code-hack with a consistent comment (e.g. //TOBECLEANED).

Unfortunately, in reality those 3 aspects are not easy to implement. You will need team members familiar with domain best practices, design patterns, and other advanced skills.

Assessing the trade-offs of hacking requires a lot of experience and expertise.

Here lies a tough challenge for your early stage startup. As a founder, you will have to surround yourself with people who possess a hacker’s mind. However, as we discussed it previously, hacking is a double-edge sword that only an expert mind can handle without wreaking havoc with your ability to iterate fast. Unfortunately, a hacker minded talent possessing an expert’s mind is a pretty rare beast these days, not to mention that he/she might be pretty expensive. If you’re struggling to find one of those mythological creatures, here’s some advice:

1. Everybody must have a Knowledge Crunching Spirit: You must have it, your co-founders must have it, your employees must have it, and ideally, your investors must have it to. This core skill will allow your team to fully understand what are the assumptions and domain models behind your current business model. That will make it easier to understand where and when hacking makes sense. Without this essential skill, there is a high risk of mismanagement of your technical debt.
2. A hacker’s mind that lacks years of expertise is better than an expert’s mind who cannot hack: Do not hire an expert who cannot hack in the early stage of your startup. A less experienced person who can hack because he/she understands the business model’s assumptions that the team is attempting to test will always be better than just being an expert. That being said, if a specific expertise is an absolute necessity to build your product or service, then you might have to accept the lack of hacking spirit. For example, if you’re trying to validate a new form of OS powered by some advanced A.I., you will obviously need some strong expertise in A.I.. However, if you’re trying to innovate in the food distribution industry, and you need a Java developer to build the backend system, then you may not need a Java developer with 10+ years of experience. Especially if this person is not able to Knowledge Crunch and hack.
3. Create A Symbiotic Space Where Hackers And Experts Co-habit: Your early stage startup team does not need to possess all the skills you need right off the bat. What matters is that they possess the right frame of mind so they will quickly gain those skills. They may not be proficient Knowledge Crunchers, hackers, or experts at the beginning, but the ability to learn fast means they’ll eventually get there. Focus on finding people with strong vertical skills, who are open-minded enough to challenge their current state of knowledge, and excited to share as well as to learn from others (an interesting model is the T-shaped employee profile used at Valve). At that point, your aim as a founder is to build a company culture where the knowledge can easily flow in any direction, and through everybody; which is one of the core ideas at Neap referred to as increasing your company’s Knowledge Liquidity.

I hope I have helped you to better understand the strategic value of technical debt in the context of hacking your iteration cycles in your early stage startup. If you’re interested in knowing more about various types of technical debt, I have listed a series of great articles here.

Did you like what you read? If yes, spread the love by clicking the ♡ button. You can also visit us on our website at neap.co.

DYDDMF — Knowledge Crunching in Your Startup ← P R E V I O U S