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
Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.
Senior EPM/TPM at Apple Inc.
Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.
Head of Product at ROI Hunter
Brad Jayakody outlines the roadmap to maintaining a healthy balance between technical debt and team growth. However, just as balancing acts go it is important to have a strong foundation.
Director of Engineering at Motorway
Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.
Head of Software Quality Assurance at FICO
Matias Pizarro, CTO and VP of Residents at ComunidadFeliz, recalls a time in his early career when he took a technology risk that had wide-ranging benefits to his product's user experience.
CTO and VP of Residents at ComunidadFeliz
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.