Tribes, Squads, Chapters, Guild - Who would have thought that these words would be associated with software engineering ?? I'm pretty sure no one did until the team at Spotify released a paper way back in 2012 titled Scaling [email protected] with Tribes, Squads, Chapters & Guild.The paper provided a snapshot of Spotify's way of working that allowed them to scale agile to a large organization. It's almost six years since Spotify engineering released the paper & the Engineering culture video that took the software development world by storm.

My customers often ask me, "Do you do the Spotify model?". Whenever I get this question, I am tempted to tell them "No, 'cause it's not what you think it is". I want to say no because IMHO they are missing the forest for the trees. Before I explain further, let me quickly give you a refresher on the terminologies used in the Spotify paper.

Squad - The mini start-up


A squad is the smallest cross-functional unit that shares the same mission and is considered the basic important building block. Think of it as a self-contained mini-startup and the overarching organization as the incubator. There's no formal squad leader role within a squad, and usually, is led by a product owner with the primary responsibility of prioritization of work. It is important to note that the product owners are NOT involved in how the team delivers their work.

Chapter - Domain Specialists

Chapters & Tribes

A chapter is a specialists group where professionals that specialize in specific domains and share the same responsibilities. The primary objective of the chapter is to reduce the " silo effect" through knowledge sharing and drive personal development. Chapter lead, a servant leader, leads the chapter. The chapter leader's primary goal is to nurture and support the growth of chapter members as individuals and as a group.

Tribe - Cohort of Squads

Tribes are squads that work on similar tasks. Similar to a squad, the tribe is led by a tribal leader whose fundamental responsibility is to ensure that the squads have all the support to be autonomous and successful. Other duties of the tribal leader include managing the budget, the infrastructure et al.

Guild - An open, informal community


A guild is an open, informal community that allows the employees to come together according to their interests. Membership to a guild is open, and anyone can join or leave any guild anytime. Also, there are no restrictions on affiliation with multiple guilds. The guild's principal goal is to enable cross-pollination of ideas, knowledge sharing and nurture cross-domain competencies across tribes.

Alliance - Alignment focussed leadership


Alliance is not distinctly outlined in the original paper. Autonomy is at the core of Spotify's engineering culture. The sole purpose of the alliance leaders is to continually build alignment across the tribes and also ensure that autonomy remains unimpaired.

Now that you've had a quick refresher on terminologies,let me clarify why the question is misplaced.

Anyone that has looked at the organization structure described in the videos and (incorrectly) interpreted that, it is a model to reorganize a good old matrix organization, is entirely missing the point of the paper. So, what are they missing?

Engineering culture and not an organizational structure

The Spotify video title is a dead giveaway. The video shines a light on Spotify's engineering culture and practices. Though they have outlined an organization structure, it is all about their engineering culture underpinned by core principles and assumptions that are not explicitly mentioned but tightly integrated into their ways of working. Marcin Floryan, Team catalyst @ Spotify, in an interview with InfoQ, "There is No Spotify Model" talks about these underpinning principles. The implicit tenets bring us to the other vital points often missed by the misguided proponents of the Spotify model. Let us look at some of them.

Autonomy and trust over control

The core principle that binds and drives the Spotify engineering culture is autonomy. Autonomy is all about empowerment and freedom of choice. But, to make autonomy work, trust has to be established. For example, Spotify allows the developers to deploy any piece of software at any time ( of course with some restrictions).

Does this mean that enterprises that adopt the Spotify ways of working, should give absolute autonomy to their development teams? No,absolutely not ! Spotify's secret sauce is to have purpose driven autonomy supported by the right information. So, before anyone organization wants to get started, it is essential that the organization identifies a definite objective; what they want to achieve, whether the team has access to all the requisite information to make critical decisions and choose whatever helps them reach that purpose.

Autonomy without alignment is futile

Henrik Kniberg’s introduction to Spotify’s Aligned Autonomy suggests, any imbalance between the two dimensions, autonomy and alignment, eventually introduces some rate of failure at scale. Though autonomy focusses on the freedom to act independently, to achieve success, the autonomous team need to align with the broader objectives of the organization. Alignment ensures that the groups share a common goal and drive towards that goal. Thus, striking a balance to operate with autonomy and alignment continually requires significant and continual attention from both teams and leaders.

Innovation over predictability

Traditional organizational approaches and governance models emphasize continuous visibility and predictability. Whereas, Spotify values innovation over predictability focussing on experimentation and delivering value. For successful implementation, an organization must review existing practices and be prepared to re-engineer or do away with anything that stifles innovation.

Failure recovery over failure avoidance

"We aim to make mistakes faster than anyone else — Daniel Ek, Spotify founder."

The Spotify culture is also firmly rooted in the belief that "whoever learns the fastest wins." Their acceptance of failures as a learning opportunity and validation of their learnings reflects that belief. Organizations that are risk averse and goes all out to avoid failure will not be able to achieve any tangible benefits.Thereforce,organizations first need to create a safe environment and welcome failure before embracing Spotify's engineering practices.

Bottomline : It's not a model . Be inspired but do not copy

I think "Spotify Model" just like agile has been caught up by the bandwagon effect and hijacked by the marketing & sales team (ignorant non-practitioners). Many organizations fall for what Marcin Floryan describes as the the "Halo Effect Bias", where you imitate a successful implementation and expect the same results.Obviously, not all of the choices made by Spotify's engineering team will be suitable for every organization. But then, that's not the point. Instead, every organization must carefully examine their organization against the core tenets and implement systems that best suits them.

Marcin Floryan's (Team catalyst @ Spotify) quote from Taiichi Ohno summarizes it all "You have to think for yourself and face your difficulties instead for yourself and face your difficulties instead of trying to borrow your wisdom."


1. Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds -Henrik Kniberg & Anders Ivarsson content/uploads/2012/11/SpotifyScaling.pdf

2. Spotify engineering culture (part 1)

3. Spotify engineering culture (part 2)

4. No, I didn’t invent the Spotify model - by Henrik Kniberg

5. Servant Leadership - Wikipedia

6. There is No Spotify Model

7. Aligned Autonomy

Disclaimer : This post does not represent the thoughts,intentions, plans or strategies of my employer.It is solely my opinion.Feel free to challenge me, disagree with me and share your thoughts in the comments section