Most product managers, like myself, do not care much about technical debt when overseeing a product. We think itâs an engineersâ thing and as such do not pay attention to it. To be fair, sometimes thatâs true (it can be an engineersâ thing), but sometimes itâs not. Moreover, we can benefit from understanding what it entails.
If you want to discover one more way to build a better product and be closer to your engineering team, keep reading!
History of the Term âTechnical Debtâ
âTechnical debtâ is a metaphor coined by Ward Cunningham. It describes a framework on how best to deal with cruft, by thinking of it as financial debt. The extra effort it takes to add new features is the interest paid on the debt.
How does it Appear?
Everything here is pretty simple. Sometimes we ask engineers to build things âas fast as possibleâ because we shouldâve released a new feature earlier.
Think of it like this: peers help us and create new rooms in our building (the product in question), they do not erect strong walls, build a bed only for one person and other unexpandable things. When the room is initially built at the time of the request, it looks good - we test our hypothesis and get valuable data from users, etc. But, what happens next? We desire to extend this room (an added feature in our project) by asking for a few improvements, and we notice something goes wrong.
A simple change, for some reason, takes significant time and uncovers new bugs to our previously sound logic. How come we face this? Whatâs wrong with our nicely (for a customer at least) built room? If we had an opportunity to look inside, weâd find out that our room, which looks perfect on the outside, has weak walls that are close to destruction. And whatâs more? we notice that there are now three grizzlies trying to have a rest on this one-person bed â total chaos, in other words.
Does âTechnical Debtâ have any Consequences Beyond the Difficulties of Extending Features?
Sure! Imagine youâre a painter trying to decorate the outer part of this structure. You made the first attempt, checked the result, and saw a few Ńracks. Youâre OK to fix this for the first time, but what will it look like the fifth Or maybe the tenth time you have to fix the cracks? Of course, youâd hit the ceiling and start finding a way to avoid working with this structure altogether. The same happens with engineers and teams in general, all members become less inspired, and performance drops.
But is it necessary to clear technical debts as soon as possible? Some would say yes, but I canât agree with this statement. And the reason is pretty straight - it all depends on the situation and the debt type.
If it doesnât prevent you from moving forward and you can pay interest without any effort, think of it positively like a garage for rarely-used things. One that allows you to keep your house free of unwanted stuff, a home for unused construction material.
Moreover, you can continue improving your home or even renovate it - you already have a room for things you donât use frequently.
Letâs consider another situation - establishing a foundation. If a foundation wasnât designed for a multi-story building, say it was built for a two-level house, you wouldnât be able to build a multi-story structure. A scenario like this would lead you to struggle with interest payments on a technical debt and as such the debt should be attended to as soon as possible.
Common Approaches for working with Tech Debt
OK, now we have a rough idea of what is hiding beyond the âtechnical debtâ term. Letâs figure out what we can do with it.
Devsâ Priority
Most of us are familiar with the first way: On some days, we have a chat with our tech lead, he claims that weâve had some ârefactoringâ tasks in our backlog that we havenât paid attention to for a long time. Considering the estimation for its resolution is nearly a month, we start asking why we should work on it, what happens if we postpone refactoring for extra time? etc.
Typically product managers do not want to spend such time on the strange activity of refactoring â we already have an enormous amount of desired features in backlogs â and occasionally, engineers canât explain why we should work on tech debt asap. So, we continue building a multi-story product on a foundation for a two-level house.
You already can imagine the consequences of such a decision.
Fixed Time
The second approach can be more productive for closing debt. Just allocate fixed time (or story points) in a sprint to accommodate refactorings, architecture improvements, etc. Heading this way may lead you to a stable product life with an anticipated and manageable amount of technical issues.
Looks good, doesnât it? so why shouldnât we choose this strategy? We can! but itâs not the most optimal way for your product. Using this technique leads to more spending on things you do not want to improve. Here, engineers usually choose what we should refactor, and thatâs the point, they may not know what weâre looking to build exactly and choose a garage for renovation instead of a foundation redesign when we want to erect a skyscraper.
Proactive approach
Weâre moving smoothly (I hope) to the third method. It requires more of the product managersâ time, but it has its pros, for one, we get to improve our productâs technical health consciously and optimally. So what should we do?
I have put the following list together as a guide:
-
Keep in mind that engineers are savvy folks. They very well know how to build a product but sometimes have difficulties with what exactly they should be building.
-
Remember, as a product manager, you know your customers, their needs, your company strategy, product metrics, and other business-facing specifics. In other words, you understand what you want to build and why.
-
Combine the first two ingredients! Always share with your team (it will be helpful and not only for engineers) everything you can about product plans. You can also educate the team on customer obsession and product responsibility. Do not hold prospects of a particular feature â
whether itâs a test, code for which you may delete in the future, or already a stable solution â your team should understand the difference.
-
Look at your product development like youâre building a house on a plot of land. Your team will create rooms, floors, decorations, etc. But they also will dismantle some parts of it and build over again. And while your folks are involved in the reasons and consequences of different features, your product will consistently become better, not only from the business perspective but also from the technical point of view.
In addition to the points above, encourage the engineers to take initiative and choose the best part of tech debt to clear per time.
No more difficult conversations with your tech lead, no more refactorings in the wrong product places - deep team synchronization does its work.
Outro
For final words, love your customers, love your team, make the world around you better. And remember, the way you create products is unique and no one else can do it quite like you.