In 2016, I had an amazing time at Agile Manchester to share about my experiences of scaling agility and lessons we learned at Refinery29. I wanted to take sometime to put it into a post for wider audience for consumption so everyone can learn from our failures, inspect and adapt. In case you are wondering, I was an Agile Coach at Spotify.
What is Scaling Agile @ Spotify
This section is for folks who have not yet read Scaling Agile @ Spotify white paper or seen a Spotifier giving a talk about how Spotify organizes! If you know already, please jump down to next section or feel free to read on for a refresher!
Squad is the building block for Spotify tech group and the most important. It is the foundation for our organization and the usual go to for problems solution. “Take it to the team” Squad is a small cross functional team sharing the same mission, and preferably colocated. Squad should feel like working in a mini-start-up where you can do whatever you need to do while Spotify acts as an incubator. Before you ask, no squad does not report to Product Owner (PO), PO is part of the squad. Diagram indicates each squads have a PO.
Next set of building block is the chapter. Chapter is a domain mastery group and purpose is to share knowledge, learn from each other, personal development together while reducing silo effect and sense of isolation. Chapters are led by a Chapter Lead, servant leader whose main purpose is to support and focus on nurturing, growth of chapter members as individuals and as a group.
Tribe structure is to support the group of squads and chapters. Tribe back in 2012 was led by a single leader, often engineering lead. Tribe lead is no longer a single individual’s responsibility but a group made up of product, engineering, design, business, coaches, depending on the need of the tribe. Key take away for tribe leadership is that like the chapter lead, it is all about servant leadership.
Spotify is focused on being incubators for squads and tribes is one of the ways to be just that. The tribe leadership is responsible for making certain that squads have all the support and autonomy that’s needed to be successful. This includes overseeing the recruiting function for the squads, as well as managing physical spaces, budgets, etc. Like the squads tribe supports, tribe also has the autonomy to experiments in different modes of operating. I think it’s pretty safe to say no two tribes operate exactly alike.
A guild is an open community so anyone can join or leave any guild. You can join multiple guilds, depending on your interest. All guild activities are optional by default. As guild member, you can choose how active or inactive you want to be in the guild. Guilds themselves are organic as well. Original intention of guild back in 2012 was to cross pollinate and nurture domain masteries across tribes. Now its progressed beyond that and guilds are formed around any common interests such as cycling, movies, and so forth. Evident of this is that while I was there. Spotify had so many guilds and I had no idea many were around and believe me that I tried to find out to satisfy my curiosity.
As Spotify grew so did the numbers and size of the tribes, amount of overlaps and touch points between tribes led to increased friction and moving slower, lower autonomy and alignment. To address those points, Spotify scaled up once more to introduce Alliance building block. Alliance structure is a support for group of 2 or more tribes that have closely aligned missions. Not all tribes have an alliance.
One of key sauce at Spotify is alignment. While alignment isn’t explicitly captured in the white paper. Through alignment Spotify makes best effective use of autonomy and leadership spends ton of time building alignment so that autonomy thrives.
The org structure elements of Spotify is a function of that culture which is a reflection of those values. All of these exist to support and enable the squad, the most important building block.
Now that you are more informed about Scaling Agile at Spotify. Onward on how Refinery29 attempted to emulate it!
Pre Emulation, 2014
In 2014 prior to emulate Spotify, Refinery29 Product and Engineering was organized in a blend of functional and matrix org style.
Each group had team leads and each group had directors whom reported to the CTO. Not fully cross functional and teams were small. Some teams were team of 2, boundaries of some of the teams are not super clear leading into lot of unintentional toe stepping, back and forth to address these conflicts.
We weren’t executing as fast and teams couldn’t run effectively on their own. What do we do? What can we do?
Post Emulation, 2015
Hey, I heard about Spotify, read the papers, saw some presentations, and consulting company we brought in talked about it with us. Spotify could be our solution, let’s try it. Emulation started around January of the year and it happened quickly at a snap of a finger. At a certain date that is now long lost in passage of time, everyone moved their desks into their new squads and chapter. By the time I joined Refinery29 in late 2015, here is what it looked like.
Squads were formed with long living missions such as surfacing of content, international expansion. Chapters were formed around domain knowledge area. We had chapter leads, product owners, cross functional squads to deliver our missions. With this we should be able to execute faster right? So what went awry?
Things that went awry
Squads and chapters wasn’t thought through thoroughly enough to have factored in real world scenarios. If Dash, homegrown CMS goes down or we need to do some major overhaul of CMS platform itself. Who owns that work? Who owns it now? Did we agree to split that up amongst squads that have CMS chapter members and carve off part of capacity? If that’s the case, who coordinates and keeps all the spread out CMS chapter members aligned?
How big should chapters be? Instead of two API chapters, we had an API chapter composed of 10–12 people across at least 4 squads. Chapter leads were setup in difficult position to nurture their people. How could you effectively focus on nurturing and servant lead when you have 10–12 people spread across at least 4 different squads that you know little about. Not to mention some folks are completely remote. Is this individual a seasoned manager who can handle that size of direct reports? Throw in the unbalance ratio of junior to senior engineer ratio and we got a hot mess in our hands.
List goes on and on. How could this be?! We read the white paper, we talked to consultants about Agile, gave titles like Chapter Lead, Agile Coach to people. We even brought on couple people from Spotify?! Is it because those two people aren’t Swedes? Do we need to hire Swedish Spotifers? Should we ask our ex-Spotifiers to change their names to Anders? Joakim?
Why did it go awry?
We missed on why we wanted to emulate Spotify. We wanted to execute more effectively and deliver . There are many ways to execute more effectively. Instead of finding right question to ask, we solved for the wrong question.
What we should’ve taken away from Scaling Agile @ Spotify is inspiration and not a blind emulation. Scaling Agile at Spotify is unique journey Spotify has undergone and will continue to be. I urge you to get inspired, take elements from it, and make your own journey.
Assess your needs, wants, strengths, weaknesses, and be brutally honest. Even if you are an inspired company, have millions of dollars perhaps billions at disposal, many people with Swedish names…real world is messy. Timebox, inspect and adapt methodically to see its progressing.
Where are we now?
We’ve stopped our emulation of Spotify in Q1 of 2016 and gradually transitioned to start our own unique journey we called New World Order at the time.
Instead of squads and chapters, we slowly reorganized into 3 primary verticals which own its own long living missions that support our business. Within each verticals a pool of talented people are self-organizing on needed basis to execute on projects that each vertical takes on. To scale, as we gain a long living missions that has crisp clarity and makes sense, we’ll build out another vertical team methodically and steadily.
The transition itself took many conversations for alignment and series of small incremental steps over many weeks, months to get to where we are now. We still have a long road ahead of us but its our journey! So far it seems to be working better for us than what we had previously. But we’re taking lesson we learned to heart and are trying to revisit how we are doing periodically to inspect and adapt methodically.
I hope our story gave you some food for thought of your own journey of your company. Thanks for reading.