The Sound of Remote Collaboration: Autonomous Squads

The recent Spotify x Joe Rogan deal made one thing clear: Spotify is going for gold of the podcasting industry. While the company’s chain of acquisitions is part of a well-thought-out business model, the Swedish music streaming service didn’t start as the most orderly bunch. Back in 2012, Spotify sported an experimental and highly volatile organizational approach that came to be known as the “Spotify model.”

In today’s article, we’re taking a closer look at the company’s early engineering culture and its Agile heritage. We also find out if it’s possible (and reasonable) to use the principles of the model to create autonomous and flexible “Remote Squads“, a robust, fully distributed version of Scrum teams.

If you’re wondering:

• 👉 What is the Spotify model?
• 👉 How does it work?
• 👉 How is it is different from Scrum?
• 👉 Is it still relevant in 2020?

You’re in the right place. But before you dig into the goodies, be sure to read our previous article—“Remote Scrum 101: Agile across Time Zones”— to catch up on some of the Agile and Scrum concepts we’ve already covered. 

🥊 Agile vs. Scrum

Yes, we know that the following information may be basic knowledge for anybody who’s ever dabbled in Scrum, but we feel a short explanation is in order. Consider yourself warned. 

There’s a fairly widespread misconception that Scrum and Agile are standalone concepts. Worse still, the two are often juxtaposed as if teams had to choose one or the other. 

Not even close. So, what is scrum exactly?

Scrum is a process framework that helps businesses and organizations coordinate complex, multi-layered projects. Agile, on the other hand, is an approach to software development (and project management) that combines a number of methodologies, Scrum being one of them.

In other words, teams *can* follow Agile principles (see the Agile Manifesto), but they *don’t* have to do so through Scrum. Scrum is just one of the possible implementations of Agile and there are a number of alternative frameworks like Kanban or Extreme Programming (XP). 

As part of the Agile family, Scrum uses an incremental, iterative approach to project management that has been successfully applied in a wide range of industries, including IT, education, automotive and manufacturing.

Instead of tackling big projects in one go, Scrum breaks complex tasks into smaller, more manageable chunks. Not only does this approach help adapt to changing circumstances or shifting project requirements, but it also minimizes the risk of derailing a project when something goes wrong. 

🎧 So, What Is the Spotify Model? 

In 2012, Henrik Kniberg, then Spotify Agile coach, shared an interesting peek into Spotify’s engineering culture. In a document titled “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds,” he outlined the company’s creative take on software development. 

Although Spotify started as a Scrum company, it eventually decided to ditch *most* of the Scrum practices and adopt a much more flexible approach to building and managing teams. While the new philosophy still centered around Agile principles, it was largely experimental.

A visualization of Spotify’s early engineering culture via Henrik Kniberg

Long story short, the document (followed by two videos) garnered significant attention, so much so that other businesses started implementing the approach on their own playgrounds. Eventually, the concept grew into what some call the Spotify model.  

Here’s a wee disclaimer. Despite the name, the Spotify model isn’t really a “model.” Neither is it a framework or set methodology. As Kniberg clarifies in another blog post:

“I’ve spent a few years working with Spotify and published a few things that have gained a surprising amount of attention – especially the scaling agile article and Spotify engineering culture video. This has come to be known as the “Spotify Model” in the agile world, although it wasn’t actually intended to be a generic framework or “model” at all. it’s just an example of how one company works.”

Henrik Kniberg

Although Kniberg tried to clear up the confusion, the name stuck. And since nobody has come up with anything more accurate, we’ll continue to use the name throughout the article. Hope you don’t mind!

🤔 How Does the Spotify Model Work?

Since the model has deep Scrum roots, it follows the tenets of the Agile manifesto, at least to a degree. But that’s not all. On top of the Agile principles, it also introduces a number of unique tweaks that make it stand out from other, more rigid approaches to software development and team management.

At the most basic level, the Spotify model:

• 🤝 Puts team culture first. Tools and processes are important, but people and company culture come first. You can’t build a great product or service without the two. Although the model emphasizes autonomy, nobody is left behind or without proper support
• 🙋‍♂️ Fosters transparency, communication and trust. Teamwork can only happen when these three values are present, both vertically (management) and horizontally (across individual teams). There’s no place for politics, finger-pointing or fear of failure
• 👩‍🔬 Encourages experimentation. The Spotify model doesn’t limit or prescribe tools,  methodologies and strategies. Teams can decide how to get work done. While the model rejects conventional Scrum practices, it doesn’t prohibit using them where appropriate
• 🤷‍♂️ Embraces failure. Failure is an important part of the process. By accepting the possibility of failure, teams can get more creative and find non-linear solutions to problems. Instead of blaming each other, employees reflect on mistakes and work together to prevent them in the future
• ⚖️ Balances autonomy and alignment. Too much control over employees borders on micromanaging, and nobody likes that. Too little control means that teams may drift away from the company-wide mission. The Spotify model seeks a balance between the two
• 👨‍🎨 Promotes originality and innovation. Teams bound by rigid processes and bureaucracy have limited capacity for creativity. That’s why the model rewards original ideas and encourages employees to seek innovation

