Let’s get something straight. Everyone hates technical debt. It’s not controversial.
IT staff hates technical debt because it forces them to work in ways they don’t want to: inefficiently, on outdated technology, for systems that are already being phased out. IT leaders hate technical debt because it’s always out there, preventing them from moving on big initiatives, causing problems in getting innovative ideas approved to move forward given the large balloon payments that debt retirement would require.
Business and product leaders hate technical debt because they never stop hearing about it. It’s the same broken record over and over: “We can’t do that new idea until we retire our debt from the legacy system, otherwise we just make it harder to remove the old system that’s holding us back in the first place.”
Software may indeed be eating the world, but ever-increasing technical debt is eating away at development capacity.
Despite the universal loathing of technical debt, I still hear the same messages from enterprise clients: “Even though transformation and modernization are enterprise initiatives, we still can’t get the budget and staff required to retire the legacy systems.” It’s with this context that I’ve decided to religiously follow one of the key recommendations from MuleSoft’s Catalyst Maturity Assessment (CaMA) — I’m going to retire (pun intended!) the term “technical debt” in favor of plain old “debt.”
No classification needed
In working with enterprise customers from around the globe on transformation initiatives — API, DevOps, Agile, or other — one thing remains true: once a topic is classified in either technical or business domains, the respective tech or business teams tend to own managing it. Despite what one would think, ownership doesn’t necessarily mean freedom to act without collaboration or scrutiny. In practice, tech teams can’t always make progress on tech topics without business cooperation and vice versa. Attempting to make enterprise progress from one specific lane without the collaborative input from other disciplines is not a recipe for sustainable value or success. Real change and sustainable value only come when a majority of stakeholders are represented in developing the path forward. This concept is at the core of the aforementioned recommendation, “Establish New Debt Management Model – Redefine how the enterprise talks about, tracks and manages technical debt.”
One of the core reasons that tech debt is so hard to retire revolves around how people talk about and model debt and the work that goes into retiring it. Pre-transformation or in-transformation enterprises tend to talk and operate in a “Plan, Build, Run” model (rather than the “You build it, you run it” federated model made popular by Werner Vogels CTO of Amazon). In the Plan, Build, Run model, many shops over-rotate on separation of duties, and the resulting process resembles an assembly line factory where the business owns “the what,” the dev team owns “the how,” and then the operations team supports whatever the people upstream from them were so kind to throw over the wall. Just like DevOps turned this model on its head and showed that major market and business advantage can come from investing in operational speed, it’s time we take this one step further and democratize the concept of “technical debt” and rename it plain old “debt.”
In this new model, with no classification, everyone gets to contribute to the pile of things that they know would be good to do, but can never manufacture the commitment to get after in a deliberate way, For example:
- Does your web experience feel fragmented because you haven’t been able to create and enforce a visual/interactive style guide that standardizes the online interfaces of your enterprise? Add this to the debt registry!
- Does your product catalog seem bloated with a few too many old offerings that are only in use by one or two customers who are resistant to migrate to newer and more supportable products? Pile on!
- Do your BI and finance teams pull all-nighters to manually aggregate month-end reports that are only valuable for a period of days or weeks? One more item in the list!
“Comrades in arms” beats “us vs them”
Many of the recommendations that come out of MuleSoft’s Digital transformation blueprint revolve around the ideas of community and federation specifically because modern enterprise operating models all rely on the concept of democratizing access to assets and unleashing motivated self-directed teams to create value out of this new level of autonomy. Inside this method of creating a more dynamic enterprise lies a basic truth of social systems: once all parties have skin in the game, a topic becomes more viable to make progress on. What this means for debt is that it’s been predictable all along for tech debt to be an unyielding albatross around the neck of an IT department. It’s been set up that way from the start because it came pre-categorized as the problem of one department!
When teams and organizations allow for debt to become something bigger than one group’s basket of orphaned tasks, then the wider community has more easily identifiable skin in the game. When everyone is working off the same list, now everyone is united in the call for something to be done to get the list down to a manageable size (rather than waiting for it to build up so long that your enterprise halts all development, like LinkedIn did, to pay down the debt). Imagine how much easier it can be to get your product or business partners talking about debt reduction when the items for retirement include things from their discipline as well as yours. This new model leaves behind the arrogant idea that only technology teams have to deal with the “do more with less” narratives and that only technology has a backlog of items that can’t get prioritized because of non-linear paths to increases in revenue.
Shared sorrow is halved, shared joy doubled
Some IT leaders and practitioners may recoil in horror at allowing other disciplines to have equal footing in debt remediation conversations, and I understand their reluctance. Tech debt management is almost always an “unloved child” topic; Why would we want to invite more people to the party when we don’t have enough resources to serve the people already here? It’s this belief that is holding us all back.
One of the core reasons there is not enough punch to go around at the party is that not enough people are at the party to begin with. Getting over the fear of losing scarce resources is clearly hard. What’s harder than that is holding on to a model and process that isn’t actually working while everyone looks to you make it work. When we open up the repository for all types of work that never gets the support it needs, you now have the fertile ground to form alliances with your peers and partners to support the remediation of the capacity killing debt that is the scourge of all. After all, there’s nothing like a common enemy to unite previously separate tribes.
Curious to know what other game-changing recommendations come out of our assessment process? Download our Digital transformation blueprint to gauge your team’s maturity today.
