Read time 6 min
Imagine this from a business owner’s perspective: you order a very complicated and expensive technological wonder. Once it’s ready (a small wonder in itself), your delivery partner’s team comes over and says they need to do some refactoring for the technical environment.
Customer: “Oookay, what will change, and how much will it cost?”
Delivery partner: “Well, from the user’s perspective, nothing will change. Oh, and it will cost about the same as the initial project.
You: “Umm, interesting, and tell me again why we should look into this?”
Delivery partner: “There’s this thing called technical debt…”
What is technical debt?
Custom software development basically means creating things that have never existed before. 80 percent of developing, programming, configuring, integrating, and testing consists of just figuring things out. Only when you’ve done that, you understand what the ideal way would have been from a performance, simplicity, cost, or stability point of view.
Once you develop the product further, you might notice that there’s a better technology for a similar task you’ve just solved. Since the schedule is always tight, you add the new technology to your solution without rewriting the previous code. Everything works, but the delivery team is painfully aware of the shortcuts taken and the potential problems there could be in the future.
In a way, you start making technical debt when you start programming. However, there are ways to overcome this. One of my colleagues said (with a bit of humor, I guess) that you can just add, for instance, two months to any software release and use that time to go through and rewrite the previously released code. You can also analyze or minimize technical debt with solid testing and review practices that help you spot potential issues and add them to your backlog. You can split the team to ensure that a suitable amount of work is continuously invested in keeping the code solid.
This sounds simple, right? Still, it doesn’t happen so often. The business pressure wins, and usually, the things will be fixed “later.”
What makes this a board-level problem?
With the whole world in a state of flux, companies need to be more adaptive than ever and quickly react to market changes and new opportunities. While you can still plan some things as before (my salute to the waterfall world), particularly the consumer business market is moving too fast for traditional budgeting and planning cycles.
Consequently, corporations face a repeating pattern: people responsible for businesses need new solutions faster than IT or traditional R&D functions can provide them. Business owners have their own budgets, and eventually – with frustration and delays – they will decide to order the necessary solutions on their own without the co-operation of their IT infrastructure team.
This might work very well in the short term; there’s a brilliant new service, business owners are happy, and new revenue is pouring in. The new solution is then handed over to the infrastructure team, potentially with a few integrations missing. If the tender was organized in a hurry, the business owners might only have budgeted money for the development, not the maintenance or the small fixes required to keep it alive (not to mention technical debt).
Infrastructure people are frequently amazed by the continuing idiocy of business owners. Don’t they understand that now instead of 200 systems, we have 201 systems to keep up to date? The opposing sides end up locked in a bitter battle that starts to echo to the board level: new strategies won’t move forward as quickly as expected.
One of our coaches said that most change agendas are like trying to turn a Lada into a Ferrari just by changing the dashboard. Even the most ambitious digital projects with 200% management support tend to drag their feet if the underlying engine does not support the new way of doing things.
Are there solutions?
I am sure some people reading this think that technical debt is a technical problem (it’s in the name already, for god’s sake). I agree and disagree. The root cause is often in the culture, leadership, decision making, and values.
We had a representative from the Finnish grocery giant Kesko participating in our recent eCom event, talking about how to deliver 1000% growth by your eCom platform. His story was fascinating. Their success was possible only because they had run a transformation program for 4-5 years before scaling up in such a fantastic way. During that transformation, they looked into structures and incentives and changed things to be market-driven. “If I want to put a feature request in for our development team, I need to act as an anonymous customer,” said the business owner. Nowadays, an autonomous team is responsible for their whole end-to-end process, empowered to choose what’s on the backlog. For similar reasons, I think things are pretty much interconnected in any company.
We at Reaktor work on all levels of an organization, from board-level advisory services and organizational sparring to deep technology projects. Instead of changing the dashboard, we recommend fixing the engine first. There are often systemic issues with skills, processes, communication, work practices, and so forth.
Once there is a good shared understanding, clarity about targets, and jointly agreed ceremonies in place, it’s time to automate. Testing, builds, and releases should be automated as far as possible so that human effort could be used where it adds the most value. Only now is it time to continuously measure, optimize, and improve everything to maximize the intended business impact.
For this to make sense and bring value, the team or unit should work in direct contact with the market. You could, for instance, form an autonomous team that can quite independently react to changes in demand or new opportunities. Then moving up in complexity, the team should be organized around clear cash flow, and it often means discussions about structures and incentives. This might require taking a hard look at procurement, budgeting, and decision making. It might benefit from a management board that has great team dynamics and solid prioritization and conflict resolution practices. And as we are all different, we should learn to be more resilient. That’s why we teach top management about how to meditate and understand their own emotions.
I’m saying that not only should you create new things. You should do it in harmony with the infrastructure team to continuously modernize the legacy architecture. It helps if, at the same time, you can break the vertical silos and old incentive and KPI models and build market-driven end-to-end value chains. You also benefit from a culture & brand that both attract new talented people and help your existing personnel to be empowered, passionate, and fast-learning to push your business into new heights. That’s a pile of consulting jargon, but I do believe in it. Naturally, it’s a long journey, just as the Kesko representative stated. These are not easy transformations.
These are my personal thoughts, so don’t blame Reaktor for my fuzzy logic (well, honestly, loads of it is stolen from my colleagues, especially from our senior coaches). Happy to hear where the glitches are in my thinking. You can reach me via email firstname.lastname@example.org.