Back to resources

Prioritizing Technical Debt

Dev Processes
Tech Debt
Team Processes

24 September, 2021

null null

null null

null at PolicyGenius Inc.

Ben Picolo, Engineering Manager at PolicyGenius Inc., shares how together with his team, they gamified the whole technical debt solving process.

Problem

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.

Actions taken

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.

Lessons learned

  • 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Balancing Technical Debt Innovation: How Roadmaps for Development Help Your Company Succeed

4 May

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.

Alignment
Leadership
Impact
Roadmap
Tech Debt
Career Path
Brad Jayakody

Brad Jayakody

Director of Engineering at Motorway

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

Why You Should Take Technology Risks in Product Development

25 April

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.

Innovation / Experiment
Product
Scaling Team
Dev Processes
Matias Pizarro

Matias Pizarro

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.