The art of technical debt management

Managing technical debt is a critical skill when developing new product, In this post I'll lay down how I see it, In these things there is no pure right or wrong but a balanced approached so I'll share how I try to balance.

This post focuses on startups where technical debt management is a matter of life and death. All applies to established businesses as well, except the price of the mistake.

New product life cycle

I took this definition after hearing Steve Blank in some lectures, I find it simplifying things just about right.

In the post I will mainly refer to customers of your product (i.e. Sales), but it applies (more or less) to user acquisition as well if your product customer’s aren't your users (e.g. FB or Google).

MVP development

You have an idea and it's going to change the world, MVP is the minimal product that brings your idea value to your customers or users. Your MVP market is small, super small because only few can get along with minimal capabilities and still keep using the product.

Defining your MVP is not that simple and requires a lot of customer validation work, once defined its all about running for a first release.

This phase is about R&D at most of it.

Product market fit

So your first version is out, time to meet your customers. In this phase you are establishing your product market and business model:

Are your customers willing to pay?

How much margin has it left you?

What is your customer acquisition cost and lifetime value?

Without going into details, by then end of this phase you have a POC of your money (or user acquisition) machine, A recipe that once repeated (and can be repeated) will bring a positive flow of revenues or new users to your product.

This phase is a mix of R&D and sales.

Scale

This is where sales and marketing kicks in high gear, this is the phase you actually prove your model is repeatable and scalable.

This phase R&D focuses on support, customer success and critical new customers on-boarding features.

Let's agree on the goal

In my mind the goal is simple, Build something that brings value to people and make them happy returning value to you. The goal is not:

Writing/Designing beautiful SW/HW

Having fast release cycles

Have a little amount of bugs

Using the latest and greatest frameworks/languages/features

Have a great UI, dashboards, Charts and reports

Have the best performance

…

In one word sales. Your product will die sooner or later if not making sales.

What matters at the end of the day?

You need to prove someone is willing to pay for the value your product offers, more than it cost to you generate this value with good profit margins (not discussing here what good means).

Sales are hard and technical people tend to underestimate how hard it is, When developing a new product its the hardest part. This is the line between dreamers and changers. With this is mind, develop your product facing your #1 challenge from day 1, sales.

So what does it have to do with Technical debt?

Why technical debt is critical to manage?

You have to move quick. You have to respond to market opportunities, customer requests and deals on the table.

Does your customer care this piece of code is a nightmare and not to be touched? Does your customer care if you are using NodeJS or Ruby?

In most of the cases your customer doesn't care about your internals, this is your problem. Sales have promised a value and you as a developer / Researcher should deliver that value. If you fail to deliver the value your product just lost a deal and got unhappy customer. Worse result, then any code or circuit issues you may feel are critical to solve, Your customers are the reason you are doing that job, If they leave you can follow.

Your customers are the reason your job exists

The two types of technical debt

Like all debt its borrowing from the future in order to use in the present. Unlike financial debt where you loan money for your future in technical debt you loan R&D and like all loans you will pay more in the future for present consumption.

How does it look like from 30k feet? You code/design, super fast while neglecting many cases that will come back to haunt you in the future.

TB Type I

This is what most developers consider technical debt, it involves these behaviors:

• No SW/Ad hock architecture, A lot of functional code pieces.
• No using testing, Weak QA.
• No CI/CD or automation.
• No environment setups, install recipes.
• No docs or manuals (or unupdated ones).
• Fragile/spaghetti code.
• Wet code
• And more…

TB Type II

These are, the bigger technical debt items, In many cases, they are not perceived as debt up until scale or product market fit, it involves these behaviors:

• Selecting the wrong chip for a product.
• Using the wrong communication protocol/method.
• Selecting bad framework, not a suitable coding language.
• Using dead (non maintained) open source.
• Using unstable technologies to build on top of.
• And more…

The “right” balance

Strong technical people are very sensitive to Type I but are not immuned against type II. Type II debt is much more dangerous, While type I will slow down your scale and product market fit, Type II can easily kill your product/TTM.

In my mind don't bother to deal with Type I until you are truly sure your Type II balance sheet is clean. Of course you should not completely ignore Type I problems but you should be much more forgiving. Till when?

As long as you don't have confidence in your product market fit you should ignore (with care) type I problems (Does your awesome unit test help when you need to change your framework or protocol)?

Once you are getting solid base to believe your technology stack and architecture will do, Its time to give more focus to type I issues.

There is no transition day

Getting confidence and gradually moving from solving type I instead of II is a process, the more customers and deployments you get, the higher your confidence, and they higher the price you pay for Type I debt.

In dataloop we estimate it every few weeks, things we feel are more solid on there Type II areas and going through refactore and Cleaned from type I issues. This is a slow, balanced process that is critical for our success. Especially if you are a startup and failure is not an option.

So becarfull on slowing yourself down to make things right from day one while product is still defining itself, watch out from maintain quick and dirty technology very long time in your customer’s house.