Spending more than a decade in the R&D I can tell you with high confidence that high quality code is hard to come by!

Nowadays, it seems like there are much more development frameworks that should ‘spare’ you with the need to write actual code, and it seems, to me at least, that the concept of ‘software engineering’ is slowly becoming a lost art.

The end result, of course, is buggy and ‘hard to modify’ software.

We can debate whether things are getting worse than they used to be in terms of software quality, but this is not what I wanted to discuss. I think we can all agree that much of the code out there is not greatly written and hence will struggle to meet future requirements.

 

If you have some runway as a product manager then surely it happened to you – 

You are asking for a change in a behavior that sounds quite simple and the engineering team informs you that ‘this is actually a fundamental change to how things are working today and it will take at least two sprints to change this’.

This is always annoying to hear. You may want to pull your hair (a privilege I no longer have due to lack of hair), but eventually you’ll either need to change the requirements, work with the engineering on a different approach or accept the cost.

Now, if this is a repetitive pattern then maybe it’s a time for some infrastructure work, and what we refer to as a ‘tech debt’.

 

What is exactly a tech-debt?

A tech-debt is referring to internal code changes that are not ‘vital’ from the product point of view. From the customers and users perspective – nothing is changing and they get no immediate new value. It’s also likely that given a different or better infrastructure – those changes wouldn’t be required.

However, tech-debt items do posses value, mainly in the form of:

1. Accelerating development in specific parts of the code/modules
2. Reducing internal infrastructure costs by optimizing usage of resources
3. Enabling future features that otherwise would be impossible or very hard to develop
4. Align coding standards across the board
5. Improving root cause analysis and debugging processes by planting vital logging and analytics events in the code
6. Improving internal security and policies compliance
7. Improving alerts & monitoring of the infrastructure services

And this is why, as a product manager, you can’t ignore them and you should work with the R&D to promote them.

 

How should I prioritize tech debt items?

A very good question.

The answer to that highly depends on your engineering team and your level of trust in their code and estimations.

 

A good known rule of thumb is to devote 20% of each sprint to tech-debt tasks. That’s quite a bit of time, so the question is – do you trust your R&D team to make the most out of this time?

This is not a question which is trivial to answer. And the reason is that with tech-debt tasks – the responsibility over the ‘why’ and the ‘what’ (why we are doing this [the value] and what we are building) is handed over to the R&D instead of you. You only control the ‘when’. Hence, in order for the R&D to work effectively on their tech-debt tasks they need to do their homework. It drills down to how experienced is the team leader responsible for that.

 

I worked with many R&D teams in the past. For some – it was very easy – I simply asked them to bring to the sprint planning their suggestion as for how to use their 20%, and be able to explain what’s the upside of implementing these items. They did their homework, managed to convince me of the value and it got into the sprint.

However, some of the more ‘junior’ and less experienced teams didn’t know what exactly they wanted to do or they couldn’t describe the value we’ll be getting by working on those. In such cases you have only two choices:

1. Work with the team more closely to refine their own requirements and what they are trying to accomplish or mutually understand that the value doesn’t justify the work
2. Reject the item and ask them to raise it in the next sprints if it’s more mature and ready to work.

 

Naturally, option #1 is the better way to go – but sometimes, due to time constraints, you simply won’t have the time to delve into this. Another reason is that it may be too technical for your expertise (and that’s legit – you are not a developer). If that’s the case – consider taking it with the CTO or the group manager and suggest they will run a mentoring session or two.

 

At the end of the day – if the tech-debt items are properly defined and you are convinced in the value (for example – you are convinced that any future features involving this specific module will be developed much faster) – then there is no true reason to block this. Add it to the sprint unless there is a tactical priority decision you need to make specifically regarding this sprint (a focused effort, for instance, on closing a long-waited feature). 

If you didn’t manage to meet your commitment for 20% capacity for tech-debt items then compensate for this in the next sprints. It’s important you’ll stand by whatever you’ve agreed on with the R&D team. Don’t make them beg you – it breaks trust!

 

What if the tech-debt is rather a ‘project’ than an ‘item’?

Yes, I’ve seen this several times. The R&D will come to you and tell you that (for instance) the infrastructure of this module sucks. The code is undocumented, spaghettis-like, unreadable, poorly designed, written in ancient ages, written in platforms which are no longer supported, etc, etc…

And it goes like this:

