Strategies for Prioritizing Tech Debt: Insights from Joel Hames, Chief Product Officer at Subject

Understanding Tech Debt: Common Causes That Lead to Accumulation

“Guest Post by Joel Hames, CPO at Subject and an EdTech Veteran.”

Technical debt is a natural, normal, and expected consequence of our velocity. In my experience building products across multiple companies, I’ve heard characterized as something to be feared. Quite the opposite, I believe that it represents two critical things: first, the focus on value delivery to users. As we build, we learn, iterate, and update. That creates debt. And it’s exactly the right kind of debt. Second, what we build today isn’t what we’ll need tomorrow. Needs will change. We’ll scale. All of that is normal, and in no way should tech debt be seen as anything other than something you strategically address as you grow – a principle that applies to the construction of just about anything we can imagine.

For just a bit more context: The need for speed – moving fast and iterating – is probably the biggest factor in the accumulation of debt. When you’re iterating rapidly and racing to beat competitors to market and delight your users, things like code quality, documentation, and technical best practices evolve and you practice trade-offs. You have to accept a certain amount of tech debt as the cost of validating ideas quickly in the marketplace.

There are other factors, too. At my startups, we often have small engineering teams, limited resources, and evolving requirements. Engineers are often learning and adapting on the fly, which can lead to experimental architectures that become debt later. Evolving product requirements result in quick changes to the code rather than block thoughtful refactoring. When engineers are heads-down delivering features, it’s hard to take a systems view of how work in one area impacts the broader codebase.

While some tech debt is expected, the key is quantifying it so you can make informed trade-offs. We need to have visibility into our debt, where it’s concentrated, and how it impacts velocity over time. This allows us to take a measured approach to paying down debt where it matters most while accepting it in less critical areas that aren’t slowing us down. Moving fast and managing tech debt aren’t mutually exclusive – it’s about finding the right balance for the stage and goals of the company.

Prioritizing Tech Debt: Impact on Overall Product Development Process, Challenges, and Strategies for Assessment and Prioritizirization

Managing tech debt is an ongoing challenge. But you can meet this challenge by prioritizing it based on data.

First, it’s critical that engineering can provide visibility into our debt – where it lives, its severity, and how it impacts velocity. This helps map its remediation to the product roadmap in a way that’s clear and rational. For example, debt that hinders the development of a high-priority initiative gets prioritized. Debt that creates fragility in our infrastructure that can impact our ability to deliver a stable system also gets prioritized.

My framework is simply to categorize debt as immediate, medium-term, and long-term. Immediate debt needs fixing now because it directly slows feature work. Medium-term debt may cause headaches but isn’t blocking things just yet. And long-term debt can be addressed when we have some breathing room.

This segmentation allows us to build tech debt remediation into the roadmap. We know it will always be a factor, so new feature work is planned with an allowance for both reducing debt and adapting to it. Planning for a 20% debt management tax, for example, bakes it into the process.

No framework is perfect, but having a data-driven process aligned to the roadmap has helped us balance reducing debt while still delivering new customer value at the velocities a startup needs.

Collaboration between product, design, and engineering is crucial to tackle tech debt

It feels a bit redundant and simple to say it, but I will: any work that devalues collaboration and communication is bound to failure. We build great things because of our combined work, not in spite of it. For technical debt challenges, we aspire to open, clear, and honest conversations that surface and rationalize our remediation. A few things I’ve found particularly effective include:

It’s easy to fall into the trap of believing that technical debt is the responsibility of engineering, exacerbating the idea that engineers solve debt. What is critical is creating a culture where reducing debt is everyone’s responsibility. How we prioritize our roadmap, solve problems for our users, grow our company, resource our teams, and manage our technical delivery, all impact our relationship with debt. With open channels for collaboration and transparent data, you get better ownership and outcomes.

Click to learn more

Balancing New Features and Tech Debt: How to Strike a Balance

Wouldn’t it be great to build new features, and never make mistakes, build debt, or worry about scale? That’s not the real world, and frankly, if we had that, we’d be moving way too slowly to grow a business. So we have to balance these carefully, not as two halves of a whole, but rather as two pieces of a puzzle that are required, but can be placed at different times to create the whole thing.

Ultimately, this is an art and not a science. It requires taking a data-driven approach to understand when debt reaches a tipping point of impeding delivery speed or quality. Some guiding principles are:

To give a real-world example, I have built multiple LMS systems, each starting from a basic proof-of-concept back-end that carried heavy dependencies on work outside of our control. These weren’t just individual components, but large parts of our architecture were built on platforms from elsewhere. As we grew, these systems strained under load and limited our creative (and quick!) problem-solving. As the impact on our ability to deliver value increased, we shifted to addressing these systems, in both cases building a modern architecture back-end that enabled us to migrate off of the fragile systems we had been using. Addressing this debt was difficult. It required the “slowing down to speed up” mentality, and careful stakeholder management as we worked through the challenges of seemingly ‘invisible’ goals. In the end, it proved worth it. We were able to grow our solutions more quickly, delivering better and more targeted value.

As noted above, this is more an art than a science. But with communication, collaboration, and commitment, you can navigate this as a product leader and generate outsized returns for your users, and your business.

Looking to find the balance between innovation and managing tech debt in your EdTech? Ubiminds is here to assist you in connecting with top-notch talent specifically suited for EdTech companies.

Click to evaluate your expansion potential

Why Choose Ubiminds?

Specialized Expertise: What sets us apart is our focus on building teams for EdTech companies. Our extensive knowledge of this field ensures that we deliver results.

Risk Free: When you choose Ubiminds you can confidently explore horizons and expand your EdTech initiatives. We take steps to mitigate risks ensuring your success along the way.

Don’t settle for generalist recruiting firms. Let’s build stronger teams together with genuinely collaborative, mission-oriented, full-time-like people who are passionate about transforming the world through education. Reach out to us to get started!

Joel Hames

Joel Hames serves as the Chief Product Officer at Subject, where he leads a diverse team of product managers, engineers, designers, and educators. Together, they craft inventive solutions that harmonize the design language of students with the educational requirements of schools. With over 28 years of experience in education, Joel is dedicated to addressing real-world challenges for users while enhancing user satisfaction and engagement.