“‘Tech debt is taking a loan against next month’s income in order to buy a feature today”‘
The rollout of our founder and CEO Mik Kersten’s Flow Framework® has led me to a whole new understanding of how software should be built.
At first, I wasn’t sure about the idea that there are four (and only four) types of work involved in delivering software, and I spent a lot of time thinking about how to debunk this idea. The more I thought about it, however, the more convinced I was that Mik was right.
One of the many revolutionary ideas of the Flow Framework – from Mik’s Amazon-bestselling book Project to Product – is that there are four categories of deliverable work that are pulled by the customer across the software delivery value stream:
- Features (business value)
- Defects (quality)
- Risk (security and compliance)
- Debt (impediments to future delivery)
They have the wonderful quality of being mutually exclusive and comprehensively exhaustive. Everything we deliver will fit into one and only one category. None of these terms are exactly new, and it’s not that the Flow Framework is redefining software delivery work per se. It’s that by knowing these categories, and fitting your existing work into these umbrella terms, that you can do amazing things like determining:
- Flow Distribution (the ratio of flow items over particular timeframe)
- Flow Velocity (the speed of delivery)
- Flow Time (measures the time it takes for work to be completed across both active and wait states)
- Flow Efficiency (the ratio of active time vs. wait time out of total flow time)
- Flow Load (the number of flow items in progress)
With all that said, I started thinking about technical debt and how it impacts a company’s ability to deliver. I have a tendency to think in analogies and “tech debt” is a wonderful analogy. The term was first coined by Ward Cunningham to explain the concept of borrowing against the future. But like all analogies, it’s not perfect – as we can see if we compare and contrast tech debt with financial debt. I think that there are some interesting things to learn from this comparison.
The similarities and differences between financial and tech debt
Both relate to borrowing against the future. Both styles of debt are taken as a shortcut to accelerate the business in one way or another, with the expectation that the debt will be paid off at some point. Both styles also assume that the cost of the debt is less than what you gain from taking the debt.
With financial debt, there is the explicit assumption that the return on investment is greater than the cost of the capital. You expect the ROI to be greater than the interest rate of the loan.
With tech debt, however, there’s a similar, but a slightly different assumption. You still anticipate the benefit of taking on the debt is greater than the cost of the debt, it’s just that the benefits and costs of tech debt aren’t clearly defined.
Unlike applying for credit, tech debt doesn’t require an external party to agree to lend the money. Even with a line of credit, the line of credit has to be set up in the first place. A bank or other financial institution has to agree that I have sufficient means to repay them. There’s no such agreement with tech debt.
A software development team can take on debt completely on their own without the permission of an outside agency. You may argue that developers should get permission from the product team or from the business as a whole before taking on debt, but that’s quite different than asking for debt from a bank. Since there’s no explicit account stating how much you owe, the rate of interest, or any covenants to repayment, it’s difficult to know exactly how much technical debt there is to pay off. While financial debt may be complicated, the terms are explicit.
Can you tell me how much tech debt you owe on your product? You may have a gut feeling of ‘a lot’ or ‘not very much’. But imagine if you asked a CFO how much debt his company owed and the best they could say was ‘not much’. You wouldn’t have much confidence in their abilities. This difference makes dealing with tech debt incredibly challenging.
There’s also no interest payment. Now you’re likely thinking, ‘That’s not true. There’s always interest on tech debt.’ I agree that there is, but there’s not a direct interest payment. Without a credit account, where does this tech debt interest go? How is it accounted for? I’ll get to that in a bit.
The cost is exponential. This is similar for both financial and tech debt. If you have little debt to begin with, taking on some debt can likely be done with a low-interest rate (even though there’s not an explicit tech debt rate). As you accrue more debt, each incremental bit of debt has an ever higher cost and that cost won’t be linear. Tech debt makes everything more expensive.
With financial debt, there’s an interest on the debt itself, but that has no impact on the sticker price of anything else you want to buy. The asset you want still costs what it costs. You may need to take a loan to buy it (and that loan has interest), but the cost of the item is still the same. Not so with tech debt.
With tech debt, you don’t have a direct interest rate on the debt, but what does happen is that the features you want to buy with your engineering effort become more expensive. The defects you need to fix become more expensive. The flow items that you need to deliver to your customers all become more expensive to purchase. That’s where the interest rate comes into play with tech debt. It’s as if you took out a loan to buy a car and then the cost of bread at the grocery store jumps by 10% just for you. This makes the actual cost of tech debt hard to calculate.
What you gain and how you pay them back is different. This is perhaps the biggest difference between financial and tech debt. With financial debt, you borrow dollars today in order to have more dollars tomorrow. With tech debt, you borrow capacity today in order to make sales tomorrow. With financial debt, the gains help you pay down the debt. With tech debt, you don’t gain extra capacity tomorrow. Because of the added cost of your future flow items, you actually end up with less capacity than you otherwise would have, had if you’d never taken on the tech debt in the first place.
At best, strategic use of tech debt can help grow revenue, which may indirectly lead to more capacity if the company decides to invest in more developers. In this sense, you can think of engineering capacity as a relatively constant income that you can spend. Tech debt is taking a loan against next month’s income in order to buy a feature today. Eventually, you’ll have to pay back that debt because your other flow items will continue to cost more than they would have otherwise.
[Blog] Do you have “Dark Debt” in your IT organization’s culture?
Want to learn more about tech debt and how to pay it down?
Chat with us today about better managing flow items in your software delivery value streams through value stream management.
We also offer specialized workshops and courses with the industry’s leading authorities on flow and value streams:
Visualize your value stream (with one of Tasktop’s Value Stream Architects): This free one-hour consulting session will help you identify the value streams within your organization today, visualize the flow of work, and help identify opportunities to make your value stream more tangible. Learn more.
Value Stream Management Workshop (with Brian Ashcraft): This 90-minute workshop uncovers how to accelerate organizational transformation with value stream management. Participants learn from recognized leaders about the concept of flow and how to champion VSM within the organization to empower teams, achieve process excellence, improve performance and deliver better results. Learn more.
Flow 101 Workshop (with Dominica DeGrandis): Flow is the continuous smooth and fast delivery of business value, and is the first of the three foundational principles underpinning DevOps. This two-day hands-on workshop shows you how to enable flow in your organization using lean practices. The workshop is best suited for teams engaged in Agile or DevOps transformations who are looking to leverage Value Stream thinking to make their transformations more successful. This gives teams the opportunity to discuss and determine prioritization policies, workflow design, and metrics used to measure team performance. Learn more.
