 Hello. All right. Let's get started. This is TechDepth for Product Managers. My name is Jason. I've been a technical product manager for almost 10 years at companies like Facebook, Square, and Flatiron Health, along with a short term with the federal government as part of the U.S. Digital Service. Having started my career initially as a software engineer, I've gravitated towards more technical work, like building foundational platform products or scaling product infrastructure. And so in working in these areas, building platforms, scaling infrastructure, I've been pretty close to many conversations around TechDepth tradeoffs, when to take it on, when to defer it. So that's the topic I'd love to talk to you all today about managing technical debt. I'm sure most of you who've been involved in software have already dealt with technical debt, but let's define it. It's a financial metaphor coined by Ward Cunningham, the author of the Agile Manifesto, to describe the code quality cost of shipping software quickly and those growing costs over time when it's not repaid. You can see here with the quote. Shipping first time code is like going into debt. A little bit of debt speeds development so long as it's paid back properly with refactoring. A danger occurs when debt is not repaid. Entire engineering organizations can be brought to a standstill. So actually in software, some technical debt is good. At Facebook, they used to say done is better than perfect. However, when you start to accrue too much debt, then your organization may eventually find it harder and harder just to stay afloat. And so obviously it's a balance. If your engineer is over engineer everything and optimize everything too soon ahead of time. It'll take too long to ship. You won't get to market in time and what you need to have built may have already changed by the time you ship it. If your engineers take too many shortcuts it becomes too hard to ship something solid and reliable to the customers. You can see this XKCD comic. There's no such thing as perfect code. You as a product manager want to make sure you know how to manage technical debt. Own it like you own any other feature of your product. But you might say, I'm not an engineer. Well, it doesn't matter. There are three tech debt management principles you should understand as a responsible product manager. First, foster safe spaces to discuss technical debt. To make tech debt visible to the business. And three, create tech debt feedback loops to adapt. Foster safe places to discuss technical debt. This might be the most important one. Basically it comes down to, can your team have candid trade off conversations about your technical debt. You need to establish trust with your whole team that you could talk about code quality, if there's something that needs to be addressed. If you don't have that trust and willingness to talk about that, you need to fix that. Establish there's no shame in tech debt. You want to keep reminding them that there's good and bad tech debt. So there shouldn't be any pressure to hide it. Again, not all tech debt is bad. If you have no tech debt, you're likely not actually building fast enough. In fact, tech debt can be framed as an opportunity to tackle interesting technical challenges to help a product become more reliable for customers and users in the end. Let your team know that they should feel free to raise any technical debt. They feel that might need to be addressed. Here you can see one example where Amazon found that improving the performance actually increased sales. And Google found that improving the page generation time affected traffic. And so there's real user benefits and impacts in the end to tech debt. So how do you do this? Well, when you're talking about your work, when it comes up, you want to make sure tech debt's part of every question, every conversation. Ask the right questions to help prioritize and make the right trade offs with your team. So first, ask questions about impact. What happens if we take this shortcut? What if we don't fix why immediately? Understand how doing these things impacts the end users, and in which cases, or in some cases, you know, how does it impact your developers? How much time will it take? How frustrating? Try to understand the severity. How likely will this happen? How long will it happen? Try to translate it to potential business loss, or maybe engineering days spent on working around it until it's repaired. Also try to figure out the timing of this. When will we see that impact? What happens if we defer the repair? Some issues develop faster than others, and others are much longer term risk. We'll see if the impact gets bigger every day, it's not repaired, or if it's basically the same effort and same impact as long as you repair it before it eventually materializes. And lastly, obviously, what's the effort and risk to fix this? Particularly with very complex legacy systems, what other dependencies are there that you might need to change with this investment? Usually there's a cascading set of dependencies, particularly if it's a very legacy, Harry Monolith might be quite risky. You might have to coordinate across teams. The areas that help you prioritize are going to be questions like, is this area of code going to be touched a lot? Might justify fixing and boning it up and making it higher quality sooner? Or is it going to be decommissioned or refactored soon? Is it basically in maintenance mode? These are things that maybe you could hold off and wait a little bit longer. Hopefully just make sure you're asking the right questions, make sure you're willing to talk about tech debt and every conversation. And you want to make sure you fully understand the issues and implications of not resolving it now or in the near future so you could collectively make a smart decision about that prioritization. In some cases, the decision might not be straightforward and involves risk management practices, but you need to understand as well as possible the risk you're taking with each decision and decide accordingly. Lastly, part of this in the end is you've got to trust your engineers. I mean, they're answering the questions as best they can. They're not trying to trick you. In my experience, most engineers actually don't want to work on too much tech debt in an excessive amount. Most of the time they're actually raising it for really good reasons, not necessarily just personal grief. But sometimes, and you can ask about this, it could be organizational or things that not only slow and affect them, but multiple people, multiple teams. Again, try to ask about the end user impact. And once you arrive at a decision, make sure you actually allocate that time and space to invest in these areas you determine are worth it against other product trade-offs. And if you've articulated your product vision well with your team, you've done a good job making sure your engineers understand the business domain that they're working in. Then collectively, you're going to make the best decisions together. Good pragmatic engineers understand there's always a trade-off between speed and quality with every decision here with taking on tech debt sooner or later. Not only will it make your product better in the end, but you also build this strength and trust between you and your important partners. And if nothing else, it'll make it easier for you to say no at other times when you're not quite convinced that the issue is worth immediately resolving that. In the end, you want to work for a really strong engineering organization if you're shipping any kind of software product. So two, make tech debt visible to the business. So now if you're having good conversations with the team, you want to make sure this tech debt that you're working on is visible to the rest of the business. Organizationally, it's going to be harder to work on invisible work that no one understands and sees. So doing this will help you manage your stakeholders, your partners, upwards, downwards, across the organization. In many cases, you're going to need to work with multiple teams. So this comes down to, can you show how bad or not bad your tech debt is, at least at a high level? And so just like with other products, try to find some good KPIs. Ideally, tie them to product outcomes. Here's some examples, some are better than others. Like what are the user bounce rates depending on your problem? How does this affect your net promoter score, your customer satisfaction score? What are the medium page load times or app crash rates? Maybe you could correlate those with your promoter scores or customer satisfaction scores. If you go down to more than nitty gritty, what's your release failure rate? Is every other release you're pushing out failing? How many bugs are escaping? Or overall, what's your availability and uptime? There's a lot of different KPIs that you can measure. I believe closer to the end user, the better to illustrate the outcomes until a good story. If your product has specific customer service level agreements, SLAs, those are great. Even better. Sometimes if you're going upstream against a culture that doesn't particularly value the importance of managing technical debt, as a product manager, you could prioritize these feature related work dependent on the elimination of some technical debt. It's like just one tactic. So some examples. Here's a dashboard we've used for engineering metrics on our build and test pipeline. Our process. This is great for a team's execution, showing the types of errors, whether there's things that spike and cause particular problems that slow and frustrate your process. And it's good for your team's execution, but it could be more compelling to tell a narrative across the business if you talk about the end users. So another example. Here's a chart of the number of high severity incidents broken out by reports from customers. And so you can see the percentage of incidents escalated by customers first. And then over time, if you invest in this, you can see the number of incidents decrease. So that's a great story to tell. And the better you can try to correlate these improvements with customer satisfaction scores or other measures of how well your customers enjoy your product. And so here's an example trend in user performance comments versus customer satisfaction scores and you can see that more people are rating the application, the top scores of four or five. The number of performance comments are decreasing. And so that implies some correlation with the performance of your application with how satisfied these customers are for your product in the end. And so that again is a really compelling narrative of why you're spending so many engineering weeks on technical debt that's not just try to make your developers lives easier. But again, it's also making your end users, your customers more satisfied, happier, it's going to be a better product in the end too. And if you could raise that makes it easier. And just like every other product as a product manager, much of your job is just marketing the projects that you're working on. Be an advocate for these impactful tech debt projects. It's oftentimes not as easy for higher level stakeholders to understand tech debt projects, as it is to direct customer impacting features. So we need to be especially vigilant and making sure people understand the impact of these projects so one proposed projects with clear impact to these end users to define what would happen without this investment. Let's go on off a cliff, or is this boiling a frog. Three discuss what these projects enable sometimes sometimes it's not necessarily addressing a problem but enabling future features making it easier. Even with things like test coverage. Sometimes you want to add test coverage it's better to front load it ahead of time and that could speed up the development. It's easier for your engineers to validate that a new feature that they're developing works properly, it shortens that feedback cycle for them, you can accelerate your product velocity. There's a lot of things that you want to make sure people really understand why you're doing what you're doing. So I'll make it easier for you to work on on that debt. Three. Now that you have buy in and then how do you actually execute on the right amount of tech debt. You want to create regular feedback loops to adapt as your product matures. So this comes down to do you have a regular process to identify the needs to address more or less technical debt over time. And then, early on, you may actually want to defer a lot of optimizations to get the product out the door. Since, in the beginning you may not even know you're building the right things that's not worth investing so much you might have to throw it all out, eventually. But as the product matures, you might want to adjust tech debt for it gets too large, depending on how much the tech debt has grown, you may need to eventually take larger measures so take a look at this craft. Your tech debt might be small and if you stay on top of it, you might have to just do a little bit of minor refactoring here and there every time you touch it. But as you build on it over time it might become harder to address you might need to do larger migrations or transformations to the code that takes more time. And if you wait really, really long, especially with big hairbally kluji legacy monoliths of code things that are just big balls of hard to understand chunks, not well isolated patterns and code boundaries. You might need to eventually just replace the whole thing entirely it's going to be easier than trying to decipher and unantangle the mess that you've created for yourself, this ball of spaghetti code that will be too hard to pull apart, and then you might just have to rebuild and refactor and there's many stories of companies that have eventually just died because they spent so much time rebuilding everything from scratch, and so you don't want to be in that place. Basically you want to stay ahead and address tech debt at the right time, but no sooner just the right amount of tech debt at any given moment. So how you want to track this tech debt with your other work. You want to track that epic or so just like any other feature, manage it regularly and your sprint grooming and planning with other work. Align with your team on the allocation for space for tech debt, make sure they understand that there's amount of bandwidth that should be allocated to keeping on top of things. Adding test coverage, doing things that will make your code quality better and make your delivery more reliable. And three plant reasonable workloads for sprints and includes slack. This is something that I believe in because slack is good for when features inevitably take longer than expected. We all know that software estimation is impossible. Most of the time, people don't estimate perfectly. And so slack is good when these features and only take longer than expected, but it's also good when sometimes features are finished faster. And then your team can use that slack time for a little bit more refactoring, cleaning up test coverage, other things like that, make it a culture and make it a habit for your team. So hopefully you're having these conversations when you're discussing and playing this work, try to identify bad code smells and track these hidden costs that you eventually need to tackle. So here's some examples of smells to identify when there might need to be a little bit more time to address some of your tech debt and some tactics to address it. So the first one, this is just an experiment for now, no need to make it bulletproof, no need to optimize it too much. And sometimes that's the right decision. But you want to roughly understand what's the cost to production is it eventually tactically, you can try to add a jury ticket into some future sprint ahead of time, knowing that you're going to have to get to it eventually. And sometimes teams fall in the habit of indefinitely deferring tech debt and they just eventually forget about this invisible work. Engineers might add to do comments in their code that eventually get lost and forgotten track that added your ticket placeholder ahead of time. So this is better for your experiments your AB tests your feature flags, you can have a productionizing playbook. When things get productionized and features get rolled out to 100% have a process of what you need to do to clean that up. Second one here. This is just one client, we can hard code this for now, maybe this is something even you've told your engineers yourself. So if you want to think about opportunistic refactoring, consider the boy scout rule. If an engineer is touching the same area a lot, leave the code in a better place than they found it. Or another variation, basically you can have a rule that if you touch a high risk legacy area X number of times, maybe two or three times. And so you won't defer it indefinitely. The areas that you're touching most often, and the areas that are most valuable for you to bone up and make solid. Those are the ones you're going to spend time on. Naturally it also means maybe there's a high risk legacy area it's never touched. Well, you don't actually necessarily need to spend that much time refactoring it. Third, you've probably heard this only someone is able to work on that code. And that's a pretty bad smell. You could end up in a bad place you have very low bus factor if that person gets hit by a bus, then you're in a pretty bad place. So hopefully you already have processes like code reviews where people are reviewing each other's code, not only helps with code quality but helps people get familiar with different areas of the code. And so that'll help with your bus factor help more people feel comfortable working on the area code. If you have more drastic measures, you can do pair programming or mob programming. This is when multiple engineers work on the same story and program it together. This will also improve your bus factor familiarity, make your code quality better. So when that one poor burned out engineer eventually leaves, you're not completely handicapped, and usually going to be in a better place your team will thank you, and you'll thank you. So, lastly, regularly reflect on the amount of tech debt allocation, you have these loops, make sure you have times to reassess. So the shortest time span have regular sprint retros. While I'm not a big believer in tracking exact sprint velocity points and seeing if it's going up or down any given sprint. I do think it's really healthy to ask open ended questions about productivity and retros. Are there investments to make our team more productive. Are there areas of the code that are constantly biting us. Are there really particularly frustrating areas that the team have felt in working on their features on a regular basis. And if so, what are things that the team can do sometimes they can be small little things like adding coverage, adding documentation, things like that, that can make your team overall more productive and happier. A two, when you do eventually have an incident, and every good product does have post mortems have the time and space to reflect, not only on how to fix the root cause, but how to risk, how to reduce the risk of future bugs. Particularly, if there's patterns and incidents that might motivate larger investments that you may have deferred before. That's really good to dig into. Try to look up other post mortem techniques their techniques like the five wise where you ask why multiple times in a row to really get into the root cause the crux of the thing, the issue. They'll help you really identify what you need to do to prevent this in the future, not just the immediate issue, but other types of similar issues. Lastly, consider lockdown thresholds. For instance, if you have a certain number of incidents in a quarter that might indicate it's time for your team to work more on tech debt, then other more direct user facing features. In the end, incidents take a lot of time for your engineers, they're stressful, they're high urgency they cause a lot of context switching they make your engineers not very efficient. And so if you have a certain number of incidents, it's time to take a step back and say, hey, like we got to work on this, we got to make things more reliable and they'll make us faster in the future. Or if you have other SLA targets like performance thresholds availability uptime that can be a time for your team to work more on tech debt and indicate, let's pause and other things that we can and work on these issues for reliability address tech debt. Lastly, these are good times to review those fancy dashboards and KPIs that you hopefully made at this point. And that's it. So summary, there are three tech debt management principles. One, foster safe spaces to discuss tech debt. To make tech debt visible to the business. And three, create tech debt feedback loops to adapt. Basically, manage your tech debt as rigorously as you manage any other part of the product. Don't be the pointed haired boss in this Dilbert comic. When you have these good conversations with your team, everybody understands why you're working on the tech debt that working on and making the trade offs with the product that you should team will thank you. You'll thank you. They'll build that trust with them, and your product will be better off for it in the end. Thank you.