Debt is typically thought of as capital borrowed from one party to another. The borrowed capital has to eventually get paid back.
Financial debt helps finance and grow a business. The first iteration was a loan against collateral. Later, there were bank loans to start a business. Now, there’s credit card debt, debt with different levels of seniority, debt structured with hurdles contingent upon actions that unlock access to additional debt, interest only strips, credit default swaps, collateralized debt obligations, etc.
The concept of debt can be helpful outside of finance, particularly around the strategy for building a company. For instance, a missing feature is product debt, and bad UX for a customer need is design debt. While debt needs to eventually be paid, its thoughtful use is core to building a fast growing company.
Think of a company as a lego set where you need to build a massive castle. However, you don’t start with the correct pieces. You can craft new lego pieces, but that takes time so you build it with existing, non-optimal lego pieces that are less good at specific functions (e.g., wrong size so aesthetic is off or not optimal for weight bearing). Later on, you might replace the non-optimal lego pieces with pieces better suited, but your first task is to build the castle.
In the context of a software company, it’s debt when the prototype only supports 5 users when it’ll need to support millions of users years from now. Building a product that supports millions of users upfront is over investment because it takes resources away from other company goals (e.g., paying debt in existing parts of the product or growing product surface area in another initiative). Managing the tension between printing debt and over investing lies at the center of efficiently using debt at a company.
The following are examples of factors Ender considers when charting the optimal use of debt.
Organizational Management
- Tools we use: Daily standups, weekly meetings, all hands, 1:1s, performance reviews, leveling frameworks, performance improvement plans, directly responsible individuals (DRIs), autonomous teams, a delineated organizational chart
- Too much debt: Holacracy. No managers, everyone trying to figure out what to do with no visibility into what the rest of the team is up to. No directly responsible individual for any project. Complete organizational chaos
- Too much investment: Top down regimented. When asking anyone to help, they say “that’s not my job.” Everyone is so segmented that no one feels ownership over their job. Every employee is simply a cog in the machine
Product Execution
- Tools we use: Product specs, iterations with customers using tools like Invision, writing up use cases and workflows, documentation of client and customer interactions, issues grouped in epics
- Too much debt: No product specs. No documentation of why anything was built. No customer development notes nor client notes. Products and features exist but there’s no explanation of why they exist
- Too much investment: Product specs take dozens of revisions in pursuit of a perfect design when speed matters more than perfection. Everyone at every level of the company needs to approve each product spec. Even simple blocking feature requests from clients require the product team to create a spec with documented use cases that undergo review then get segmented into tickets that are then assigned to an epic and prioritized at the next quarterly “sprint”
Tech Execution
- Tools we use: Choosing a faster, simple solution that works for the immediate use case instead of a more robust approach that would scale better. Unit tests, automated and manual QA tests, code reviews, structured deployment process, code design reviews, brittle code, documentation.
- Too much debt: The code base is a monolith where any new feature causes dozens of other features to break. There are no tests to see if new code will break existing functionality. Scale becomes impossible with the current database and architecture. The entire codebase needs to be rewritten from the ground up.
- Too much investment: Developers need to write tens of unit tests before submitting code for review. Microservices are spun up before a long term use case is clear. Code reviews are so slow to occur that “new code” doesn’t match the production codebase. Simple blocking bug fixes need design reviews to discuss before implementing, testing, reviewing, and deploying to QA before going to production. Feature development stalls as excess structure deflates developer enthusiasm.
There are other forms of debt like marketing debt and design debt. There’s even debt in the business structure, e.g. I know a number of companies that started as LLCs knowing they later had to switch to C-corps. The switch is time consuming and expensive… but it can make sense under circumstances.
We have a philosophy of minimum viable structure. We let things break and only pay off debt when the team agrees bottom up that additional structure is necessary. When using the framework of debt, we think of it as minimum viable investment. Use the minimum amount of investment to accomplish the task at hand. There are triggers that alert us to add investment.
Reinvestment Triggers
In organizational debt, the triggers could be frequency of
- employee confusion around reporting,
- questions related to career development, or
- escalations related to employees arguing over scope of ownership
In tech debt, it could be
- frequency of tickets related to small outages,
- frequency of delta on performance for customer facing items (e.g., page loads taking 1 second instead of .1), or
- raw time investment of employees to ramp into complex codebases
We identify these triggers and monitor how often they’re happening. Once they exceed set targets, we use that as an internal trigger to reinvest to pay off debt. Without triggers, debt can easily get out of control. If tech debt gets too deep, then growth may halt while entire aspects of the product are rewritten.
I’ve seen companies stalled for years having to redo everything. On the flip side, I’ve seen companies let developers refactor for years and pause feature development even though there was no compelling business need to refactor.
Golden Mean
The key question is how much debt should be taken and under what conditions will it be paid off. Similar to financial debt, operational debt can have steep interest that accrues over time. There’s a golden mean or middle path. The tricky part is that the golden mean is different at stages of the product life cycle, and it’s different at stages of a company (e.g., for organizational debt, the org chart of the company at 5 people can be flat but at 1,000 people a truly flat org chart would be chaos).
Part of being in a startup is being ok with little things constantly breaking. Likewise, you also have to be ok with quick fixes instead of over investing to prevent any issues. If you’re not taking on operational debt, you aren’t going fast enough. At Ender, we deliberately choose our debts and make sure they can be paid.