Business Blind Spots: How product pressure breeds Technical Debt and how to deal with it
Technical debt is the worst name for something the whole company is responsible for and is mainly caused by non-technical people in the first place. It’s like blaming the “climate crisis” on climate scientists and expecting them to be fully responsible for solving all the problems. Let’s be honest, technical debt is a company’s problem. When you talk to those geeks in the engineering team, they almost always want to deliver “the perfect solution”, which, in principle, eliminates the effect of having any debt (and leads to unacceptable timelines). Usually, the product team and the business enforce corners cutting, fast delivery, more delivery, and NOW delivery because that matters to them. They often ignore red flags from the engineering teams raising concerns about missing functionality, lack of code hygiene, leaving a mess, not testing enough and making their life much more complicated in the future.
In 99% of cases, technical debt comes from pressure, lack of visibility and poor product management.
So there you go, I said it.
Customer obsession is a good thing, right?
Just touching on the obsession a little bit. When a company says they are “customer obsessed” or “product obsessed”, it’s usually the first sign that technology concerns and tech debt might be an afterthought. Nothing with “obsession” in the name is a good thing, even if said in a way that is supposed to be amusing. There are probably some good intentions behind it, but very often, it’s become an unhealthy excuse to just cut all the corners to satisfy not only users but also investors, board members or some high-level egos at the cost of developers’ experience.
Everything has its own place and requires balance. Delivering a good product sometimes means delivering fast and dirty. At other times, it might mean overinvesting, more planning than usual, and testing until it becomes incredibly boring. It depends on the product’s purpose, lifetime, value, meaning, importance, and business goals.
I see “obsession” as a significant red flag, often indicating a company burdened with a substantial amount of tech debt.
What is a tech debt, then?
Tech Debt is everything we leave behind that should be completed as part of the product/feature development:
- Cleaning up the code
- Writing extra tests to cover new scenarios
- Removing unnecessary complexity
- … and much more
Completing these things doesn’t translate into immediate value for the business. Still, if they are not done, they become a headache for the engineering team, affecting their output quality and speed.
Tech Debt — we borrow time to deliver now and care less about the side effects, but we must repay it later. If we don’t, we pay a hefty interest, not only in time currency.
It is not a tech debt if something bothers engineers, but it doesn’t negatively affect their delivery ability. Indeed, the code can always be better; things can be improved, but perfection should not be a goal in itself. Again, it’s all about finding the balance. Engineers are notoriously known for overdoing, but that’s where clear business direction and goals help steer the right decisions.
Get Andrew Winnicki’s stories in your inbox
Join Medium for free to get updates from this writer.
I already mentioned one of the most significant contributors to the tech debt, but there are more reasons why this might happen.
- Total blindless of the tech team of the product strategy and direction for the future, which translates into a lack of predictability and working only one sprint at a time. This is the easiest way to ensure nothing is futureproofed in the code.
- A lack of care or understanding from the tech team of what good code looks like often leads to leaving behind a mess with an attitude “it will be someone else’s problem.”
- Constant and never-ending pressure to deliver new shiny things. It’s like working in a coal mine 24/7 and not having time to shower or sleep properly. This ends up poorly.
- The project effort is severely underestimated, which leads to a lack of time and unnecessary self-imposed pressure, and that’s mostly the tech team’s fault.
- Externally created debt occurs when libraries and third-party integration change, and the team either has to manage very problematic dependencies, create weird hacks, or upgrade, which sometimes might cause a ripple effect across the whole application.
- Micromanaging teams often happen when they are led by a non-technical person (who theoretically is also not in charge), like scrum masters or delivery managers.
- Lack of trust in smart people hired to write complex software solutions to solve business and customer problems. A company should not pay 100k+ to a lead engineer to tell him/her how to do their job.
- Blame culture where “us vs. them” mentality becomes very strong between delivery (agile) teams. When that happens, tech debt is probably the least of a problem.
- When everybody thinks that the Tech Debt is the Tech’s team problem…
I’m sure there are more examples of root causes, but these are the things that have had the greatest impact on me after working with multiple teams and companies over the years.
Can Tech Debt be a good thing?
It is possible to avoid tech debt, and it’s not the Chinese government’s way of “Tech debt from now on is banned. Therefore, it doesn’t exist anymore”. Some companies are very aware of the challenges and let their teams address challenges and futureproof regularly. While no debt is an excellent goal, it is tough to achieve in the real world and counterproductive, just like 100% test coverage of the whole codebase.
Tech debt can also be good as it shows that team members are thoughtful and understand that it is sometimes worth cutting corners to achieve specific results quickly. Maybe to test something before starting to build a full-blown solution that will take months? Or what they build is supposed to be live only for a short while. These things might create tech debt, and it’s OK to make them less than perfect.
I once joined a big corporation working on a very cool product. I saw their tech debt board with over 2,500 tickets, many as old as 3–4 years. You know what we did with them all? CTRL+A, DELETE and did not affect us at all, but it created a lot of joy and relief.
Like everything in excess, tech debt or total lack of it can be detrimental. But when it’s understood, justified, and regularly addressed, it can be managed effectively. Our lives are all about balance, and maintaining a healthy level of debt is no different. So, rest assured, tech debt is not a monster we can’t tame but a challenge we can overcome.
A side note…
I love to use tech debt as a training ground for new starters (I’m talking about debt, not tons of bugs!). Usually, it’s an excellent way for new joiners to quickly dive into the code, show the initiative and bring some outside-the-box thinking. It can spark discussions and new creative ideas on how to solve problems. I love this approach to getting the team up to speed very, very fast and letting them contribute meaningfully from day 1.
How to deal with “product debt”?
Obviously, no silver bullet will magically solve the problem, and every company requires a different approach. So, let’s cover at least some of them:
- Review the tech debt board and be bullish about it. Likely, everything older than 1 year has a 95% probability of being deleted and forgotten. Anything above 2 years, delete; don’t even bother. This only means that this is the first time anyone has looked into these things for a long time.
- Make sure teams estimate their work correctly, add enough overhead for unexpected issues (which always happen) and let them incorporate good testing and tech hygiene into the process. It’s not about delivering the shiny feature and quickly moving to another shiny thing.
- Allow teams to discuss tech issues during product planning and scoping in the early stages. The tech team should always be involved in product strategy and planning to help uncover things lurking in the background. They need to have a voice at the table together with the businesses and design teams.
- If necessary, allocate 20% of the engineering team’s time permanently to deal with tech debt and ongoing improvements, which are not part of a particular product roadmap. It could be one day a week or maybe 1 development (sprint) cycle every 4. Or at least a solid sprint once every quarter. It all depends on your needs and how much mess there is to clean in the first place. Often, it also depends on how much the business will allow the engineering team to do that, which leads me to another thing.
- Ensure business and product teams understand the cost of tech debt, cutting corners, and the mess left behind by quickly delivered features. Translating “future hours wasted” into $$$ and time is easy. People listen when their ability to move fast is affected.
- Explain that tech debt is not only a problem for tech teams. Maybe you should stop using “tech debt” and call it “product debt” instead. That might help create a wave of change and understanding of the problem.
- Prioritise and review debt regularly, at least once a quarter, to prevent it from growing beyond control. The organisation’s tech and product leaders are responsible for this.
- Ensure all engineers are encouraged and supported to make small, incremental changes in the code as they work on it, leaving the playground a bit cleaner as they found it. That’s the Boy Scout’s rule!
Please share if you have more ideas about solving the tech debt problem. I would love to hear your opinion on that. I’m sure I didn’t cover everything, and good ideas and different perspectives are always welcome.
