I am currently a software engineer on the productivity team at GitHub. I have been a software engineer for my whole working career, which is coming up to eight years now 😬. However, most of this time has been spent bridging the gap between product management and engineering. Feeling the push and pull from both sides is something I have experienced a lot.

That said, most of my career has been in greenfield projects. Bringing great entrepreneurs ideas to fruition through technology.

Working with startups is fast paced, deeply interesting and super fun. The most interesting part for me was, "technical debt" and "legacy code" didn't really exist. Due to the nature angel stage startups, they tend to work to a very tight deadline with a limited amount of cash. This ultimately means that they work knowing that they may not exist in six months time. Paying technical debt just isn't a priority at that stage. You certainly don't have time to build a legacy codebase. What's the point in paying off our debt if you can't find a product market fit? Who cares about crappy code if it's going to be in the junk yard in a few months time anyway?

If a startup manages to find product market fit, then the runway becomes longer. This gives time for your technical debt to catch up on you. You won't be able to move as quick. It starts to feel like you have a ball and chain around your leg. It's crippling. It leaves your yearning for the start-up culture once again.

Although we have achieved a lot in a short amount of time, the tech industry itself is still relatively young. For example, Uber, Lyft, Instagram, Snapchat are all younger than 10 years old. As the industry and the products grow up, there is going to be a growing environment appearing. Legacy systems. Working on legacy systems will become more common place than it is today.

So what does all this actually mean for product managers?

Historically, software engineers have looked to declare bankruptcy on legacy systems in favor of starting over again with a re-write. We have learnt that there are huge hidden costs behind re-writes. This prolongs the time to market and reduces how fast you can validate your ideas with customers.

There is a growing belief that the technological evolution of a legacy systen needs to be done over time. Moving the system from X to Y gradually. Think of it like creating an ice sculpture, you tend to chip away at the ice. Step back every few minutes. Check the shape of the design. Sculpting by making small incremental changes leading to the final master piece.

All this is to say, I believe that building empathy for the team and the state of the system is going to be vital skill that a product manager must have in the near future. By building empathy it will allow the product team to continue to ship features while also moving the in right technical direction. It also means that the refactor can grow up with the change in product requirements.

So how do I build empathy for legacy systems?

I believe there are three key points to being successful in this area:

1. Seeking out limitations

Actively seek out understanding of the current system. Understand the limitations and the affect it may have on speed of development. If you are working on a new feature in a part of the codebase that the team hasn't touched for a while, ask your EM or technical lead to scout the area. By doing this, you can set realistic expectations to stakeholders. And gain brownie points from your engineering peers.

2. Chip away at your debts

Honestly, this is the best thing that you could do for the future you and the future of the product itself. Chipping away at the debts enables you to move in a more agile and nimble way in the future.

I tend to think of it this way. If you don't service your car, I would bet my bottom pound (I am British) that you will break down one day. That could be in the near or distant future but it will happen. If you continuously service your car, I can't guarantee that the car won't break down. But you will have a much lower chance of it happening.

3. Bake time into your product lifecycle

So you have decided to service your car, that's great. Don't go expecting the service to be done in five minutes.

You should look to bake a certain amount of time into the product development lifecycle. The sole aim being to tackle technical debt and legacy system problems. Carving out this time will allow the team to explore and make the right choices to improve the state of the system. Again, enabling quicker future iterations.

Work with you engineering peers to figure out what the split looks like. But always be pragmatic.

The ultimate goal is to reduce the opportunity to have that ball and chain secured around your leg. By continuously investing time in technical debt and legacy system updates, you will be able to continuously keep moving. Meaning you can keep providing value to your customers.

I hope this has been insightful and may be even thought provoking. Of course if any of you have any thoughts, ideas, contrary beliefs I would love to chat about them @mrsimonfletcher.