Prioritizing Technical Debt
24 September, 2021
null at PolicyGenius Inc.
All organizations find it challenging to deal with technical debt. Any engineer can point out dozens or hundreds of problems they’d like to fix, but we can’t fix them all. Prioritizing technical debt work is a fundamental challenge for team 一 if our time is finite, and we assume we can’t fix it all, how do we start? This question leads to decision paralysis and unsolved debt.
I see many engineers, managers, and product managers try to build a prioritized list of tickets, listing all of all the tech debt problems they felt the team needs to complete. This led to either a huge, languishing backlog of items that would never be completed or a shorter list of items that captured the concerns of a single moment in time.
Any attempt to create an exact order for accomplishing those tasks felt arbitrary. There was no single way to put a specific item at the front compared to other items on the list, so prioritization felt a little awkward. Priorities change frequently. The problems today are not going to be the same problems 4 weeks from now.
Depending on the projects that different teams might be working on, there are a number of ways to deal with technical debt.
My goal was to develop a process for building a list of tech debt items that accounted for some of those unique challenges of technical debt – global prioritization is rarely possible, the tech debt of today is frequently not the tech of tomorrow, and an indefinitely growing catalog of tech debt items is never useful.
Inspiration struck, and I mulled over an idea of building a debt backlog based on the format of the game show, “Jeopardy!”. Five well-categorized columns, five concrete action items looked like a surprisingly well-aligned mapping to our problem.
It’s finite – there’s a 25 item limit to the size of that backlog. It’s loosely prioritized – just like Jeopardy, items further down the chart seem a bit more important ($1000 technical debt would be considered more impactful than $600), but every item on the chart is “important enough”. And we have 5 broad focuses for the work contained, controlled by those categories, which gave me leverage to help push the team in the most important directions.
I sent out an invite, fired up a soundboard, donned a fake mustache, and led the team through an exercise filling out that board. Brainstorming and laughs later, we had 25 glorious tech debt items ready to go.
Board in hand, our goal was to see how much we could get through in the next 3 - 6 months. Every engineer can choose only the items on the board they cared the most about. Because every engineer has a different personal relative-prioritization for those items – the service they care about the most, or the thing they want to learn more about, having that broad set of things to take from gives them the power to make more choices. They gave higher priority to what they cared about, but still within our bounded context.
The board was designed to be thrown away. We wanted to take away the monotony of spreadsheets and project management tools like JIRA. We ran with the first set for 6 months, and we accomplished a ton of the priorities on the board.
By designing that exercise, we made forward progress on debt that we had to ignore for a significant amount of time.
- Designing something that’s scrapable to manage technical debt. A lot of tech debt is ephemeral in nature because your active focus today is not necessarily your active focus months down the line.
- Outside of p0 (urgent, business-critical issues), it’s okay to prioritize technical debt loosely. Forward progress on the problems people care about is more important than perfect decision-making.
- Set a time-limited goal for tech debt at each round you try to prioritize it. Outside of critical mission-critical efforts, you may find that some of this work is less important than you expected
- Gamify the process. Our process was a lot more fun, enjoyable and engaging than tech debt backlogs of the past, and by designing it this way we were able to create tremendous momentum on the problems we cared about most.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.
Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart
Roland Fiala, Senior Vice President of Engineering at Productsup, raises an interesting issue about autonomy in teams: does it hinder collaboration opportunities that lead to better problem-solving? He shares his system for promoting teamwork in engineering departments.
Senior Vice President of Engineering at Usergems
Roland Fiala, Senior Vice President of Engineering at Productsup, highlights the importance of soft skills and shares how he motivates his engineers to further their careers by focusing on personal growth.
Senior Vice President of Engineering at Usergems
Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.
Senior Product Manager at Hibob
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Technical Program Management at Apple Inc.