But the changes don’t end there. 

Autonomous squads embracing Agile principles via Spotify

1. Squads, Chapters and Guilds

The first major difference between the Spotify model and Scrum is the way employees are grouped into teams. Traditional scrum teams are replaced with squads, self-contained and autonomous units of up to 8 employees. 

As described in the original document:

“A squad is a small, cross-functional, self-organizing team. Usually less than 8 people. They sit together and they have end-to-end responsibility for the stuff they build – design, commit, deploy, maintenance, operations; the whole thing.”

In terms of the actual workload, the changes are mostly cosmetic. Each squad is responsible for their own slice of the pie and hones in on a particular feature or part of the product. Squads have the freedom to decide what they want o build and how they’re going to accomplish that. 

Next on, the Spotify model renames the function of the Scrum Master into an Agile Coach. While both are similar in terms of responsibilities, Kniberg reasons that “servant leaders” are more desirable than “process masters.” The new function also emphasizes the importance of Agile principles. 

Tribes, chapter and guilds via Spotify

Individual squids are bundled into tribes of fewer than 100 members. All squads within a tribe work on a specific group of products or services. For instance, one tribe may focus on UI while another could tackle AI-powered analytics.

The model also introduces the concept of chapters which are essential skills-based units that group employees with similar expertise. While squads are organized around diversification of talent (cross-functional), chapters are homogenous in terms of individual employees’ skills.

Last but not least, guilds are informal structures build around areas of interest or specific topics. A guild is “an organic community of interest where people across the whole company gather and share knowledge within a specific area. For example leadership, web development, or continuous delivery.”

2. Release Trains and Feature Toggles

When it comes to shipping the actual products/projects, the Spotify model, like Scrum, favors frequent, incremental release cycles that are more flexible and easier to deliver. The model follows the Scaled Agile Framework (SAFe) and ships using Release Trains, bits of the product that depart weekly or every two/three weeks.  

Parts of the code that haven’t been finished when a release train departs are shipped too, except they’re hidden using feature toggles (feature flags). Feature toggles let developers deactivate unfinished bits of code so they still end up in the rollout but aren’t visible or usable by end-users.

Autonomy simplifies teamwork via Spotify

3. The Next Level of Autonomy

Scrum Teams are already pretty independent in terms of how they organize and tackle work, but the Spotify model takes autonomy to the next level. 

As Kniberg puts it:

“(…) autonomy makes us fast, by letting decisions happen locally in the squad instead of via a bunch of managers and committees. It helps us minimize handoffs and waiting, so we can scale without getting bogged down with dependencies and coordination.”

But autonomy is not enough to warrant the quality of delivery. That’s why the model balances autonomy and alignment so teams have the freedom to experiment with workflows while staying in line with company-wide mission and principles.

4. Organic Innovation

The Spotify model fosters innovation. But not only the kind of innovation that sprouts during brainstorming sessions and hours spent in meeting rooms. It propagates *organic* innovation that happens when people can people follow their passion and cultivate interests. 

Back when the model became popular, Spotify allowed employees to spend 10% of their total work time experimenting during hack days and hack weeks. They could use that time to create pet projects, brainstorm product features or dabble in any type of creative work. 

The company would also run biannual hack weeks where all employees would get together to create cool things. The “usability” of those experiments wasn’t as important as generating fresh, non-linear ideas. While some could end up as shippable products, there’s no real pressure here.

5. Limiting the Fallout

Experimentation often leads to unpredictable results so the model comes with safeguards against having “too much of a good thing.” To keep the product safe and prevent the whole system from going offline due to programming mistakes, the model uses what Kniberg calls “limited blast radius.”

Updates and new features aren’t shipped to all customers all at once. Instead, only a fraction of users, usually geographically limited, get early-bird updates that are rolled out gradually. This way teams can A/B-test and gather feedback before shipping to the entire user base. 

By limiting the repercussions of deploying faulty code, teams can get more creative with the features they deliver. A solid idea that’s quickly implemented is better than a great idea that never sees closure.

