How to Address Tech Debt vs. Product Debt vs. Business Debt
Once upon a time, in a cave filled with software engineers, a voice complaining in unison shouts, “Product Managers do not care about tech debt. They think nine mothers can give birth in one month.” Engineers are forced into putting band-aids on top of band-aids because feature work just keeps coming and the lowly engineers are powerless to plug holes and fix things. Thanks to their negligence, the entire product remains a leaky bucket, and as one generation of engineers passes over the dirty code to the next, the company struggles to keep up with knowledge decay, spending more resources each generation to keep a poorly done up software from breaking down completely.
Meanwhile, as the engineers complain about product managers, there’s this other cave filled with Product Managers. They draw stick figures on the wall of the gods they need to appease: the VP of Sales, Head of Business Development, and the Head of Strategic Partnerships. Above those three deities reign the supreme overlord, the CEO. The Product Managers chant in unison, “We cannot get beyond the MVP because the gods want their every whim done yesterday. When everything is a priority, nothing is!” Yet they’re not done! On another wall are stick figures of the engineers. Those lab rats complain that the interservice communication, the data ingestion pipeline, and the OAuth implementation, whatever those mean, are poorly done up that they all need fixing. Yet users can log in and use the service. What’s so bad about them? If only these lab rats understand the life of a product manager, they wouldn’t be complaining about petty stuff.
And then there’s Mount Olympus, the realm of the gods. The CEO looks down on the lowly product managers and their team of engineers. “Why are they so slow? I’m losing business opportunities here and there because they want to build everything into a palace when all we need is a shack so that I can create an income cycle to fuel the next step of product development.”¹
If you’ve been in one of those realms before, congratulations! You’re working in a tech company.
In all reality, every division in a company has its own pain points.² While it seems that one department refuses to fix the problem of the other, it is also true that most people in the company work with good intentions. Hence, if everyone is trying to do a good job and they also complain about each other, the problem therefore lies in communication (or more specifically, communication breakdown).
The more aligned the company, the less these types of complain shows up. Those who grew out of a five-person startup know this well. Back then, there were barely any communication problems. Everyone’s aligned because communication is as easy as anything.
Engineers are fond of modern coding techniques. One funny quip people run into often is that engineers write tomorrow’s legacy code today. Yet it has also been noted here and elsewhere that if your company is six weeks away from running out of cash, migrating your old Android Java code to Kotlin isn’t going to help you, regardless of how much the gods at Google tell you otherwise. As Peter Cohan repeatedly notes in his book Scaling Your Startup, the company needs to sprint towards liquidity. That is, the company needs to reach a point where it has enough free cash flow to fund future endeavors. Yet time and again I have seen Director and VP level engineers unable to wrap their heads around this.
Elsewhere, there’s an interesting research where it was found that the ENTP and ESTP personality types tend to have a higher tendency to display psychopathic behaviors. (This is not an attack by the way. This is just a statement of facts. If anything, for the world to advance to where it is today, you need those personality types)
These two personality types are very closely associated with entrepreneurs. They are very difficult to deal with because they are often extremely confident, often good debaters, and often dismissive. While these personality types are prone to impatience and gaslighting, they themselves are also not smarter than others. They are good at high-level concepts and often oversimplify at their company’s peril. If anything, they are better wordsmiths, which works well in reinforcing investor and customer confidence, but works adversely in conditions where deep analytical thinking is needed.
Of course, this too leads to communication breakdown. If you need to protect the company and also have a CEO who refuses to collaborate, you then go behind his back, which ends up frustrating him more, and the death spiral continues.³
And then there are the product managers, whose battle cry remains to be “With Great Responsibility Comes No Power.” Lest the engineers and the CEO think that product managers are dolts, most reasonably good PMs have an ideal roadmap which they couldn’t execute thanks to the various constraints in the company.
Note that correcting engineering mistakes is in magnitudes cheaper than correcting product mistakes. A software bug can take a few hours to fix. A product bug often takes months to fix. The stakes the product managers carry are often much higher than engineers.
As one might have noticed at this point, tech debts are things that slow development down. Product debts are things that slow AARRR down. How then does a company address these debts? It must address it by driving alignment and driving it often. If the business loses, everyone loses. Interestingly, all tech debt and product debt are business debts. Every problem the engineers and product managers have is also a problem of the business. So if one needs to campaign for a tech debt or product debt to be addressed, he is to frame them as business debt and prioritize them from highest to lowest. In essence, everything has to be framed as business debt.
Here’s an example. If I need to migrate my code from Java to Kotlin, I need to show the monetary impact this endeavor will bring. As with most estimates, an intelligent guess is good enough.⁴ Suppose my prediction is that migrating to Kotlin will cost $50,000 per month for six months but will save the company $100,000 per month from the seventh month onwards, then it’s easy for the decision-maker to check how this initiative fare based on other initiatives.
In general, you want to prioritize tasks based on the Impact vs. Effort matrix. Those that are high impact and low effort (hence low cost), do them first and work your way down in priority.⁵
A deeper discussion on that matter deserves a separate article that already exists in abundance elsewhere. Hence with that, I’ll end here. Happy collaborating!
If you enjoyed this article, I’d be happy to connect with you on LinkedIn. I also run a non-profit organization called Big O(n) Development.
___
¹ And then you have the den of atheists, led by the VP of Operations, whose entire team secretly curses the CEO, the Product Managers, and the Engineers for building a sloppy product.
² If any of them is not in pain, something’s not right!
³ To be clear, there are these personality types in Engineers and Product Managers as well. They are also a tremendous pain to deal with (and in general, must be fired. If you need to move fast, you need to keep these narrow-minded divas from blocking your way)
⁴ Take note: intelligent guess.
⁵ Of course, in a big company, you will always have a five-year-old senior executive who wants a yellow text on red background and you have no choice but to appease him (because him throwing tantrums *might end up being costly)
