Everyone says they want to fix tech debt, but, in my experience, almost no one really tries.
Every developer at some point, probably
If product owners and stakeholders can’t see the gain (or avoidance of loss) in fixing technical debt, we’ll be stuck with whatever random percentage of effort they set aside for it. Incidents are very visible and clearly painful, so they are a great opportunity for communicating why we should address technical debt.
As engineers, we often sell fixing technical debt as if we’re convincing other engineers. It’s a regular occurrence for teams to have an overly complicated, slow, unreliable deployment process. And that’s how we describe it. To stakeholders, that may sound like a problem. But realistically, there are an infinite number of problems we could fix.
We’d have better success if we communicated the cost of tech debt in stakeholder focused language:
“Incident #183, which affected 175 customers, was caused by X. We did not immediately detect the issue because deploying took over an hour, and the owning devs were in a meeting by the time the deployment completed. If we set aside a week of dev time to improve our pipeline, we expect deploys to take less than ten minutes. We will detect production issues faster, allowing us to minimize customer impact in the future.”
If we want buy-in for fixing technical debt, we should communicate value that stakeholders care about. Next time there’s an incident, consider how addressing technical debt would have avoided the problem. Use that perspective to communicate with stakeholders. By sharing their perspective, we’re much more likely go get the desired buy-in.