Technical debt 🏦 is often accumulated and ignored in software projects that are struggling with quality, timelines, and expectations. Instead, teams focus on fixing bugs, adding new features, and building quickly. Ignored tech debt is like a monster 👹 that the business knows exists but that it is afraid to talk about 🫣. This monster only becomes a priority when it becomes a blocker or costs more money. Until then, the business assumes that the team will simply learn to live with it.

In the meantime, the engineering team 🤹 has to work on a superficially stable 😵‍💫 product. They patch up 🩹 and build new features 🏗️ on an already leaky product. The team may say technical debt is stopping them from building features X, Y, and Z. They can only deliver X1 and Y1. Some Product Owners (POs) may find an alternative path to squeeze the feature set into the release. They think they’ve achieved the impossible 🥳. In reality, ignoring team feedback is a 🧨 mistake that lowers morale and trust. Over time, you end up with an unhappy, 😖 less motivated team.

Prioritizing a Collaborative Product Experience

As POs, we prioritize the customer experience. But our responsibility extends beyond users 🧑 and the business. We must include our engineering team 🤹 and other stakeholders. Once you consider everyone, you will notice the rough edges and gaps. We must assess the gaps in our process, discuss, and create a plan 📝. We need to focus on the immediate and larger gaps, and set timelines to address others. The earlier we resolve these problems, the better.

I have come to realize by focusing on the collaborative product experience, including all primary stakeholders, and not just the customer experience, we can create a better outcome 📈 for all. We must set aside time on our roadmap 🌎 to review and address technical debt. Give time between releases for teams to recharge themselves 🏖️, reflect on their work, and come up with ways to improve the collaborative product experience 💡. It’s possible that tech debt is not the monster 👻 we always thought it was. Or, perhaps worse, we’ll find that by ignoring tech debt for so long that it was us who made it into a monster 👹. You will never know until you look.

Understanding Ignored Tech Debt

If you want to know the type of monster you are dealing with, keep reading. Here are some steps I suggest to deal with ignored tech debt.

Allow the development team to conduct a technical audit to identify and compile a list of tech debt items. 

This process can be time-consuming, especially for teams that work on legacy infrastructure, unstable products, or systems where tech has not not been actively managed. Product owners can focus the team’s efforts by providing specific goals for the next few releases or for the year ahead, allowing the development team to review connected pieces and identify potential blockers.

Work together to understand the business impact, development impact, and cost of fixing each item. 

Use a simple scale, such as small, medium, large, and extra large, to categorize the ignored tech debt. Development impact refers to the effect of tech debt on the product from a technical point of view, the development team’s job satisfaction, and the team’s morale. You may also consider other factors relevant to your development team.

Map tech debt items on a chart against business and development impact. 

The size of the circle should correspond to the cost of fixing. This will help you to prioritize which tech debt items to address first.

Address debt with high business and high development impact first. 

For example, this could be a mobile app or site that not only frustrates users and leads to lost revenue, but also slows down development. Everyone should be motivated to eliminate small and medium-size circles within the current development cycle, but larger circles may require a conversation. Collaborate with the business and development teams to understand tech debt impact and if larger circles can be split into smaller ones. Resolve as much tech debt as possible while meeting release goals, and ensure everyone understands the cost of delaying or not fixing tech debt. Develop an action plan and timeline for revisiting remaining debt and make space for these items on the product roadmap.

Prioritize items with low development impact but high business impact based on potential impact on the user experience or business goals. 

An outdated payment processing system is an example of such tech debt. It may not directly affect the development team but can cause users and the business to suffer. These items may surface in the future as feature requests, so it’s crucial to address them sooner when the impact is smaller rather than later. Categorize and prioritize these items based on their impact on the business and development, and create an action plan to address them.

Next, focus on tech debt with high development impact but low business impact. 

While these items may not directly affect the business goals, they can have a significant impact on the development team’s ability to deliver quality products. Examples of such tech debt include code refactoring, code optimization, and writing unit tests. To prioritize these items, work with the development team to understand their impact and estimate the cost of fixing them. Then, identify a use case or scenario that demonstrates the value of addressing the tech debt, and present it to the business stakeholders.

For example, you can show how refactoring a piece of code can improve performance and reduce risk in future releases. It’s important to approach these conversations with empathy and understanding. Your goal is to help the business stakeholders see the long-term benefits of addressing the tech debt. By investing in the development team’s productivity and morale, you can help them deliver better products faster with higher quality and confidence.

Save low development and low business impact debt to address last. 

While these items may seem trivial, they can still add up. For example, the unused code or feature in the product clutters the codebase and might make it difficult to maintain over time. In this category, evaluate each item and consider its long-term impact on the product. Start with those that are strongly connected to the product roadmap and goals for the year. For the remaining items, analyze and understand what happens if these tech debts are not fixed in a year. If the answer is little to no change in size and impact, carry them over to the next year. But if ignoring the debt increases its impact, prioritize and create an action plan.

Long-Term Benefits for All

