Thanks for a useful and insightful write-up, as always. I could not agree more on the pair programming point.
In terms of communicating tech debt, one of the key strategies I've found really helpful is reframing what tech debt actually is and using different language around it. Borrowing heavily from @kentbeck, I've found that framing 'tech debt' work as a decision to invest in the *optionality* of the software.
Often I've had pushback from stakeholders who see paying down tech debt as just something engineers want to do to make their life easier, at the expense of delivering features etc. to the business. By changing the narrative to 'this is creating greater future value for the company', often lands better and makes more intuitive sense to business stakeholders. It's a shameless plug, but I have written more about it here:
Absolutely! I love the framing around optionality. Talking about what gets *enabled* is especially important when you have a hard time measuring the actual cost of tech debt. The answer is: focus on the future.
Thanks for a useful and insightful write-up, as always. I could not agree more on the pair programming point.
In terms of communicating tech debt, one of the key strategies I've found really helpful is reframing what tech debt actually is and using different language around it. Borrowing heavily from @kentbeck, I've found that framing 'tech debt' work as a decision to invest in the *optionality* of the software.
Often I've had pushback from stakeholders who see paying down tech debt as just something engineers want to do to make their life easier, at the expense of delivering features etc. to the business. By changing the narrative to 'this is creating greater future value for the company', often lands better and makes more intuitive sense to business stakeholders. It's a shameless plug, but I have written more about it here:
https://evenlydistributed.substack.com/p/optionality-as-a-common-language
Absolutely! I love the framing around optionality. Talking about what gets *enabled* is especially important when you have a hard time measuring the actual cost of tech debt. The answer is: focus on the future.