Back
Over the years I have seen more than one non-technical person get really upset when an engineering lead mentions “technical debt”. As an engineer this has been the butt of more than one internal laugh. However, in thinking about it this really isn’t a laughing matter. To understand the problem and propose a solution we will use the following example conversation.
Non-technical: “Customer A wants us to add feature X to the product. How hard does that sound?”
Engineering: “Sounds like a good idea. Shouldn’t be too difficult but before we do it we need to resolve some technical debt around Y.”
Non-technical: “What’s the technical debt around Y? How long will that take?”
Engineering: Gives a description and then says: “Should take two or three sprints to clean up the debt.”
Non-technical: Pause. “Why does everything take so long around here? Every time I talk to you all I get is excuses!”
Engineering: Blames company for not properly managing debt, etc..
Does this conversation sound familiar to any of you? I’ve experienced similar conversations multiple times in multiple companies. In fact, at a previous company a CXO got so upset he threatened to fire the next person that used the term “Technical debt”.
The problem
Clearly there is an issue here but what is it? Does the CXO not want to acknowledge past decisions? Is the engineering team using technical debt as an excuse? Is engineering padding it’s estimates to “sand bag”? Why do we have so much technical debt?
This all boils down to a communication issue. Bringing up the technical debt after the fact does sound like an excuse. Because the technical debt has not been quantified previously it also leads people to think that engineering is “lazy” or “sand bagging”.
In actuality the CXO has every right to be upset. But being upset at the term “technical debt” is pretty humorous.
The solution
In my previous article “Are you planning to become technically bankrupt?” I have discussed some of the issues with technical debt and how to track it. It is a fact that technical debt slows down the engineering team. The longer the debt goes unpaid the slower the team goes. So what’s the solution?
Track your debt after every sprint
In my previous post I made some recommendations on how to track technical debt. Feel free to take a look for some ideas. The important thing is that you develop debt metrics that are tracked consistently and accurately. This is going to take some effort but will help to avoid uncomfortable and emotionally charged conversations like the fictitious one above.
Communicate your debt metrics to the entire company
Typical engineering teams do have metrics. They may or may not include debt metrics today. Once these metrics have been developed and agreed upon they need to be communicated to the entire company.
The company needs to decide on a format that everyone has access to and a method to distribute these metrics. I personally think a portal is best as it ensures that the data doesn’t get stale. However the downside is you rely on the employees to actually login and look at the metrics. Also, if you use a subscription based service things can get expensive quickly.
Another barrier is training. Engineers understand what stories and points are but these terms can be quite confusing to the rest of the company. Ensure that the company gets training and that the metrics are displayed in an understandable way. I recommend that you convert your metrics into laymen terms by using averages.
Quantify the drag debt is having on engineering
This one is a lot harder to pull off but here is how I have accomplished something similar in the past. WARNING: This took a significant effort but helped support my stance that refactoring would cost the company less money than continuing to ‘fix’ a broken solution.
-
Categorize all existing/previous issues related to debt
-
Estimate effort to resolve issues
-
Estimate new issues for the next 12 months (using historical information)
-
Add items 2 + 3 above. This is the effort to maintain the solution for the next 12 months
-
Translate into man weeks using a calculation similar to above
-
Compare and contrast the results of #5 with the estimate for refactoring
This does not take into account ‘opportunity cost’ of not being able to add new features or respond to the market in a timely manner but it is a starting point. With this information you can start to discuss the cost of not refactoring.
Final Thoughts
As stated the ‘frustration’ with technical debt boils down to the debt not being quantified nor communicated to the rest of the organization. By doing so your engineering team will have a much better understanding of the debt. Armed with the ‘facts’ future conversations can be much more productive and a lot less emotional.