You: “Ok, so what do you suggest?”

Group leader (GL): “Re-writing major part or all of it”

You: (crap) “And what’s the effort estimate for that?”

GL: “4-5 sprints of two people”

You: (WTF) “Come again?”

GL: “4-5 sprints of two people!”

 

Whenever it happens – it’s bad news.

Either the GL has no idea what he’s talking about and we’re simply dealing with junior engineers who don’t feel like maintaining others’ code OR the GL knows exactly what he’s talking about and then you are facing a real threat to your roadmap.

Either way – as I said – bad news for you.

 

Just to be fair – when I was a young engineering team leader I did the same to whomever was the product then. They worked very hard trying to convince me this is not needed and at the end of the day I decided they are half right and we managed to narrow down the scope of the project. I’m just saying that it’s quite natural for junior engineering leadership to reach such conclusions – so you need to take this into consideration.

How to handle this?

I’ll repeat again that if this is the message you are receiving there is a problem for sure. It’s either with the code or with the people. None of them is good, but I prefer to have a problem with the code because the code can be fixed. Good people and especially good engineers are hard to find.

Now, if you have an engineering background it’d be much easier for you to get to the bottom of this. I know it’s not your job, but believe me – it’s for the best. Any work items you manage to eliminate out of this project, while still extracting the value – it’s a win! So if you do possess such a background, sit with the GL and ask him/her to walk you through. Where is the real pain? What’s the origin? And why do they believe this approach is the most efficient one? Ask for alternative approaches and analyze them together. You may be able to cut the scope of the project to one or two sprints eventually.

I once managed to cut such a project from 145 days to 36 in a single 30-minutes meeting – while still getting the majority of the value of the project. I simply leveraged this event as an opportunity to get rid of unnecessary flows and also corrected some of the wrong working assumptions the engineering team had regarding where the value is.

So having an engineering background is certainly a blessing in such cases, however, it’s not a must.

 

Here is what you need to do regardless of whether you have an engineering background or not:

1. Inform the engineering team that since this is a huge effort estimation it needs to be handled as a project, and the first step is to document and agree on the goals of this project. Ask them to write a document that details what are the current pains they are handling and why the world is going to be a better place after they are done (‘features related to X are going to be delivered 3X faster’ and so on).
2. Tell the engineering team that before you can approve this project you’d like to see a plan which is divided into sprints. 4-6 sprints can easily turn to 10-14 sprints. Trust me – I’ve seen this happening more than once.
3. Once you receive the document and the plan – review them with the team and ask them to explain it to you in the most non-technical manner they can. Listen carefully and think – is it all really necessary? Are there any flows or adjustments that can be postponed for later? Your goal is to narrow down the scope to the bare minimum which is necessary to deliver on the main value.
4. After you agree on the scope and the time it’s gonna take – take a look at your roadmap. How does this tech-debt affect it? If everything was done properly in advance – then this tech-debt was already accounted for in the roadmap, but sadly this is rarely the case. Make adjustments to your roadmap by pushing forward items or simply removing them. Do you like what you see? Probably not… but it is what it is and it’s probably the time to communicate this upstream to your boss and whomever else it may concern.

 

The key in handling this is to challenge the value such a project delivers and work to narrow it down to the bare essentials. The challenge is that the project involves deep technical details which are rarely understood by product people. 

This is why the instinct of the product is either to kill it or accept it as a whole, assuming the engineering team knows what they are doing. Don’t assume that. They may be great developers but good chances they are not great in project management. Help them.

 

Summary

The bottom line here is the following:

1. You need to adopt the working assumption that tech-debt is part of reality. Don’t fight it, but rather accept it and just make sure it’s done efficiently.
2. If executed and managed properly – tech-debt can help free future bottlenecks and make the development more efficient.
3. If managed poorly – it will result in the exact opposite – it will postpone your roadmap and will accelerate loss of trust between product and engineering.
4. It’s your right and your duty to require a plan which covers also the ‘why’ and the ‘what’ from the engineering team in case the tech-debt spans over several sprints.
5. Be agile with tech-debt the same way you do with your own user stories. Break it down to small chunks, where each chunk delivers a value of its own. You’ll need the engineering team by your side in order to achieve that because it’s quite technical.

 

That wraps up the post for today.

If you found this post/series useful – please let me know in the comments. If you think others can benefit from it – feel free to share it with them.

Thank you, and until next time 🙂