Disruptions to the Release Process, Pt.3: Tech Debt

Photo by Christina @ wocintechchat.com on Unsplash

No matter how much unpacking and planning you do on a product release before it gets built, unforeseen technical limitations can arise in the middle of development. Whether the problem exists within your current codebase or lies in the tech you wish to implement, you have to use compromise, innovation, and flexibility in your response.

Two words: Tech Debt

You’ve thoroughly planned your product release, your production environment is working like a well-oiled machine, and you have fended off all ad-hoc feature requests from internal stakeholders. Wait…what’s this? Oh no, a developer finds a limitation within the codebase that does not allow you to easily implement a certain feature that is required for your release!

Your mind takes off at a million thoughts per minute: “I need this feature. I’ve shown it to all of our customers and they loved it!” and “Well great, what kinds of other hidden limitations will we find once we begin to unpack this!” and “Oh my god this is going to push out our release a ton and now I have to realign marketing efforts, CS, and Sales, and oh god what if my estimate on a new release date is wrong?!”

It’s hard not to spiral into panic-mode when tech debt gets in the way of a release but it is important to remember that technology is always evolving and naturally frenetic. There is no cure-all for this problem so please remember this: All you can do is analyze the situation, lay out your options, and choose the best path forward that aligns with your company strategy. You can use this method to suss out inferior options and lay out the best opportunities for your team when faced with tech limitations:

1. Define the problem: You need to determine the scope of the tech debt with the development team and understand how it affects your release. Which aspects of the release are affected? What needs to be fixed in order to resolve this problem?

2. Calculate the amount of effort to fix the problem: There are multiple ways you can go about resolving this problem and you should calculate the level of effort for each possible solution. Knowing how much development time each solution would require will help you make the best possible decision for your release and help you communicate release date changes appropriately to your company. You can get the levels of effort on common possible solutions such as:
   a. ) Resolve the tech debt and implement the feature as designed
   b. ) Hack around the problem and implement the feature as designed (this solution maintains or increases tech debt which may need to be repaid later)
   c. ) Compromise on or replace the feature with something that doesn’t require resolving the tech debt

3. Choose a path: This obviously depends on your resources and the level of urgency on the release. If your release is going to make or break a sale if it’s not live in time, you can implement hacks to get it to work and ask for forgiveness later. If you can delay the release without letting down stakeholders, you can take the time to implement the feature correctly and eliminate some tech debt. If the feature in question can be changed in order to avoid technical limitations, notify your stakeholders right away and get to work. The path you choose depends heavily on the climate of your company at that time, possible customer investment in the release, and a historical understanding of paths chosen in the past (if your company always chooses hacks, perhaps it’s a good time to repay some of that tech debt now, and vice versa).

4. Understand and communicate consequences: This is particularly important if you have to delay the release in order to accommodate for tech debt. Even if you have more flexibility in a release and can delay it without hurting stakeholders, it is important to remember that every delay in your current release delays future releases. This snowball effect is always present, whether you delay a release or have to repay tech debt later. The most important thing here is communicating your decision and possible consequences to your internal stakeholders as soon as you have the information so you can set expectations and eliminate confusion.

Every delay in your current release delays future releases

Conclusion

You cannot always plan for and avoid tech debt problems that arise in the middle of a release. Depending on resources and time, the way you handle these technical limitations will vary with each situation. All you can do is define the problem, calculate the amount of effort needed for each possible solution, choose the best possible path considering your situation and stakeholder interests, and communicate, communicate, communicate what your proposed solution means for the company moving forward. Tech debt is a tough but completely normal problem for Product Managers and development teams. You cannot escape it; So stay informed, flexible, and innovative in order to make the best decisions needed to get your release out the door.