The battle between tech and product is never ending, and the question of why technical debt should be worked on can be hard for people, who do not have an engineering background, to understand.
This post lists some ways to communicate "technical things".
Analogies
Use the following analogies of the state of things:
- a clean room needs regular cleaning, though if one day is missed it won't make a difference
- a working car needs regular maintenance, though if one day is missed it won't make a difference
Use the following analogies for habits:
- going for a run or going to the gym - missing one day is ok, but not every day.
It's the same with technical debt. Missing it for a day won't make much impact, but if it is never done, the results will build up and negatives will surface.
Business Impact
Communicate any of the below impacts:
- speed - such as every feature taking longer to build if we have outdated code
- blockers - such as tech debt of deprecated libraries meaning they aren't supported anymore and can post security risks, and that won't work with other components
- reliability - unresolved tech debt increases the risks of outages or bugs, which can impact customer negatively
- cost - the longer we delay addressing tech debt, the more it expensive it becomes to address
Present a Plan
- Break down the work in to manageable tasks
- From the above business impact points - show how investing time in tech debt will increase efficiency, reduce costs or enhance stability
- suggest a phased approach such as 20% of each sprint being tech debt
Provide Evidence
- Show metrics such as customer complaints and slow delivery times
- Demonstrate past successes of addressing tech debt
Tie all of the above to business goals like lower cost and better use experience.