6. Remixing Teams

The concept of a “team” isn’t a constant in the Spotify model. Everything that happens around squads, chapters and guilds is dynamic and there’s a continuous flow of talent between each of these structures. 

As Kevin Goldsmith, former VP of Engineering at Spotify, observes: 

“We focused on building full-stack, autonomous teams, built around a single, clear, mission. The expectation is that once the team’s mission has been fulfilled that it will dissolve.”

In that sense, the model makes it possible to reorganize both vertically and horizontally depending on the changing circumstances and project requirements. That is as long as there’s a strong community and internal culture that keeps everything together (more on that in a bit). 

❌ Is the Spotify Model Broken?

One of the reasons why many companies try tried to copycat the model was the alluring perspective of an Agile Utopia it seemed to offer. Self-organizing teams that need little to no supervision are a dream come true for managers across the board.  

The thing is, Spotify’s early engineering culture was built by trial and error. That’s why most of the premises of the model are purely empirical and have very little well-substantiated theory behind them. Even if the model did *seem* to work for Spotify, at least in the beginning, it’s not a formula that could be repurposed and replicated anywhere else. 

Spotify didn’t implement the Spotify model by copying Spotify. Why do folks at other companies think they can implement the Spotify model by copying Spotify?

— Kent Beck (@KentBeck) May 25, 2018

But there are other reasons.

• 🤯 It’s an Agile wilderness rather than a utopia. A degree of autonomy *is* important, but how do you make sure everybody does what they’re supposed to when they’re supposed to do it if the chain of command is weak or constantly fluctuating?
• 🏚 It’s a relic of the past. Many advocates of the Spotify model forget that the original document was published back in 2012 when the company was still in its infancy days. Since then, Spotify has pivoted away toward a more formal and structured approach to building and managing teams
• 🤝 It’s merged with company culture. Every company blends in a unique composition of mission, values and processes that are the core of its internal culture. It’s difficult, if not impossible, to replicate these elements in the exact proportions. And since the Spotify model builds on company culture, it has slim chances of working anywhere else

So, given all the shortcomings, the big question you’re probably asking yourself is: “Does the model make any sense today?” The short answer is (*drumrolls*) YES, but not in the exact form it was originally implemented at Spotify.

✅ Why the Spotify Model Is Still Worth a Shot

“Since then, many companies have been “copying” the Spotify model, which I found rather scary at first. But now I’ve met quite a number of those companies (and heard back from even more), and so far I have yet to see a case where a company ended up in a worse position than where they were. In fact, some have seen some huge improvements!”

Henrik Kniberg

Let’s make one thing clear: Copying the model 1:1 isn’t going to work when separated from Spotify’s unique internal culture. But drawing inspiration from it… that’s a completely different story.

Even if your business is not into software development, the model offers a number of unique benefits that are out of reach for more traditional approaches to building and managing teams.

It’s biggest strengths?

• 🐝 Cross-pollination. Many organizations struggle to populate values, processes and ideas globally, across their structure. While some teams may stick to one, prescribed toolset or framework, for others it may not be the optimal solution. In the Spotify model, everything spreads organically, both vertically (across the organization) and horizontally (between teams). If something works well for one squad, it gets picked up by the rest
• 👮‍♂️ Bureaucracy vs. flexibility. The Spotify model helps draw (or find) the fine line between structured, organized team management and autonomy. Teams that have a certain degree of flexibility in terms of what they work on and how they deliver that work build up their internal decision-making superpowers. In most cases, that means less supervision needed and more headspace for the managers
• 🦺 Safety first. With all the experimentation and innovation going on, the Spotify model is pretty safe when it comes to making mistakes. As an Agile/Scrum offshoot, the model unfolds projects in incremental, bite-sized bits that prevent any large-scale blowbacks

🤔 And What About “Remote Squads?”

As you can see, the Spotify model has its moments. But what would happen if we looked at it from the perspective of remote work? Would it make sense to adopt this largely experimental approach in fully distributed teams? What are the potential benefits?

Managing distributed teams is tough, especially when employees are spread all over the globe and span several time zones. But if remote teams could prioritize work, track progress and solve most of the day-to-day problems on their own… that would be a managerial dream come true.

Considering how important autonomy was for the original Spotify squads, the concept of independent Remote Squads seem to make perfect sense. Small, self-contained units of less than 10 people could be truly agile in terms of self-organizing work without direct, centralized supervision.

But that’s not all.

