In many organizations, the phrase “technical debt” has become a buzzword used to complain about anything that annoys an engineering team. Unfortunately, overuse of the phrase has given some leaders the perceived permission to ignore the impact of the very real phenomenon.
So, to avoid the extremes of “everything’s technical debt” and “nothing’s technical debt”… I’d like to set aside the phrase itself for a moment and look at a few specific areas where debt can be experienced.
1️⃣ Code. Poor structure and inadequate automated testing can make simple changes take too long.
2️⃣ Architecture. Reliable, scalable systems often must be more complex than the simplistic ones that work for a small-scale minimum viable product.
3️⃣ Usability. Features that have grown organically often lack the cohesion that supports learning a new product. A growing but cobbled-together interface makes it harder to grow the customer base.
4️⃣ Knowledge. As teams grow or churn, the understanding of “how we do things around here” starts to morph. Important but undocumented maintenance is forgotten, while other rituals persist, consuming resources even though nobody remembers why.
If you’re starting to feel like your team’s work is drowning in some kind of debt, perhaps one of these categories will be telling for you. And if you’d like a thinking partner to explore your particular situation, let’s talk. Visit stevedwire.com/talk to start the conversation.
Leave a Reply