Technical Debt: Preventing, Managing, Fixing for PMs

Author

Irene Yu
March 30, 2023

Welcome to my monthly newsletter. I'm an experienced software engineer, a tech mentor to product managers, and the founder of Skiplevel. Every month I share:

  • technical skills and knowledge you should know

  • tips for working with and collaborating with dev teams

  • tips for non-engineers struggling with confidence in technology

  • tips for managers looking to build a more technically literate team

Ask me anything (yep, anything) and I'll cover it in an upcoming newsletter issue!

Connect with me on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.

Q: My dev team and I disagree on the choice of third-party video editor to adopt for a new feature we're building. The [video platform] I prefer clearly has better features, but the dev team is adamantly against it because it requires using an iframe and will "incur future tech debt". Tech debt is something I've heard over and over again as a reason not to do something and I'm wondering how I should approach it as a non-technical founder/PM?

| Asked by CEO (Acting PM) @ Seed startup

Ask me anything & I'll answer it in an upcoming issue!

Hey CEO @ Seed startup,

I get why it’s hard to wrap your head around technical debt and how it affects product decisions and timelines. But as you correctly concluded, tech debt isn’t something to take lightly as it could really sink your product in the long term hence the pushback from your dev team. This is why as a PM and CEO, it’s an important part of your technical education to know how to think about tech debt as an important consideration for product decisions.

Technical debt in a nutshell

Technical debt (or tech debt for short) refers to an accumulation of work that builds up when software quality is sacrificed in exchange for quicker delivery of a feature or product. This means implementing the quicker short-term solution instead of the more optimal solution because it’s more complex and/or labor-intensive.

I’ll give you a quick example: It’s best practice to write a unit test for every line of business logic code. However, writing unit tests for every line of code can add weeks onto the release cycle. In order to prioritize a faster release time, developers release code without proper testing. Bugs are released alongside the feature since business logic was not tested properly. These bugs then cause other unforeseen issues.

The expectation is there will be time and resources later to go back and build things the right way. But as you can see from the above example, tech debt often accumulates to the point that it becomes difficult to keep up with and inevitably completely prevents or slows down the ability to build new features.

A good analogy for tech debt is trying to build new walls and windows into a house with a sinking foundation and a precarious structure. Even if it’s possible to add in new windows and walls, it’s probably not a good idea and will only lead to issues in the future.

Here’s a funny meme that captures this analogy pretty well:

Preventing, Managing, and Fixing Technical Debt as a Product Manager

Technical debt is one of those pesky things that just comes with the territory of building software. No matter how much you try, some degree of tech debt will sneak its way into software. Ultimately it’s up to your development team to fix most tech debt but as a product manager you can also take some control over ensuring technical debt doesn’t bog down your product and team.

Managing technical debt ultimately comes down to 3 things:

  • Preventing it

  • Managing it

  • Fixing it

As a product manager you have a role in all three and here’s how:

Got a question? Ask me anything & I'll cover it in an upcoming issue!

💡 Tech Term You Should Know (TTYSK)

"DNS (Domain Name System)"

The internet is made up of many interconnected computers and servers, and each of these devices has a unique numerical address called an IP address. For example, Google's main server's IP address is 172.217.6.174.

However, remembering and typing in these numerical IP addresses can be difficult and impractical for people. That's where domain names come in. Domain names are human-readable addresses that are easier to remember and use than IP addresses. For example, instead of typing 172.217.6.174 to visit Google's website, we can simply type google.com.

The domain name system (DNS) is the system that translates domain names into IP addresses. When you enter a domain name into your web browser, your computer sends a request to a DNS server, which looks up the IP address associated with that domain name. The DNS server then sends the IP address back to your computer, which uses it to connect to the appropriate server and load the website.

Hot Twitter Takes 👀

Process is half the battle if you want better collaboration with cross-functional teams. Are there retros? What's the sprint board process for PMs and engineers? How early do you include engineering in the product process?

If you didn't read my last newsletter on using ChatGPT for product managers to improve technical chops, you should.. then reimburse your PMs.

Anyone else? 🫠

Want to feel more confident in your technical skills?

Become more technical in just 5 weeks, without learning to code. We also train teams. Find out more at skiplevel.co/teams and book a call with me to get started.

As always, connect with me on LinkedIn and Twitter and follow Skiplevel on LinkedIn, Twitter, and Instagram.