Community Comment: Part 28 - Technical debt is actually a subset of organizational debt
- Not all technical debt is the same
- Discussion with purported CTOs
- Technical debt is subset of organizational debt
- Business + technology = "our business"
The comments I provided in reaction to a community discussion thread.
Fractional CTO and "Engineering Management Expert":
"Technical debt? Is that a joke?"
CEOs and non-technical CxOs should not have to hear about technical debt — if the engineering department manages it well.¹
Technical debt is is a measure of these quantities:
– DUCT TAPE that holds your system together.
– RUST that has accumulated.
Duct tape represents improvisations resulting from:
– Quick fixes that were needed to "plug leaks".
– Pressure to produce too fast, and not doing things properly.
– Implementing experimental features with minimum effort, in order to gather data to decide whether to pursue them.
Rust:
Systems slowly decay, as if they are rusting.
For example:
– Core assumptions are eroded as the business evolves.
– Third party APIs and libraries evolve, requiring changes.
– Performance is degraded due to significant traffic growth.
– Security best practices change and patches need to be handled.
SO WHAT?!
Advantages of incurring temporary tech debt:
😎 Faster feature implementations. This is worthwhile because 85% of features fail to deliver the promised value. Experiments that don't make it can just be removed. Successful experiments will need a second implementation phase.
😎 Faster MVP implementation. Just like for features, only this is the whole product.
Disadvantages of carrying long term tech debt:
😡 Lost productivity — the more improvisations there are, the longer it takes to deliver new features. You could call this "interest" on the debt.
😡 Lost business — due to breakdowns, missing features, bad performance, security issues.
😡 Increased employee churn — nobody wants to work on a system that is not well maintained, has frequent breakdowns and emergencies, with little hope of being able to change this.
What is your company's attitude to technical debt?
Gfesser:
Hi [Fractional CTO and "Engineering Management Expert"], good post. I'll appreciate your explaining what the intersection of the y-axis and x-axis is intended to represent on your diagram. Does this mean coordinates of 0,0? If so, what does it mean when there is negative cost? Perhaps what you're looking to convey here is that there are cost gains until a hypothetical threshold is reached, at which point these gains start getting reverted. Also, what is your view with respect to whether cost, fragility, and trouble are always directly correlated with each other? Since there is no time axis on this diagram, might it be likely that cost increases in the short-term as tech debt is being paid down? If so, what have you personally found to be a good strategy communicating the benefits and drawbacks of this short-term dilemma?
Fractional CTO & "Engineering Management Expert":
Great — someone is paying attention! Yes Erik, I'm trying to indicate that a small amount of tech debt is beneficial, especially if it's because of experimentation. The most intuitive way for me to show that was to move the graph down below zero. But your question makes me understand that I need to think about this a bit more, and label the origin and y axis clearly and explicitly. The same goes for your question on why I grouped cost, fragility and trouble. I was tempted to label it just "trouble". As I said, I need to ponder on this for a while — thanks for raising these points!
Fractional CTO and Executive and Technology Leadership Coach:
Given the source of technical debt is usually business decisions, I’ve come to the conclusion that technical debt is a myth (or a misnomer, if you want to be precise).
https://medium.com/@nrcantor/technical-debt-is-a-myth-cb122d3c2717
Gfesser:
[Fractional CTO and Executive and Technology Leadership Coach] I think you've made some good points in your article, regardless of whether I agree with everything you've stated. In particular, I like your raising the concept of an "organizational mortgage". I've consulted dozens of firms over the course of my career, and this is a very real issue that many organizations face. Put another way, many firms have organizational debt just like many of these same firms have technical debt, but I would argue that (1) the technical debt these firms possess is really a subset of their overall organizational debt, and (2) many of these same firms unfortunately choose not to look at their issues from a holistic perspective. One of the challenges in discussing this dilemma, however, is that many firms, regardless of domain, are now arguably software firms often run by individuals who don't have software development backgrounds, and as such, systemic issues surface in the software that they build. There is such an overabundance of issues in many firms that it's oftentimes not realistic to single out individual groups, so I continue to hold the view that it's healthier for a given organization to refer to "our business" rather than referring to business and technology as separate entities.
Fractional CTO and Executive and Technology Leadership Coach:
Erik Gfesser You’re absolutely right about technical debt being a subset of organisational debt. They go hand in hand, and the same thinking drives the accumulation of both. Just like organisational debt, it’s often the right decision, even though the consequences are differencent off they’re ignored.
One of the perspective I try to hold I’d the same as what you’ve described – technology and the business aren’t separate entities. They’re intimately connected, interdependent parts of a whole. If I’m completely honest, however, I sometimes struggle to keep that perspective, given how many years I was on ‘one side’ of the imaginary divide.
I think the companies that successfully adopt a holistic, system-wide view, have a massive competitive advantage, because they can see the consequences of decisions in ways that functionally divided companies can’t.