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

Team Development Framework for new managers

26 June

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.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Promoting Interdepartmental Teamwork for More Efficient Problem-Solving

13 June

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.

Internal Communication
Collaboration
Roadmap
Team Processes
Cross-Functional Collaboration
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Motivate Your Engineers to Grow in Their Careers

13 June

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.

Goal Setting
Different Skillsets
Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Motivation
Team Processes
Career Path
Performance
Roland Fiala

Roland Fiala

Senior Vice President of Engineering at Usergems

How to Successfully Rebuild Your Product

6 June

Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.

Customers
Product
Dev Processes
Users
Prioritization
Adir Nashawi

Adir Nashawi

Senior Product Manager at Hibob

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

Technical Program Management at Apple Inc.