My own brush with the 'Spotify Model'

Yesterday, I started the story of how I voluntarily booted myself out of squad team work and into… well, it wasn’t exactly clear.

To give a bit of background, the company I was working at was changing fast. We were hiring developers and other individual contributors like there was no tomorrow, including front-end developers.

Up to then, we had mostly been working in teams organised by technical discipline: Python devs, Java devs, front-end devs. This worked OK when we could still shout abuse have ad-hoc face-to-face discussions with each other. But we’d long since outgrown it.

We had been gradually and painfully switching to cross-functional vertical teams for some time, but had also retained horizontal platform teams to retain close governance over the big tech scaling challenges we were facing. The result was messy, to say the least.

All this was happening against the background of tech industry chatter about structuring product organisations. The biggest influence over the last five years has been the vaunted Spotify Model. You’ve almost certainly heard the language of the Spotify Model: squads, chapters, guilds, tribes.

So, we had front-end devs working on multiple teams (or squads in Spotify parlance), but that didn’t include me. I was now an architecture astronaut. Or a floating line manager. Or a bit of both. Like many in high-growth startups, I was supposedly in the position of being able to largely define my own role.

In terms of the Spotify Model, I saw myself as taking on the role of a Chapter Lead. We held regular front-end chapter meetings. These had genuine actions and decision-making powers, so for a bit of wry fun, we adopted some of the language of communism too. Using terms like collective and politburo served to demonstrate that in reality we had no idea what we were doing, so we might as well enjoy that fact together.

We had taken on some of the structures of the Spotify Model. But that’s not enough.

If you look at the illustrations (part 1 and part 2) from the presentation from which these structures were taken, there is a whole lot more there than squads, guilds, tribes and chapters.

We lacked the focus on customer impact, continuous improvement and delivery, culture-focused roles, lean, kaizen and psychological safety.

Instead we focused on the team structures and their names, because changing those things seemed easy in comparison. We lacked the wider product and engineering culture shift that’s required to enable those structures to work.

Indeed, the ‘Spotify Model’ doesn’t actually exist. Spotify didn’t name it that. Their presentation was just describing their own engineering culture. It’s a case study. Others took these ideas and turned it into a ‘model’.

Ultimately, I spent a great deal of time on line management and hiring responsibilities, and wasn’t able to spend much time on the technical side of the work.

That’s because my role was most strongly defined by the overall culture of the organisation, not whatever structure has been imposed upon it. And culture is very much harder to change.

“Culture eats strategy for breakfast”, as Peter Drucker almost certainly never said.

Have you moved completely away from individual contribution work? I’d love to hear about your own experiences of how it happened. Hit reply and tell me all about it.

All the best,

– Jim