I thought I was done with the series of articles on the importance of empowered engineers, but then an article came out a few days ago criticizing the Spotify model of Agile at scale, and I could not pass up the opportunity to try to turn this into a teachable moment.

The author criticizes the Spotify model of scaled Agile, but neglects to mention that Spotify built a company now worth more than $25B, while competing – and often winning – against both Apple and Amazon, two of the very best product companies in the world.

And then the author goes further, and recommends instead considering the process adopted at Fitbit for scaling Agile, but neglects to mention that immediately after they did, the company’s value proceeded to plunge from over $10B to less than $2B.

There’s a lot of talk today about focusing on outcomes, but here’s a chance for people to see quite clearly the difference between output and outcomes.

That said, this does raise some important questions:

First, did Spotify succeed because of the process they used? And did Fitbit suffer because of the process they used? There’s really no way to know for sure but the theory I argued in Empowered Product Teams and The Most Important Thing would explain both Spotify’s success as well as Fitbit’s struggles (more on that below).

Second, even if we ignore the actual business results, what about the specific criticisms of the Spotify model that were called out in the article? Are they fair criticisms? I think they are, and in fact in 2013 I raised those very same concerns to leaders at Spotify.

But what the article fails to mention, is that what they got right at Spotify was much more important than what they got wrong.

If you peel away all the Agile process talk, pithy nomenclature, and clever videos, the core of the way teams work at Spotify is empowered product teams, and especially empowered engineers. In particular, the level of autonomy given to those engineers. At Spotify, the dial for autonomy is set all the way to 10.

While I am all about empowered product teams, and I love setting the dial relatively high on autonomy, it is easy to point out the inevitable inefficiencies that arise when individual autonomy is set so high, and management and leadership is set so low.

But the Spotify leaders explained to me that they were aware of this trade-off, and they considered this an acceptable price to pay for the benefits of fully empowered teams and engineers. The Spotify leaders also explained to me that this choice was in part a reflection of Swedish engineering culture.

I left the discussions fully believing that Spotify would need to adjust how they work to deal with the consequences of the weak role of management and leadership, especially as they grew (which they have indeed addressed in several aspects, creating that difference between what was evangelized and what they evolved to), but that overall I was not worried about them, because it was clear their business depended on consistent innovation, and they were doing what I considered the most important things to nurture that.

It’s worth noting that I’ve had the same discussions with teams at Google where they also set the autonomy dial very high. In fact, it was Spotify and Google that inspired my series of articles from 2015 discussing the trade-offs involved with autonomy: Autonomy vs. Leverage, Autonomy vs. Mission, Autonomy vs Ownership and Autonomy vs. Initiatives. I also have published articles to encourage Spotify and others to raise their game in product management and product design to be as good as their engineering.

In stark contrast, at Fitbit, the company that the author cited as having a process he liked better for scaling Agile, they adopted the polar opposite of the empowered team model. This process uses delivery teams rather than empowered product teams, and if I’m right about the necessity of truly empowered engineers for innovation, while you might see an increase in output, you would expect to see a serious drop in the amount of innovation, and then in business results, especially in an innovation-driven market like wearable technology. And sadly for Fitbit, after they adopted this process in 2015, that’s precisely what we have witnessed.

Is Fitbit’s decline due to these reasons? Impossible to know for sure, especially since I don’t personally work with them, but I find it absolutely inexplicable that they would move to the process they did. And my understanding is that the leaders behind this ill-conceived move are no longer there.

Now to be clear, while I do consider Spotify a strong example of empowered product teams, the process for scaling Agile they promoted several years ago is not what I personally advocate, nor what I am writing about in my new book, however, it’s critical to keep all this in perspective, and you could do far worse than to adopt Spotify’s model of scaled Agile.

So I hope that people don’t take the wrong lessons away from both Spotify and Fitbit. Most of us would absolutely love to have the degree of ongoing success that Spotify has earned.

Rather than obsessing over process details, you should be looking for the deeper truths that have fueled their record of innovation.