There is a human cost to this constant patching and fixing. It can burnout the people maintaining the system as well. I wonder if this can be quantified as well.
Great question. If you're working in an environment where hours are logged to projects, you could measure utilization. If not, I would make "temperature checks" and feedback loops with the team part of 1:1s and feedback sessions. A third option is to understand why it seems to be taking longer to similar work packages delivered over time. This is usually a good sign that technical debt is creeping in and some are "suffering in silence." I'm sure there are other ideas to keep a pulse on the team.
There is a human cost to this constant patching and fixing. It can burnout the people maintaining the system as well. I wonder if this can be quantified as well.
Great question. If you're working in an environment where hours are logged to projects, you could measure utilization. If not, I would make "temperature checks" and feedback loops with the team part of 1:1s and feedback sessions. A third option is to understand why it seems to be taking longer to similar work packages delivered over time. This is usually a good sign that technical debt is creeping in and some are "suffering in silence." I'm sure there are other ideas to keep a pulse on the team.
Good take on a commonly misattributed problem.
It is an interesting twist to make technical debt a financial challenge, not just a technical challenge.