• 💪 Remote squads focus on collaboration. On the one hand, the Spotify model aims at independent, self-contained teams. On the other, it emphasizes the importance of creativity, experimentation and free flow of ideas. If you couldn’t get your remote employees to regularly communicate with their peers (and enjoy it), the culture of experimentation where teams tag along to create cool things may be just the thing you need
• 🏉 Remote squads aren’t limited by structures. Unlike traditional, siloed teams with a tight chain of command, remote squads are mercurial in nature. Talent flow happens organically and employees are allowed to pursue all kinds of projects. When squads collaborate remotely, their members can contribute expertise across a number of projects and hone their skills in the process
• 🧰 Remote squads experiment with tools and processes. Frameworks like Scrum are overly prescriptive. The workflows are linear, predictable and adhere to a certain pattern that doesn’t change much between iterations. The Spotify model, on the other hand, embraces experimentation. Remote Squads can decide what to work on next and what tools they want to use. This, in turn, makes it easier to proof workflows against time-zone differences, delayed feedback or miscommunication

🐑 Autonomous Remote Squads in Taskade

1. Your First Remote Squad

Assembling a Remote Squad in Taskade is simple. All you have to do is create a Workspace, Subspace or Project and invite people to collaborate. You can send invites via email, by entering a username or through a simple link.

Each new member can be granted a specific level of access:

• 👩‍💻 Admin — Can fully configure and edit projects, templates, and manage projects and workspace settings
• ✍️ Editor — Can create and edit projects, templates in the workspace. Cannot manage projects or workspace setting
• 🤓 Viewer — Can only comment and chat in projects. Cannot create or edit projects, templates in the workspace

It’s that simple!

2. Virtual Meeting Room and Digital Whiteboard

Effective, frictionless collaboration is a challenge for many distributed and co-located teams. Whether it’s because of time-zone differences, inefficient communication tools or lack of camaraderie among employees, it’s impossible to build flexible and autonomous remote squads without putting trust, communication and transparency first.

For that reason, every remote squad should have a dedicated collaboration space that enables a frictionless exchange of information and flow of ideas. In Taskade, your team can use the limitless real estate of virtual meeting rooms and digital whiteboards to brainstorm ideas, engage in meaningful discussions and get work done.  

Taskade is a virtual meeting room, collaborative white board, and a communication platform.

3. Sandbox Workflows

The Spotify model is all about *choice*. Instead of following a prescriptive framework or methodology, remote squads can embrace experimentation and put together a unique process that feels the most natural for the type of work they’re dealing with.  

• 👉 Which tool is better for this project?
• 👉 Should we use Scrum or Kanban to organize work?
• 👉 How should we communicate?
• 👉 When is the best time to run meetups?

At Taskade, we believe that squads should be able to design their workflows from the ground up. Every Project, Workspace and Subspace can be sandboxed and customized. It’s up to the individual squad to decide how they want to communicate, visualize projects or customize workspaces for optimal productivity. 

4. Progress Visualization

The Spotify model does stem from Agile/Scrum and as such is best for handling projects in increments. But sometimes it’s not possible or practical to break big projects into chunks. And when that does happen, your squad should be able to clearly visualize the progress they make and keep individual milestones in view. 

Thanks to the Roadmap feature, Taskade lets your squad keep track of all kinds of projects, big and small. Every task, goal or milestone with a fixed deadline can be positioned on a timeline so it’s much easier to plan ahead. 

Schedule work, track progress and measure performance.

5. Customizable Templates

Starting new projects feels like a chore?

It doesn’t have to.

Taskade comes packed with dozens of free, customizable templates you can use to start-up projects in no time.

Depending on your squad’s preference and project requirements, you can cherry-pick from categories like:

🛠 Engineering

• 👉 Programmer’s Productivity Checklist
• 👉 Quality Assurance (QA) Testing
• 👉 Front-End Checklist

🤝 Meetings

• 👉 Team Agenda
• 👉 Meeting Topics Queue
• 👉 Remote Team Meeting Agenda

🎯 Roadmap

• 👉 Product Release Roadmap for Remote Teams
• 👉 Sprint Roadmap

And many more… just look at handy this Sprint Roadmap. Isn’t it great? 👇

💡 Conclusion

As more companies are moving away from the traditional on-site model and romancing with remote work, managers and business owners are looking for *no-nonsense* ways to balance autonomy and alignment in their ranks. Creating autonomous remote squads seems like a good start.

While the Spotify model is technically a relic from the past (with so-so reputation), it does offer an interesting take on the way we think about building and managing teams. It’s unlikely that you’ll be able to replicate Spotify’s success by following in its footsteps, but you may learn how to build a great team that’ll consistently deliver.

---

And much more…