_or as a person in a CTO-like role_
Ah, the technical debt.
While the concept is sweet from the business perspective, the result of leveraging technical debt, most often, is a big mess.
The technical debt is accruing every week, after each iteration, sprint, what have you. Your developers are whining about it, and they want to do a significant rewrite or solve it with microservices altogether.
And you know this rewrite, like others in the past, will be a significant sink of time, and likely a catastrophe.
This is how I see it from my humble developer/team lead perspective. I’m really curious to know how people in CTO roles perceive it.
I agree that this is a useful quality lever that can get the whole company out of a bind, or could let business leverage a market opportunity before the competitors do.
What I’ve found is that people in various project-manager-like roles tend to overuse this lever. I believe this lever should be used only when there is a significant gain for the business, and the debt should be paid shortly after that.
What I’ve personally seen, and what I’ve been told by my fellow developers, is that it is common to use the technical debt lever just to:
- reach the “sprint commitment,”
- meet the artificial deadline,
- increase “developer’s productivity,”
- show manager’s power.
These don’t sound like critical high-value goals to reach, given the price of the Technical Debt.
That is my perspective. Now, what do you have to say?
As a CTO (or in a CTO-like role), what was your most consistent pain, frustration or problem with Technical Debt in your company in the last 2 years?
Have you ever had any?
Thank you for your time reading this and giving a thoughtful response. :)
I have found it’s best to not take tech debt complaints very seriously and instead look at actual success metrics. For example if every change to a bit of code introduces new bugs then that might be a reason to tidy it up.