Kam Lasater, wrote a great piece on technical debt. Primarily explaining how stupid you sound when most people try to explain technical debt to businesses-minded people.
When we use the term technical debt with non-technical business colleagues, they assume, that technical debt is analogous to financial debt. After a few minutes of discussion they are usually relieved to find that there is no actual money problem. Then after not seeing any tangible sign of a fire in the movie theater, they will then conclude that that we either don’t know what we are talking about or we are using the wrong terms or both. Think about their context, how quickly would the CFO get fired if they claimed “we have a lot of debt” but couldn’t produce a balance sheet with lenders, amounts, interest rates and terms?
The article goes into a lot more detail on what the problem is, and also the ways you can explain it better. But essentially, the trick is to explain it in ways that people can understand:
Companies and business leaders don’t care if jobs are hard or annoying or take longer than they “should”. The difference between a user story taking a day or 3 days is negligible compared to its business value. Companies and their leaders care about revenue and costs. They care about customers and growth. They care about time to market. If we want to have our non-technical colleagues listen and act, we need to either improve our use of the financial terms they understand or we need to translate our message into business outcomes that they do care about.
I’ve seen this myself where I work. Every so often it’s regarding technical debt, but typically, I think it’s when people aren’t aware of the context in which they’re explaining something. It’s something I definitely had to get to grips with as well, learning how to talk to various people, what they understand, what they’re interested in, and overall, what matters to them.
This may sound rude, but I think sometimes us developers get a bit stuck in our own world. We tend to use a bit too much jargon, arguing over the stupidest of problems, and not really focussing on the wider business perspective. For example, the value of the product doesn’t get better if you use a different code style.
One thing that helped me at work was to spend time with people like product managers, business leaders, or anyone else non-technical that I had to explain things to. That way I learned their perspective, and adapted my wording to fit. It’s only going to be better for both parties if you can get things across clearly. It avoids unnecessary confusion and it saves time.