A few years ago, a director at my organization said at an all-hands meeting that he viewed "tech debt is a debt we never have to pay and have no interest on". In one swoop, he told the entire organization that technology concerns are not valid.
People have been complaining for years using specific issues. We could point at times that important services went down. We could point at full time operations people who have to babysit applications. We could point at failed initiatives. The bi-annual company survey always has "we're fighting the same fires" in the top issues.
I suppose the issue with talking about tech debt to non-technical people is that they don't care. It doesn't affect them. At least not directly, like it does for developers.
I think I agree wit the general sentiment though. I don’t think “tech debt” in abstract is an actionable thing.
Instead it should be pitched to the business as “we should change how we architect $service because the time spent on cards which interface with it are mostly spent wrangling rather than actually implementing the desired features. With $new_model here’s the code for what those same cards would have been and we expect that features of this nature will take 4 hours instead of 40.”
There are good things and bad things. There is nuance. I haven't and can't provide the whole picture. I just provided one anecdote that I felt is relevant to the discussion here.
In re-reading my comments, I think it's easier to interpret what I wrote in an only negative way. I think that dealing with technical debt is would be a topic that the company does poorly.
On the flip side, they build new products quickly and use new tech often. I consider the organization to be similar to other big-company feature factories. There's a degree of dysfunction in that, but also has a purpose.
It does affect them indirectly. More importantly, it affects the company.
Engineer's lose motivation and put less effort in. The company has to spend more budget on operations. Emergencies come up. Projects fail to deliver on-time.
These things are the tech debt and the interest being paid.
He had a point in some cases. There are products that aren't used or aren't under active development.
He was lumping all of the tech debt together. He was saying to everyone in the organization that he viewed all tech debt this way.
Ok, so there is impact for them? Then elaborate and be specific. I'm pretty sure that any sane manager or director will listen when you tell you them you can save on operational costs. Just be specific and explain what you can do and what it will achieve. There's literally 0 need to use obfuscating non-specific vague words such as "technical debt".
Everytime I see someone mentioning technical debt I take as a signal that there is a vague idea of opportunities for improvement, but no one has taken the effort to quantify the costs and benefit in a specific way. If you see yourself using the words "technical debt" as an engineer, it means you need to do your homework and be more specific and ask yourself what you're actually saying.
A few years ago, a director at my organization said at an all-hands meeting that he viewed "tech debt is a debt we never have to pay and have no interest on". In one swoop, he told the entire organization that technology concerns are not valid.
People have been complaining for years using specific issues. We could point at times that important services went down. We could point at full time operations people who have to babysit applications. We could point at failed initiatives. The bi-annual company survey always has "we're fighting the same fires" in the top issues.
I suppose the issue with talking about tech debt to non-technical people is that they don't care. It doesn't affect them. At least not directly, like it does for developers.