In an earlier article I looked at the various way how to communicate tech debt. But only very few people will actually care about any form of debt if they don’t have to pay interest rates. This is where the magic of a meaningful charge back model comes into play. Let’s take a look at two illustrative teams working on different technology platforms.
Team 1 works on a platform that accumulated a lot of tech debt over time. Here one developer is working on features and four of his colleagues are working on the interface mess, trying to cope with outdated code and thus the team one has a velocity of 1 complexity point / person month – while Team 2 working on a modern platform has a velocity of 5 complexity points / person month. This seems a wide spread but is actually in line with what I have observed in some real-world situations after counting function points with different teams.
What usually happens in the annual fight for a limited IT budget is :
- Approach 1: Team 1 and Team 2 are of similar importance and they therefore get the same budget, e.g. 100 person months. Team one is going to produce 100 complexity points with this while Team 2 will be able to produce 500 complexity points.
- Approach 2: Quite often Team 1 will have a longer history and is used to spending more money for the same output so Team 1 might get 500 person months and Team 2 only 100 so that both of them are able to create the same output.
The problem with this approach is that there no inventive for the business owners of Team 1’s functionality to reduce the tech debt. They are paying massive interest rates on the tech debt but it is not transparent there therefore they lack any incentive to work no the underlying root causes. This is where a clever charge-back mechanism can help. In this approach we separate the feature budget from the “interest” being payed for tech debt.
In this approach both areas get the same budget for feature development as in Approach 1 from above but the “productivity gap” is explicitly charged back to Team 1 – therefore their overall budget is 500; while Team 2 gets much more done with a fraction of the money.
You might think this is only left pocket, right pocket accounting. If you think so you have never been part of one of the fierce battles for next year’s IT money. These discussions tend to be very heated and with this kind of transparency the Team 1 responsible will have a much harder time justifying their spending and therefore is incentivized to invest into refactoring and the reduction of tech debt.
How to implement this in practice? In this article I listed a few ways how to potentially measure tech debt. So take one of these metrics, and with some basic math you should be able to extract a tech debt part of your IT project portfolio that can be charged back separately.