How do you Deal With Tech Debt as a PM?
It’s so easy to focus on shipping exciting new features that sometimes we forget the importance of completing tech debt stories, and creating minimal technical (tech) debt along the way.
This is true for engineers, designers, product managers and builders of all stripes. In fact, in my experience, it is hardest for CEOs. It is so easy for CEOs to connect the dots between a feature and more growth, a stronger valuation, and greater success for the company.
For the PM specifically, one of the most challenging parts of the job is prioritizing tech debt. Then, protecting it after is nearly as difficult. As one of our primary stakeholders is the CEO, we are constantly trying to build to their vision.
This creates a perceived tradeoff between career growth, impact, and tech debt in the short term.
So, how do you deal with tech debt as a PM? In today’s post, I’m very excited to collaborate with Brennan Decker, who writes regular amazing content on LinkedIn, is writing the book From People Manger to Product Manager, and has a great youtube channel.
What the Tech Debt is
Its Impact
Role as a PM
Strategies to Address
As a PM at JD Sports, Brennan has great in the trenches anecdotes and advice on these areas. I started my career as a software engineer. So, let’s get into it.
What the Tech Debt is
As a Product Manager, hearing the words technical debt from an engineering lead can be scary.
Regardless of how technical you are, we all know that debt is bad right?
Well just like debt in the real world, it’s not that easy and sometimes it’s necessary.
Think about buying a house. Would you rather save up the full purchase price of a home or just the down payment?
On one hand you don’t incur any debt but the trade off is waiting longer to save for the full purchase price. On the other hand you can move into your new home quickly if you’re only putting a fraction of the purchase price down on the home, but the tradeoff is that each month you have to allocate a certain amount of your salary towards paying on your mortgage debt.
Now let’s take this same concept and apply it to shipping software products.
As a Product Manager are you willing to incur technical debt to ship faster? Going back to the analogy, what if you find the perfect house in a great school district. Would you allow someone else (a competitor) to come in and swoop it up while you’re stuck saving your money? But on the other hand, at what point do your debt payments take such a significant amount of your salary that you can no longer afford to do the things that you love (ship new features)?
Hopefully you see the complexity now and understand that it’s all about balance. We as Product Managers have to weigh speed to market against the technical debt load that we may take on.
Now that you understand what tech debt is, let’s dive into the three main types of tech debt.
How it was created
There are three main types of tech debt. It’s worth understanding what drives each.
Deliberate tech debt
Many times, when building, we have a goal. Perhaps it’s a quarterly OKR, or it’s a date a game ships, or it’s a short release window. These goals cause us to sacrifice the long term for the short term. So, we have a discussion as a development team, “shall we go for the quick way over the right way?” And sometimes, we choose the quick way.
So tech debt is not inherently a bad thing. This is “good” tech debt that we incurred to push out an MVP. But it’s “bad” in that there is a future cost.
For those out to eliminate tech debt, the good thing about this type of tech debt is that it’s a known commodity. The team knows where it exists, what problems it might cause in the future, and when the team must absolutely fix it. This usually aids in prioritization and discovery decisions.
Unfortunately, as development teams it is exceedingly hard to document all of this. Especially when team members move on, sometimes deliberate tech debt becomes accidental.
As a result, it becomes useful to have an understanding of some of the common types of deliberate tech debt to be able to identify it:
Not deleting dead code after an experiment result or unshipping product decision
Not having the tests, monitoring, and alerting in place; as a result, bugs are found in production
Deployment and build times take several hours or days
Developers lack the proper tools to allow them to detect technical issues before they go in production
The team prioritizes one platform over the other, so one has faulty code spots that cause bugs and crashes for corner users on the lesser platform
A third party tool or tech stack choice no longer scales for the organization’s complexity, metrics, and number of users
These types of issues come up regularly throughout the course of moving fast to build software. A good dev and product team makes these decisions strategically, but also comes back to address them smartly.
Accidental tech debt
The nature of accidental tech debt is that it often arises over the course of the time. Anytime you build a teal, it immediately becomes outdated. The app, and the underlying technology evolve.
Moreover, sometimes, requirements change or the competitive environment inverts. These cause the existence of either code, systems, or entire features that are no longer needed - or actively hurting the existing product.
https://twitter.com/mehulkar/status/1471330907999121408
Accidental tech debt has the insidious problem of typically being more hidden than deliberate tech debt. It might be that iOS has updated all its functions and the mobile engineers need to refactor some of the code. It may be that the website has something built on a web standard no longer supported. These things sometimes only hit the product team’s radar after a user has experienced issues.
Rot tech debt
The final type of tech debt is that which arises from the constant feature treadmill. We rush to add capabilities and features to a system such that it grows to become ugly, complex, slow, and hard to update. This often happens when the original team only understood part of the future requirements, so they built a solution that solved a very specific use case. Then in future instances, maybe years later, teams bolted on other features.
The team feels like they are biking as fast as they can but eventually the systems get to a place where they biking in stationary.
All the compounding bolting on off features causes the overall gears of the system to start to turn more slowly. Eventually the circular wheels that were the initial system become squares, hard to budge without the most exceeding amount of effort.
Its Impact
Tech debt comes in all shapes and sizes. There is the small, innocuous manual config each time you build. It adds a few minutes, but causes issues if you do not. There is a system check that doesn’t happen automatically so you need to do by hand.
The nastier, sinewy type is that the larger inefficient systems and processes that slow future development or make scaling difficult, if not impossible.
Slowing future development
Take the manual config and multiply by 10. Tech debt that slows future development adds hours to future changes. This might be because of choice of technology, system architecture, or decisions by prior engineering efforts.
This type of work can sometimes become accepted organizational processes. As a result, it further ensnarls itself in the culture by fooling developers it has to be that way.
Let’s say tech debt makes you 10% slower at implementing features. If a team of 8 engineers deploys one feature every other two week sprint, the expense of 10% tech debt is 13 features over the year. If it only takes a few sprints to complete, the ROI for solving this type of tech is fairly high.
Making scaling difficult or impossible
Another class of strategic tech debt is that which makes scaling difficult or impossible. Sometimes, this tech debt is known, but more often than not, it needs to be encountered.
When we were running season events at Fortnite and breaking records season after season, we ran into a concurrent user limit every season. That was because we were doing something so cutting edge that the tech had literally not been built for. At certain levels of scale, scaling can be difficult unless you address tech debt.
Role as a PM
To oversimplify it, tech debt is loved by stakeholders (ship fast), hated by engineers (ship good), and on your shoulders as a Product Manager to figure out who to make happy.
So how can you possibly win in this situation? It’s easy. Do. Your. Job.
You know that classic venn diagram that illustrates the role of the PM being at the intersection of UX, Business, and Technology?
Well this is where you earn your check at the crossroads of Business and Technology.
As a Product Manager you have to translate the Business needs (and speed) to your engineering team (they don’t usually like Business timelines) and the current state of your tech stack to your Business stakeholders (they don’t usually like technical constraints.). The more excited and aligned that you can get both groups around a shared vision the easier that your job becomes.
All of that being said, two of the most important roles for a PM to address tech debt are: 1) to prioritize it enough, and 2) to understand when to and when not to.
Prioritize Enough
As the ultimately accountable order for what engineers build, it is up to the PM to prioritize technical debt enough. But there is a goldilocks amount here. A PM that over-emphasizes tech debt becomes loved by engineers, but not quite as much by product leadership and executive stakeholders accountable for growing the business.
So how can a PM prioritize just enough, but not too much? One of the first things to do is to properly assess each tech debt element. Is it acute or systemic? Another thing to do is understand its strategic impact. Can leaving it in place enable other, more important features. And what about the impact on eng’s morale?
Also understand the team’s confidence in these claims, as well as the time it will take to fix the issue. After that, try to make an informed prioritization decision.
One can probably not expect to ever get it quite right. Nevertheless, at every planning cycle, PMs should ask the question after evaluating an early draft outcome: “are we prioritizing tech debt enough?”
Then, at the end of each cycle, foster a discussion with the dev team. Ask, “did we address the right tech debt this quarter? Was our focus too much or too little? And what are the top priorities for next quarter?” These questions help teams adjust to the individual level that makes sense for them given their capabilities and business context.
Understand When to and When Not to
These prioritization questions get to the heart of the skill which is to be able to understand when, and when not to, address tech debt. There are a couple key factors to consider:
Developers’ perspectives
Business impact
Tradeoffs on other initiatives
Part of the reason the PM role exists is to negotiate these details at the lowest level of detail. You should roll up your sleeves and write out the thinking. What do devs think? What is the business impact? What is the tradeoff? These things in paper help everyone on the team make a better decision.
The PM should also develop their own perspective. The goal should be to, as always, drive business outcomes by solving user problems, creating growth levers, and keeping the team happy. If the team is unhappy, that might mean prioritizing tech debt more than normal. If the business outcomes are critical, then it might have to wait.
Strategies to Address
Now that we understand what tech debt is and what PMs are expected to do about it, how can PMs go about doing a better job of that? It starts with tracking and developers, and goes all the way to preventing pile up.
At each step of the PM’s role in the software development process, a PM who is great with tech debt can stand out.
Track It In the Same Place
If tech debt tasks do not end up in the backlog, they will never get executed. Track tech debt issues in the same backlog you use, and hold them accountable to the same standards. In many orgs, that means having a spec with the key points in place.
This also has the benefit of constantly reminding the team of the key tech debt issues that exist. Otherwise they can easily feed into the backlog. Even if the items continually get deprioritized, at least a discussion about them is happening.
The last thing you want is to have a separate backlog of uninspiring tech debt items and an exciting set of features. That makes the tradeoff decisions too unrealistic. In the same place, they are more easily weighed.
Empower Developers
Empower developers to find, suggest, prioritize, and address tech debt. At each step, they will feel happy to be included, and feel better about the decisions being made of which tech debt to prioritize.
When finding tech debt, give developers time. Actually make it a task occasionally. Build processes around understanding which developers are the most effective at finding tech debt so they can be rewarded and recognized.
In addition to empowering developers to find tech debt, provide tools to empower developers to add tech debt items to the backlog themselves. That way they feel as little friction as possible in suggesting ideas. Then apply the same rigor as you normally would in evaluating the estimated work, impact, and risk to prioritize the items appropriately.
Then, in the prioritization conversations, regularly ask developers to provide the impact and work estimates. Then ask questions to help them be rigorous with it. Encourage their other developer team members to push the thinking. If their is a tech lead, lean on them.
Finally, when solutioning, avoid being the answer-teller. Set the stage for developers to think through innovative solutions that are not only at the bleeding edge of what is available, but scalable to avoid significant rework in the future.
Regular Conversations
The fashionable thing to say is to make technical debt a part of every conversation you have with your eng team.
The problem with this is, it’s more a tweet than a practicality. The best PMs help eng teams focus on the right thing in each meeting. Don’t bring up everything in every meeting.
Instead, set up a regular forum and cadence where people come prepared to review and discuss tech debt items. This helps make tech debt a first class citizen in the ideation and discovery process, similar to features for users. Ask curious questions. Follow threads down to fine details to understand what is actually causing the problem.
When you are taking on tech debt, understand what the implications are. Ask what the shortcut saves the team now. Follow up with the estimated impact to resolve the issue later. This information empowers you to make better decisions.
Be an Advocate
In the conversations, be the PM who cares. Dive into the details to understand them. Then follow up on the conversations by implementing the other strategies to have actions back up your words. This helps developers consider you as an “advocate” for great tech systems and minimal tech debt. Over time, developers will want to work on your team.
In addition, double click on the discovery piece. Like you interview users for their problems, interview developers. Instead of going to what developers think they should build, start with the problem. This will help them clarify their own thinking as well.
Finally, in conversations with executives and product leadership, be the advocate for tech debt work. In all the places your dev team is not, deliver on the mission of having less tech debt. Sometimes this might mean spinning up entire company wide initiatives with executives. Other times, it might mean helping carve out protected portions of developer time for this type of work.
Measure & Goal The Team On It
One of the best ways to optimize something is to measure it. By putting a KPI on tech debt, you help the team measure and improve their processes to addressing tech debt. This can not only be a unique way for the PM to add value, it also is motivating team members. Everyone likes to crush a number.
To ensure that commitment to the metric, make it a goal of the team’s. Put it in official OKRs if it makes sense. This type of specific goaling helps everyone get united around the cause, and prevents derailing of projects halfway through.
Prioritize It
With a specific KPI goal in mind, prioritizing the work becomes slightly easier. But even if the work is not a committed KPI communicated to executives, make sure to be the PM who prioritizes the work.
Many PMs include a certain portion of time or sprints to focus on tech debt. This might be the right solution for your team. Consider whether they are comfortable with flexing into and out of tech debt work, or if they prefer a constant stream.
Keep it prioritized
One of the hardest challenges is not chasing after the next shiny object. Executives, sales, and other stakeholders constantly come with opinions on what the team build. Well, what should the team cut to fit the new feature? Tech debt is one of the first things to come up.
This is why it is so important, then, for the PM to use the weaponry from their regular conversations. PMs should speak to the specific details of the problems, and why the estimated impact is the way it is.
Prevent it from piling up
Finally, stop creating tech debt! Prevent it from piling up in the first place by helping the dev team to plan reasonable workloads for sprints. Every dev will need to create tech debt if they are asked to do a month’s worth of work in two weeks. But if asks are reasonable, less tech debt piles up in the first place.
But, if it looks like things might be piling up, act quickly. Consider having full sprints dedicated to flush it out if necessary. At Google, it was not uncommon to see teams spend an entire month of the year on scalability and tech debt.
Customizing Your Style
None of these strategies or tactics should be applied without consideration for your context. Tech debt is a big and varied topic, and the role of PMs in shaping varies company to company.
At some companies, tech leads and architects live to identify and prioritize the work. At others, it is more of the PM’s role. In that case, the process described above can be particularly useful.
Regardless of the type of company and role of PM on paper, each PM and dev team will have a different situation in every company. To be a truly great PM, the key is to identify stakeholder motivations and work with them.
Why are we generating tech debt?
Do engineers feel like we are addressing tech debt enough?
Are we prioritizing tech debt enough?
Asking first principles questions like this will help you develop a strategy for your team. Maybe your team feels like they are doing enough with tech debt, but they need to be pushed to think bigger. In other cases, maybe they are over-prioritizing infrastructure initiatives.
Determine where the team is and where the team needs to go. Some of these strategies can help along the way.
Towards Tech Wealth
The inverse of tech debt is tech wealth. This is the idea of prioritizing tech debt strategically, as well as building systems and capabilities in advance, to enable tech capabilities as a strategic advantage in the marketplace. As a PM, especially a platform PM, you might consider helping your team push towards tech wealth.
For instance, the team might decide that building an experimentation platform is a good decision for scale that it will experience over the next couple of years. A simple tool like Optimizely might work for some parts of the funnel for a small part of users in the short term. But the team decides to build an in-house platform to enable a culture of rapid experimentation. That is a tech wealth mindset.
To enable a tech wealth mindset, start by getting specific about the tech debt you are talking about. Then use the tools in this article - from track it in the same space, empower developers, and the rest - to transform your team into one that uses tech debt conversations to grow the business.
To learn more about tech wealth, subscribe to the newsletter and follow Brennan. We’re just cracking into the first layer. ‘Till next time.