Many startups are familiar with the term "technical debt". Technical debt refers to situations when suboptimal code is produced to get a feature or product out the door quickly. There's often a good reason to do this (such as winning a new client or testing a new concept cheaply) but it does mean that at some point someone is going to need to refactor the code and build the system properly and until they do sp the code base is more difficult to maintain.
The interest that you pay on this debt is the increasing complexity of the code base (thereby making new developments more difficult to write, test or ship), more bugs to fix and the knock on the effect on morale of the dev team.
This concept of technical debt helps us to understand another type of debt, organisational debt.
All startups have organisational debt
In the early days of a startup, it's just not possible to create an entire company and system in one go. These things take time and sometimes you need to hack solutions. For example, until you've built your back office system, you might have people doing manual work to make it all happen behind the scenes. Another example is if you outsource a function to a third party until you're big enough to do it in house.
This is organisational debt. It's a temporary solution that you'll put right in the future and until you do you'll pay the cost of doing it sub-optimally. The price of organisational debt could mean having a higher salary overhead than needed to complete a task, it could mean high complexity or it could mean delays in gathering information.
Organisational debt makes sense if you are still developing and testing the business model. Startups are organisations in search of a viable and repeatable business model. Investing in processes and systems only makes sense once there are customers to serve and revenues being generated.
There's the right time to take out debt and there's a right time to pay it back
Scaling a business with a lot of organisational debt is risky. An organisation that works at 100 transactions a day could self-destruct at 1000 transactions a day if there are lots of manual processes. In the same way that taking on more financial debt than you can handle can put you at risk of bankruptcy, organisational debt can cripple an organisation trying to scale.
In what order should you pay back the debt?
The way I think about this is in three levels of priority in terms of reducing the debt.
First consider which processes and systems are closest to the customer and optimise those first. Above all else, the business needs customers and it needs a great customer experience. If it affects the customer experience, fix that first.
Secondly, I would focus on fixing the unit economics of the business. This allows the business to start generating a better contribution from each transaction gives a good base from which to scale.
Finally I would optimise back-office and overheads. Examples might be customer service systems, finance systems, procurement.
If the business is scaling and addressing point 3 before point 1 or 2, it would cause me concern. If 1 and 2 are getting good attention, it builds a good base from which to optimise point 3.
Of course this model is a huge generalisation but it's the best way I've found to express why it's OK to maintain some organisational debt as you grow.
It's OK to have the right kind of debt
As a COO I often had colleagues proposing ideas or projects that improved the efficiencies of the business. If these were in category 3 and we hadn't yet fixed 1 or 2, I would say that it was better to hold off on these projects and suffer the ongoing organisational headaches until we'd built a business worth optimising.
There's often a bumpy ride that a startup takes after raising Series A funding and much of it can be understood by the fact that some parts of the business mature first whilst the rest hasn't yet caught up. It can feel very difficult for the people involved and the challenge for the management team is to help people understand that it's a conscious decision to hold off on improving some parts of the business because it's the right thing to do to be in debt on that area at that time.
I think it's about recognising and sharing with the team that yes, we can and should do better (in the area which is chaotic), we will fix it but now is not the right time. It's not an easy thing to communicate and requires sharing with the team the big picture about what areas are improving and why they are the important pieces of the jigsaw to solve first.
As always, it's about priorities and it's about not taking on more debt than you can handle.