When we’re talking about what we’ve done, are going to do or haven’t done, one phrase inevitably comes up: “technical debt.” Scott, our VP of Product usually corrects the concerned engineer: “that’s technical leverage.”
Indeed, as a smaller, bootstrapped company, we must carefully choose our activities. We need to focus our efforts on impact — proving our ideas cheaply, intentionally choosing to avoid work until we learn from our users what the next step should be.
Fortunately, unlike financial debt, there are clear decisions to be made about technical debt. You don’t have to pay it all off today…you may not ever need to pay it off.
The way you achieve comfort with your technical, ahem, leverage is to ditch the euphemism and begin to discuss the real issues.
We started a conversation about technical debt, what it really is and how to deal with it. The first thing I tried to do to get my head around the problem was to think about what it actually meant. The phrase technical debt ends up meaning nothing, or encompasses so many things that it becomes a trigger for more work, big schedules and general pessimism.
Technical debt can be benign, like a quick hack to reduce the work required to get a release out as easily as it can be system instability waiting to cause a 3AM site outage. As I continued to list of all the things, Anthony, our VP of engineering, cut to the core of the issue: risk.
Whether debt will have an impact on us and how likely we are to feel that impact is what we really need to be thinking about. With that insight, Anthony adapted the binary risk analysis model to help us understand and categorize our debt. The process is ongoing, but we’ve started building a model to help us get comfortable with the debt that shouldn’t worry us and get proactive about the debt that should.