Do your clients report bugs about your product to you? Does your team fix an issue or push a new feature only to create 10 new issues? Perhaps your product used to be awesome but over time it has started to lack polish or is getting slower to use?
Many of these issues tend to be caused by “Technical Debt”.
Technical debt is defined as “Implied cost of additional rework caused by choosing an easy or limited solution now, instead of using a better approach that would take longer.”
Essentially, someone made a “good enough” decision or the “cheaper” decision in the past that is now causing issues today. One “good enough” decision isn’t always going to hurt you, but over time 100 or 1000 of these types of decisions tend to compound into issues that directly impact your customer’s experience.
Not all technical debt issues are felt by your customers. You might have a crack team that doesn’t ever let bugs or performance issues get in front of your customers. Instead, you as the business leader might experience a slow down in delivery or an increase in cost to deliver something new. This might be due to your engineering team being forced to make complex engineering choices in order to weave around prior technical debt decisions.
So how do you manage accrued technical debt?
At some point, you, a new product owner, or the newly promoted team lead will ask the hard questions: “Enough is enough! When are we going to address the thousand pound gorilla in the room? When are we going to start fixing some of our technical debt?”
As a leader of the company you will need to make the decision to put a plan in place. This plan will seek to make your customers happier or make your product development teams more efficient at delivering new features. Both of these results are better for your business!
Do we throw the baby out with the bath water to achieve the quality and delivery speed we need? NO – rewriting your product from scratch is almost always a horrible idea for reasons we can discuss another time.
What technical debt should you fix first?
To resolve technical debt in a manner that makes sense for your business we need to build a plan. This plan can start with a few different approaches:
- Fix something that is easy and on the periphery of your product
- Fix something that causes the highest number of calls to customer support
- Fix something that is critical to your business
Each of these strategies come with different risks, pains, and gains.
Fix something easy and on the periphery
If you have a junior to intermediate level development team, you may want them to fix technical debt in something that is less critical to your overall system. This gives them the ability to try new approaches to solving problems. They can feel safe in learning, as making a mistake may not come with pain inflicted on the customer or the business. The team can build their confidence on something simple before graduating to more difficult tasks.
Fix something that causes the most support calls
Identify the reasons for your top 5 support calls …and if you don’t know this, now is the time to put some reporting in place. A reduction in support calls means that something impacting your customers has been addressed. This has the added benefit of making your customers love you because you are fixing their pain and it makes your employees happy as you are addressing their needs too.
Nobody likes taking the same call 50 times a day “yes sir, I know sir, we are aware of this issue and are working on it”. That can really kill morale and motivation!
This can impact your NPS score and boost positive word of mouth referrals which will ultimately boost your bottom line.
Fix something that is critical to your business
Perhaps you have an issue in your product that keeps your business from moving into a new market or industry? Perhaps you have performance issues that keep you from running more than one marketing campaign at a time? Perhaps the way your product was originally created doesn’t quite align with how your business operates today which causes a lot of manual labor outside of the system?
All of these things can be signs of technical debt in your system blocking your business from improving and scaling and ultimately, profiting.
Steps to fixing technical debt
Once you have decided that fixing the technical debt is important you will need a plan to resolve it. Here are some steps you as a business leader can take to get started.
Company leadership steps
- Communicate to the team, not just the engineers, that you would like to see the product quality improve and that you are willing to invest in making the product AWESOME! The team that allowed technical debt to amass in your product isn’t going to fix it on their own without you driving that priority home.
- Sell to your leadership team why you think solving technical debt is important for your company, your customers, your product, and your employees. You as the leader of the company can only do so much up front. You need to convince your leadership team that your mission is their mission.
- Have frequent “retrospective” meetings where you can identify things that need to improve (like technical debt) and then plan for that improvement to take place in your next product development iteration.
- Ensure that reducing technical debt is part of your culture. The opposite of focusing on quality (debt reduction) is that your culture allows the creation of technical debt and degradation in quality and customer/employee experience. Everyone should be as excited as you are about making your product better.
Daily strategy for reducing technical debt
- Think first! As a product engineering company, we spend a great deal of time helping our customers think through the features they are building and how they will be implemented. Taking the time to think through each bug fix and each feature implementation pays huge dividends in solving technical debt. Simply not creating any more technical debt will help out a lot.
- Identify owners. You most likely have a product owner that owns all the features of your product. You might have someone that owns your customer support group and how that world is handled. Be sure that you also have someone that owns the architecture and someone else that owns the quality. This can be a hat that someone wears in addition to their title as team lead, manager, etc. But without someone owning quality and implementation details – nobody does! These owners don’t have to be (and probably shouldn’t be) the chief “doer”. They are your coach for how to do things better.
- Refactoring is critical. When a decision is made a year ago it was most likely the most appropriate at the time. But when you bump up against that decision in your product later, actively fix it. Refactor the code so that it is up to date with your new quality standards. Make sure the code complies with the way the company thinks or acts now. Ensure the product, the UI/UX, and the design all fits with what you are now doing. Don’t let an aspect of your product linger and fester into an area that nobody wants to touch. It will only get worse.
- Regression test regularly. Quality is something you test for once and then never again. As you add new features and test the quality of those new features, ensure your team is also looking around for any new breakage. If the product is fairly stable, add automated tests to your product. You should continuously test your product from all angles to ensure that the quality remains at least as good as it was. Fixing one thing shouldn’t result in 10 new issues the customer has to deal with and is the first to see.
- Measure technical debt. Measuring your technical debt can happen in a few ways. You can run analysis tools over your code and identify flaws. You can run test coverage tools to see how much of your code is under test vs. not. Or you can look at key business metrics, like call center volume. You can look at the performance of your product and track if it gets more performant over time. But the key here is that you start capturing data about your product, analyze it over time, and let the data drive your strategy for improvement.
- Technical debt review in workflows. Include technical debt in your code review and feature review / QA processes. Could the team have resolved this technical debt issue as part of delivering this new work? Require that they do it before accepting the new work.
- Plan technical debt into sprints. The only way to actively reduce technical debt is to ensure that some percentage of the work your team does is to actively resolve past issues. You might choose a number: 5%, 10%, 20%. Then hold your team accountable to ensure that some percentage of that iteration’s work is actively making the system better.
Should you seek to eradicate all technical debt from your product? No! That is probably never the right thing to do. There will always be the law of diminishing returns applied to this. Fix it because it improves your business performance, customer experience, reduces call volumes, enables the product teams to innovate easily- or 100 other business drivers.