Now that I have your attention, I invite you to lean back and crack a cold one with me. Let’s yell at the cloud together for a minute. We will fight it out in the comments after.
Disclaimer⚠
I’m well aware that orgs exist that handle technical debt like adults. These orgs either keep it as a simple metaphor for grown-up change management or use it as a term of art with actual accountability and consequences. This rant is geared towards the chop shops that throw tech debt around like Flex Tape.
Technical debt
Technical debt as a metaphor is an incredibly valuable communication medium. It’s supposed to fit non-functional changes into a business model.
It’s such a powerful meme that it’s taken off and evolved to the point where we are having discussions about accidental vs strategic debt , or how we should avoid it or leverage it
It’s gotten too much attention from programmers so that it has become a pretentious word for maintenance. For everyone else, it’s become a tool to make excuses for pet projects.
Maintainence
Maintenance is in the eye of the beholder. You set up a maintenance budget, and it’s the first thing that is corrupted by stakeholders.
- Refactoring a product to add a bunch of features can be interpreted as maintenance
- Replacing an existing system with AI is part of a deprecation cycle and, therefore, maintenance
- Implementing a shiny new authentication framework to remove security risks? Maintainence
These can arguably take precedence over
- Upgrading infrastructure
- Writing documentation
- Patching vulnerabilities
- automating recurring tasks
- Making logging consistent
We’ve started to talk about technical debt like a target because it’s often convenient to put stuff on the roadmap under the guise of reducing technical debt 👻. Using technical debt as a spooky goal in itself hides the underlying interests.
Types of work goals
The reality is that all the work attributed to tech debt has different goals, and treating this work as uniform makes it impossible to evaluate whether the objectives have been achieved. Fundamentally, any work has 4 possible goals.
- Increase revenue 📈
- Reduce Costs📊
- Manage Risk ⚠️
- Fun 🎉
Increase Revenue 📈
Simply put, any work that will contribute to the bottom line by attracting more business, expanding the market, or preventing revenue loss. This can include new features, as well as resolving long-standing issues that hurt paying customers. If it comes from sales, line goes up. This goal is often smuggled into technical debt work and causes scope creep.
Reduce Costs 📊
This can be directly related to the costs of tools, suppliers, and hosting, as well as reducing the cost of delivery by increasing velocity. If you can deprecate an entire internal system, scale down hosting, or cut your turnaround time in half, this is cost reduction. This is often marked as technical debt, as high-cost practices are applied to achieve a quick TTM, and the results are cleaned up as expected technical debt.
Manage risks ⚠️
Sometimes work is done not for the bottom line, but to make sure we have a job in the morning. Typically, this involves preventing production defects and outages, increasing testing, and addressing security vulnerabilities, but it also involves future-proofing. If you don’t keep up with your stack, you run the risk of unforeseen work in the future. This is the work that engineers feel most strongly about. Risk is usually not factored into the bottom line.
The benefit of talking about risk is that, like debt, it’s an excellent metaphor non-technical stakeholders are well-versed in. But it’s much more precise and allows you to pinpoint the urgency of your proposed changes.
Fun 🎉
Fun is the work that has no immediate tangible benefit to the organisation. These can include your moonshot projects, pet projects coming from leadership, educational projects from new faces, and genuinely morale-boosting money sinks. Fun projects are crucial to any team. We need to have fun projects, but we must be honest about when a project is enjoyable and not try to hide it behind ulterior motives. You want your fun projects to be visible and identifiable. You want to show the organisation you are committed to fun.
Shadow accounting
In the general zeitgeist, technical debt can live anywhere outside of increasing revenue. In practice, technical debt has become work free of accountability. Working on technical debt has become a goal in itself, a useful quagmire for all stakeholders to hide the actual goals of the work. Revenue-increasing features are smuggled into tech debt under the guise of replacing existing features. Cost-reducing measures and risk management are fighting tooth and nail for that sweet tech-debt budget, while everyone is trying to get their fun projects approved without accountability.
WTF are you doing
Before starting work on any change, make sure the following is defined and agreed upon ahead of time:
- which of the 4 goals it’s related to
- how your proposal will achieve them
- quantify the expected results of the work
If you can’t do that, there’s a very high chance someone is wasting someone else’s time.
After the work is done, evaluate if the expected goals were reached and hold the initiator accountable.
For my Australian colleagues 😏🦘:
- Put the bill on sales to hit their sales projection on that new feature
- Hold your turbo-geeks to the expected savings of that 2-year refactor
- Celebrate spending Q1 on an openly fun project
- Keep the receipts on the risk updates when the outage comes
Conclusion
I ran out of bourbon 100 words ago. Please stop using tech-debt to smuggle pet projects onto the roadmap. Be honest about opportunities, risks and fun. Real badasses work together. 💪
