Lessons from a (tough) quarter tackling tech debt

It's been a tough quarter.

My team and I spent the last quarter focussing on backend migrations, package updates, and decommissioning services.

I am beat.

This was a surprisingly rough experience for me.

In this post, I want to record my experience, share what I've learned, and give my future self tips on handling these ‘seasons of tech debt’ better.

Excuse the slight dear diary angle to this post. I hope it helps some of you, too.

---

What happened?

In Q2 2024, I kicked off a 'season of tech debt'.

We had spent months (years?) moving very fast, from startup to acquisition. Dealing with tech debt, as is usually the case, wasn't really a priority.

Until it became one.

Some of our tech stack was in desperate need of attention. It was time to step back from building features and focus on improving what we had.

With my development team leader, we identified several areas of focus across the entire stack, from infrastructure to packages.

I spent time with stakeholders justifying my decision and got the green light to allocate significant resources towards this project.

On April 1st, we kicked off.

Why was it rough?

I was excited to get this done.

Getting time to fix stuff is basically unheard of. Organisations rarely prioritise this type of work, so I was excited I got to dedicate an entire quarter to it.

Despite that, the quarter was rough. Intense in all the wrong ways.

The main reason for this is simple: there wasn't much for me to contribute.

When working on 'typical' product work (features, bugs, etc.), my contribution is evident. I guide the team towards building a product that helps our customers, achieves specific goals, and generates revenue.

This didn't feel like the case during the 'season of tech debt'. I felt like I was in the way. I had to revert back to a more straightforward project manager role, checking in on people, getting status updates, and, well, letting them do their thing.

For three months.

What would I do better next time?

It's not all doom and gloom. This quarter has taught me a lot. Here's how I would better handle it next time:

Know that it'll be tough

I had fairly rosy expectations for this quarter.

Product people (me included) always complain about the lack of time to fix stuff. When I did get the green light to focus on tech debt, I thought we'd made it. High fives all around!

Now that I've gone through it, I know it's not as simple as that. It's tough. It's lonely; for everyone on the team but particularly for the PM.

Learn as much as you can

One of the reasons I felt useless was my lack of knowledge.

I can't contribute to a heated debate about fixing tests or migrating an RDS instance. And, to be clear, it's not my place to contribute to these conversations.

But one can always be more informed.

Spend time learning the intricate parts of your product, the stuff you may not know much about yet. Go deeper than the average PM. I found having this extra knowledge super valuable.

Be helpful (but leave them alone)

If you can't contribute, advise, or add anything to the discussion, step aside. Let your team do the work.

The best thing you can do is be supportive, take anything you can off their plate, and let them focus.

Understand that this contributes to business goals

One of the reasons businesses don't like to focus on solving tech debt is it doesn't feel like profit-generating work.

Unlike adding a new feature or building a new product, updating packages and migrating infrastructures cannot easily be associated with cash in the bank.

Of course, we know this is the wrong way of looking at it.

In a recent talk, Purvi Shah talked about decommissioning a service at Amex. It was a huge, 18-month project that took enormous effort and resources -- all 'just' to remove something.

This project saved the organisation some $12 million/year (pennies to Amex, sure, but not nothing) and, more importantly, simplified their entire technical stack saving a tonne of future time.

I like Ibrahim Bashir's definition of how different product work contributes to the bottom line. He splits impact into three: adding revenue, maintaining revenue, and increasing margins.

Do you think solving tech debt added to our bottom line? Thanks to this quarter's work, we:

• Reduced some of our bills by up to 60%.

• Removed a clunky deployment process, allowing us to deploy ~2x faster.

• Simplified parts of our architecture, speeding up a core customer experience by 2.2x.

This all adds to the bottom line by improving our margins.

So, here's a note to future me: there is a light at the end of the tunnel. This is important, revenue-generating work. Be supportive. Learn. And be patient.