Update: in the afternoon of January 14, news emerged that Sonos CPO Maxime Bouvat-Merlin is also leaving the company.

Sonos CEO Patrick Spence is out, felled by last year’s disastrous app launch. I have no inside track on what happened, but from what I’ve read, Sonos’s leaders made some terrible decisions. They’re worth looking at so we can avoid making similar mistakes.

Before I elaborate, a few disclaimers. I’m not a Sonos customer. I’ve heard good things about their products and bad things about their business practices. (They eventually rescinded some.) I don’t know anyone who works there and have no details on how they went about this project. So this post is speculative.

That said, news reports make it clear that Sonos made several questionable choices. From my vantage point, the most egregious was deciding to wholly scrap their previous app under pressure.

Scrapping the old app may be excusable, since it had accrued a lot of technical debt. In September, Bloomberg published an article by David Lee that offers insights into what happened. Among other things, it highlights the following:

For two decades, Sonos had allowed its tech debt to pile high. When it undertook in earnest its effort to revamp its app in mid-2022, the company knew it was sitting on infrastructure and code written in languages that were pretty much obsolete. The Sonos app had been adapted and spliced and tinkered with so often, the vast majority of work being performed for the new app was less about introducing new functionality than sorting out the existing mess.

I bet the codebase was an unmanageable hairball. So I can understand the impulse to retire it.

The problem is that Sonos isn’t a product; it’s an ecosystem. And ecosystems evolve gradually. When the company introduces new products, developers tweak the codebase. They introduce exceptions to make the new product work alongside older products. It’s not just features: developers also establish protocols and standards. When things break, they fix them.

Do this repeatedly over two decades and you end up with a complex system that works – even if it’s held together with tacky tape and prayers. This takes time. You can’t quickly recreate the complexity embodied in twenty years’ worth of tweaks.

By “works,” I mean offers customers a good experience. Customers don’t care if the codebase is a giant hairball. They care if their expensive new speaker gets arbitrarily dropped from the network.

As I see it, Sonos failed to heed Gall’s law:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

The old app was a complex system that worked, at least from the user’s perspective. One must be very careful when messing around with such things. You can’t scrap an ecosystem without pissing off a lot of people.

But Sonos wasn’t careful. Fixing the hairball was a daunting task, so they didn’t prioritize it. To get around this, they hitched it to a critical new product launch. Again, Lee:

The company could have tackled its tech debt sooner but appears to have lacked a crucial element: urgency. It finally came in the form of the Sonos Ace headphones, the first product in the Sonos range to be fully mobile rather than using home or office Wi-Fi. The app needed to be rebuilt, as did the cloud computing setup underpinning it.

This was happening amidst 1) layoffs and 2) a reorg. 🤔

These are leadership decisions. To recap, they opted to:

  1. Scrap their old app and restart from scratch
  2. Tie the new app to a critical product launch
  3. Do it while implementing major organizational changes

Each of these decisions is questionable on its own. In combination, they proved disastrous.

Lesson: be conservative when changing established ecosystems.

Systems that have evolved over time are better fit to their purposes than anything you can design from scratch – even if the team is exclusively composed of brilliant designers and engineers. With a complex enough system, nobody can account for all eventualities.

The company acknowledged as much in their postmortem. Again, this is from the Bloomberg story:

[Sonos lead counsel Eddie] Lazarus said the company had a list of what were regarded as “essential” bugs that needed to be fixed before launch. Bugs it deemed to be less critical, or functionality it felt could be left off temporarily, would be dealt with after the launch. When I asked if it was possible the company’s idea of an “essential” bug might have differed from what customers considered vital functionality, Lazarus paused before saying: “Our list of essential bugs, obviously, was not comprehensive enough.”

“Our list of essential bugs was not comprehensive enough” is a phrase for the ages. It perfectly captures the risk of violating Gall’s law.