Remember, it’s important to regularly review and address tech debt during your product development process. This helps maintain the health and stability of your product. It also ensures that the development team can work efficiently and effectively. By prioritizing and addressing previously ignored tech debt, you can create a culture of continuous improvement and quality. As a result, you’ll deliver a better collaborative product experience. Ultimately, a positive and motivated team is essential for the success 🌟 of any project, and it is our responsibility as POs to ensure this. Do the right thing for your people and product.

This post was contributed by Rushi Pol, the Product Owner Craft Steward at Robots & Pencils.

This article describes my strategy for learning new technology, refined over the decade or so that I’ve been working in tech. As with any advice based on one developer’s experience, you may find that it’s obvious or that it doesn’t apply to you, but I hope it’s useful as a guide, a checklist, or even just a starting point for reflecting on your own learning process.

When I talk about learning a technology, I mean something pretty concrete. I would apply this approach to:

• programming languages
• data stores
• libraries and frameworks
• tools (git, Docker, Regex, etc.)
• platforms (Linux, AWS Lambda, Google AppEngine etc.)

I wouldn’t apply it to:

• methodologies (TDD, agile, effective writing, etc.)
• high-level concepts (parsing, ML, IoT, serverless, etc.)
• low-level details (virtual memory, garbage collection, etc.)

A 3-Part Strategy for Learning New Technology

Here’s an overview of my strategy: when I’ve got a new technology to learn, I think about going through three broad phases:

1. Consuming documentation
2. A learning project
3. Application

Phase 1: Consuming documentation

My first stop when approaching any new technology is documentation, especially intro docs or tutorials. I do love a technology that comes with good documentation! This phase might also include courses, blog posts, or other third party material.

Beyond actually learning the technology, in this phase I’m looking for:

• Points of comparison: Is this technology similar to something I already know?
• Unique features: What are the ways this technology is different or surprising? Where might I apply it instead of something I already know?
• Integration points: What kind of projects could I use this technology for? Will it let me leverage things I already know, or does it require me to discard my usual toolbox?

The objective is obviously not to learn everything there is to know, but to create connections to my existing knowledge so that I can start using the technology and find my way to answers in the future.

Some examples of great material for this phase:

• A Tour of Go
• Clojure Programming
• Execute Program

Phase 2: A learning project

Once I read the introductory documentation, I try a little project using the new technology. I aim for something small but not trivial. I want something where I can safely apply the skills I’ve just (supposedly) learned but also something that will challenge me and expose any gaps in my understanding.

Note that this isn’t learning on the job or building tools to scratch your own itch (though those are important skills in their own right). It’s a project that’s conceived, planned, and executed with learning as a primary goal.

I try to find a project that:

• Highlights the new technology: I won’t learn much about a new database if I’m struggling to get my front-end code just right. If I want to try out that auto-documentation feature, I should make something that I’d want to document.
• Is just beyond what’s comfortable: Getting frustrated with advanced features isn’t productive, but neither is retreading material from the tutorial.
• Doesn’t have too much instrumental value: If I set out to build something, I might overlook a new technology’s failings if I want the thing badly enough.
• I can put some polish on: The point is to learn a technology well; it’s good to have some time to polish, review, or get feedback.
• Above all, I want a project that’s small: A tight scope helps me keep focus and leaves me free to fail fast if the project isn’t working.

The objective is to discover all the things that the new technology’s documentation didn’t address:

• How difficult is it to install/build/operate?
• Can I integrate it with my existing tools (languages, editors, source control, packaging and deployment, etc.)?
• Does it still feel elegant and useful when I’m using it on an original problem (and not a carefully chosen example)?
• Did I actually learn it well enough to turn an idea into a reality?
• Am I confident that I’m using this tool correctly? Idiomatically? Sustainably?

My experience has been that these kinds of questions aren’t always addressed very well in documentation or are addressed more with hype than with facts. If, after putting in a genuine effort, I can’t get a new technology to work for me, it’s an indication that the tech might be immature. Alternatively, my understanding might be flawed or the technology might not be a good fit for what I’m after.

Some examples of projects that I’ve done in this space:

• What Tide is it Right Now.com
• The Prettygood Passphrase Generator
• Mondriandroid

I also find it helpful to write up a little experience report when I’m finished. This helps me capture and clarify my impressions of the new technology and have something to share with others.

Phase 3: Application

Once I’ve done my learning project, I’ve hopefully got a good sense of where a new technology fits and whether or not I want to keep working with it. At this point, it stops being a target for deliberate learning. If I’m trying to further develop my expertise, I look for:

• Opportunities to use it professionally: Perhaps I have a work project where the new tech is a good fit or is already a going concern.
• Side projects: This can be bigger and more instrumental than a learning project while still being a safe place to experiment.
• Complementary technologies: Sometimes it might be appropriate to start this process over with a related technology. (For example, you might learn Elixir then Phoenix, or Rust then WASM).

Naturally, I’m always looking for opportunities to go deep on a technology (heck, I’m still learning things about Python after nearly 10 years!) but I’ve found that further expertise comes much easier with study and experience than it does from studying alone.

This post was contributed by Nat Knight, one of the principal developers who supports our clients and projects at Robots & Pencils.