The hidden costs of technical debt
I read in Ars Technica that Sonos, the smart speakers brand, will need to spend $20 million to $30 million in the short term to fix their mobile app, after the problems caused with the last update. Not enough, this means they will fail to achieve its annual revenue target by $200 million, as the app refactoring will force them to delay two hardware releases, and they have laid off 100 people after disclosing this mess. Ouch! That hurts.
It seems that part of the problem is the outdated code and infrastructure that the app was running on until now. Legacy code and legacy infrastructure. Technical debt, building up for years and years. Now, they wanted to return that loan (the technical debt) because they needed important architectural changes to support new products, but the interest cut piling up for 20 years was simply too much to swallow.
This is just another case of legacy code and legacy infrastructure being poorly maintained, probably with high effort from engineering teams, for decades long until there is no other way around than to fully replace it. And you know it, the longer you stay without refactoring anything, the higher the cost will be to replace all this legacy.
This wasn’t just about outdated technology or code problems. It was the result of rushing decisions —often more related to investors’ financial motivations than to engineering reasons, taking shortcuts which resulted in longer and bumpier paths, and ignoring the long-term consequences that ultimately crippled the project. It was the result of considering non-functional requirements as second-class citizens.
But the problem Sonos is facing is more than just a lesson in technical debt. In fact, it may be the least important element. This story points to something deeper and more important: it’s a wake-up call for any company dealing with complex systems. It’s about technology, but it’s also about processes and, above everything else, about people.
As the mentioned article points out,
a former engineer told Bloomberg:
«They separated people that had been working together for years creating great products. I don’t understand what could motivate someone to shake things up like that.»
It seems that engineers were afraid of losing their jobs if they questioned the new app’s release. Ouch! Again.
The People-Processes-Technology Framework
The PPT framework is a way to look at the operating model of a company that has been around since the late 1960s, often used to address organizational changes. It emphasizes that for any transformation to be successful, companies need to align their people, processes, and technology. When any of these three elements are out of sync, problems start to snowball.
The Sonos situation is a great example. Sure, they had a technical issue, but that tech failure reflected broader problems in the other two areas—outdated processes and people struggling to adapt to new realities.
Sometimes I say to my consulting clients that in a company technology is not isolated. People make the technology. And other people use this technology in a particular way (processes). So, you may have legacy technology, that’s for sure; but, in every company that has been running long enough, there are also legacy processes and legacy people. Yes, legacy people.
Let's break down each of these dimensions to see how ignoring them can lead to the kind of mess Sonos found itself in.
What Exactly Is Technical Debt?
When we talk about technical debt, we're talking about the compromises companies make to get things done faster in the short term, knowing full well that they'll pay the price later (or they should now). This usually happens when developers cut corners or delay fixing problems to meet deadlines or ship products faster, and when ops/infrastructure people delay some needed systems architecture redesign and do quirks and patches instead, also to ship faster saving time now or because it implies additional work to an already stressed development team.
Typically, we think of technical debt as bad code —legacy code that's hard to maintain, full of bugs, or just plain old. But it also covers things like outdated infrastructure, old servers, outdated cloud systems, or networking equipment that’s no longer efficient. Over time, these small compromises stack up, and the cost to clean up can become enormous.
You can see technical debt as a loan: you are changing time for money. You save time now, like getting a loan provides you with a sum of money that would take a long time to accumulate; but at some point, you will have to pay the amount of the loan with interest that keep growing as time goes. Similarly, at some point you will have to change that code, infrastructure, processes… anyway. The more you delay this decision, the bigger the interest will be.
For Sonos, their debt wasn’t just about code. It included poorly integrated systems and legacy tech that had been patched and re-patched over the years without a real plan for the future. Eventually, that patchwork collapsed under the pressure of a new app launch with timelines driven by financial requirements and not considering the technical ones. But, as I said before, technical debt is only part of the story.
Legacy Processes: Invisible Roadblocks
While technical debt gets all the attention, legacy processes often go unnoticed—until they cause a bottleneck. Every company has a way of doing things. Sometimes those processes are explicit—clearly written down and formalized, and perhaps forced by information systems. Other times, especially in startups, they’re informal, just part of the company’s culture or "how things are done here."
The problem is that these processes, whether formal or informal, can become outdated. They reflect a way of doing things based on old realities that no longer exist. So, even when a company grows, scales, or shifts direction, these legacy processes stay in place simply because "that’s the way we always did it". Even more, often new people don’t challenge these old habits and just follow, without questioning, the old habits that were valid in the old days just because “it’s how they do that”. It is related to processes as it is related to people.
Sonos likely ran into this problem too. Their old methods of developing and testing software, designed for smaller or simpler projects, couldn’t keep up with the complexity of their new app, new hardware and current user load. When processes lag behind reality, even the best technology will struggle to deliver.
Legacy People: The Human Touch
The third element in the framework is people. While it's often easier to blame technology or processes, sometimes the issue comes down to people who are stuck in old ways. These legacy employees may resist change or lack the necessary skills to keep up with the company's evolving needs.
Often, it is the management of the company that changes things without considering if their staff is prepared, have the right skills or needs training. Adapting people to new realities, with all the elements that it implies, is always the most complex and difficult part of any transformation project. This change management in it’s purest form.
Here’s where things get tricky. It’s not that these people are bad employees. More often, they’re just not trained or equipped to handle the changes the company requires. In my experience, the most frequent problem is that management have ignored the people change management part of the equation.
I prefer to write the formula with Processes and Technology being a function of People. Without People “adapting the” and “adopting the” processes and the technology, nothing will work in a way that is sustainable and reliable.
This could mean they need to learn new tools, adapt to different processes, or develop new skills. But if they can't, companies face a tough choice: either retrain them, move them into roles that better suit their skills, or, in some cases, let them go or replace them. In the latter case, please do that with a human touch, helping them, not in the sociopath way of doing things so frequent in today’s world, primarily in multinational environments.
This isn't just speculation; it’s backed by psychology. The famous Asch conformity experiments show how people will conform to group norms even when they know those norms are wrong or without knowing why. In a business setting, this means employees might stick to outdated ways of working just because everyone else is doing it. This is a recipe for stagnation.
Moreover, any time a manager does not include People in any change initiative that she needs to lead, it is headed for disaster. At the end of the day, if People does not embrace (the intended) change nothing could be done successfully. Not including people from the very first moment will drive to unmotivated teams, people leaving the company (remember, the good ones leave first, the mediocre and the bad stays), losing knowledge and money and ultimately, it can lead to the company becoming irrelevant.
For a visual demonstration of how conformity works in practice, take a look at this conformity waiting room experiment, where people imitate the actions of others in a waiting room, even when there’s no rational reason to do so. The same kind of inertia can be found in companies when people stick to old processes out of habit.
The Takeaway
The lesson from Sonos is clear: you can’t cut corners forever. Whether it’s in technology, processes, or people, debt eventually catches up with you. And when it does, the cost is always higher than you expected. Assuming technical debt or cutting corners as a normal way of doing is a dead-end road; you will end up paying it with interest, sometimes very high, as the Sonos case shows.
Managers need to take a systems thinking approach. Focusing only on one aspect—like technical debt—without addressing the other dimensions, processes or people who are struggling to adapt, is like treating the symptoms without diagnosing the underlying disease; it will not fixing anything, but rather create more chaos and a bigger problem. You should always consider the 3 dimensions of the PPT framework for any change to make sense.
The fact that senior employees were afraid of telling top managers what was wrong, as we’ve seen in the Sonos case, although it happens in many organizations, tells us that there was something wrong with values. Corporate values are not just marketing bullshit. Values are the red lines that constrain our behavior; values tell us what is acceptable and what is not. So, fostering a set of values, will drive people behavior: what is ethical and what is not ethical for us, what can and cannot be said or done, how we want to be recognized. When you lose your values - being it explicit or implicit-, you lose your identity, and with that the brand and often the most loyal customers. It’s the beginning of the decline.
To avoid accumulating technical debt, you must create a culture where non-functional requirements are first-class citizens. Continuous refactoring, continuous code deletion (reducing the probability of hitting a bug), and continuous communication to the user will help to create a habit of continuous change.
Creating a habit of continuous change means continuous learning. So, you should create a learning organization if you want to last forever, or at least for long… but I will talk about that another day.
Y además…New technology+old organization=expensive old organization