Tribes, Squads, Chapters…What’s with the “new” lingo?
Having worked for four companies so far that implemented (or at least tried to implement) the Spotify model, I thought I’d share my thoughts with you on the subject.
Some 5 years back, during my MBA study year at Cass Business school (what now seems a very distant memory) I happened to be at a dinner organized by the university where Aviva’s former CEO, Andrew Moss, was our guest. God, how excited I was, dining with the big cheese! I even shared it on Facebook, you know…back then it was “the cool thing”. At the dinner, Andrew Moss announced a speech he had prepared where he mentioned how honored he was to dine with prospective MBA graduates, and also that he really liked our diverse professional background. In some cases, he said, he found our job titles to be somewhat amusing such as “Scrum Master!” he shouted in a big roomful of students, staff, and guests. “What is a Scrum Master? Does it have to do something with American football?” he said humorously. I wondered to myself, “How do I describe this role to a CEO?”, and then I lift my hand up and said, “well, you know… it’s another title for a Project Manager…”. I knew I was the only one (maybe ever) Scrum Master in the MBA cohort. Also, from experience talking to non-Agile related people, I knew that this reply would definitely save me all the hustle of explaining what Agile is! After all, it was 2015, who wouldn’t know what a Project Manager is? Five years later, I like to think that the title of the Scrum Master is well established and you are aware of it (at least its existence!). If you’re not, and haven’t been living in a cave, I’d suggest you go and Google it right now.
In 2020, a similar conversation would go like this:
-So, I joined this new company and I work for the Global Payments Tribe where I…
-Wait, what? You work for a… TRIBE? Haha! Hilarious mate! What is this, some Xulu thing? Or a cult?
-No no, you see a Tribe is like a business cluster, and it has a Tribe Lead, various Area Leads…
-A Tribe…LEAD? Haha, like a witch doctor?
-Again noooo… think of a Tribe Lead like a mini CEO. In the Tribe, we have all the components and people we need to get the job done and…
-Then why the hell would you name it a Tribe?
…and here I am, explaining things…again…Do you see the pattern here?
A couple of years back, in 2018, I was part of ING’s massive Agile Transformation where they introduced Tribes across the whole organization. Teams were now named “Squads”, and the notion of “Chapters” was introduced. This was the “Spotify model” that would later spark a whole debate as to whether “Spotify” is a product or a model. I wouldn’t vouch for it but I think it’s the former. (By the way, I have zero issues with the naming convention “Spotify model” since I often hear the “Uber model”, the “Google model” or the “Amazon model”. We refer to them as examples of their successful business, operational, monetization, organization, etc.)
I was familiar with the Spotify model since I’ve seen it laying around in forums and social media, but not that familiar. Make no mistake, this model wasn’t news, it was firstly introduced in 2012! Also, I was surprised to find out that since Spotify’s CEO and Facebook’s CEO were buddies, Spotify was inspired by Facebook to create its organization model! So, it wasn’t really the Spotify model, it was rather the Facebook attitude: “Move fast and break things” [1]
However, lately, and as the industry is sometimes slow to catch up, I find that this model has started to become the norm, so where we previously had teams, now we have Squads. Where we previously had business units now, we have Tribes. And where we previously had line managers now, sometimes, we have chapter leads (which by the way is not a very good implementation of the intended role of the Chapter Lead).
Which begs the question, are we thirsty to copy (successful) organizational models because we put our trust in the way they seem to be functioning? I remember hearing the Director of a big TelCo I worked for saying that “We want to be the Google and Facebook of TelCo” (that’s for another story!).
At first sight, the reasons for adopting a different terminology could be something similar to these:
- Act like one to be like one: Maybe a deep belief that if we organize ourselves similarly to a successful company, we’ll be like that company.
- Acknowledgment of success: We acknowledge that Spotify is a successful company (hey, they’re making a few bucks, aren’t they?), so what they’ve done with their organizational structure must be good.
- Fun: Do you know where else we find the terms squad, guild etc? Games. So, one potential reason is that this naming convention sounds more playful, fun even, you could say.
But why bother with changing the terminology? What’s so ill-fated with calling a team, well…a team? If we trace Agile back to its roots, a team was always meant to be a collection of cross-functional people that collaboratively work towards a common goal. What’s wrong with that? Or is it that lately (20 years), a team has been consisting of one type of roles, typically micro-managed with a very narrow (if any) room for self-management or autonomy, and by the term squad we tried to put under the rug that bad state and forget about it? “A squad is autonomous, self-organizing and self-managing”. Luckily, this coincides nicely with the original intentions of Agile, autonomy, self-organization, and self-management. If you’re not doing these, it doesn’t matter if you name your team “Super Mario”, it will always be a non-autonomous, non-self-organizing, and non-self-managing.
An agile organization doesn’t deliver work according to a classic organization chart; rather, it can be thought of as a series of cells (or “teams,” “squads,” or “pools”) grouped around common missions, often called “tribes.” [2]
That was McKinsey’s original term for a Tribe. Granted, it took Spotify’s terminology and vision, repackaged it, made a few things explicit, and sold it to companies like ING as a blueprint.
I think at the heart of implementing the Spotify model is the notion of a flat organization. In other words, we could simply say a “flattened business unit” or “flat organizational structure”. Instead, we refer to it as a “Tribe”. Some people get confused by the term “flattened”, they don’t really understand how it works. Well, it’s quite simple: we remove the layers. We make leadership (not management, different things) accessible to everyone, and everyone accessible to the leadership. Management doesn’t really add to the layering, it’s mostly there for everyday stuff such as holidays, sick days, and maybe personal conflicts. Other than that, leadership exists to set the vision and the strategy, and everyone else works together towards achieving that. Also, Chapters are there to make sure they look after employees’ craftmanship and knowledge expansion.
If you prefer to talk numbers, in a flat organization I would expect to have 2 layers: leadership, and everyone else. In a traditional organization, we can have as many layers as we like, each layer subsequently managing, or being managed by another. Sometimes, these layers exist merely to justify pay rises e.g. in order for a senior development manager to receive a pay rise, since there isn’t a position in the company that justifies a higher pay, we make one up, thus making him “more senior” than others, and thus giving him more power and adding an extra layer to the hierarchy.
The Spotify model has indeed received some first-class bashing for being frivolous from people like Jeremiah Lee who has worked for a short period of 7 months as a Product Manager. I’m sure people have their reasons for doing so, for example, to drag attention or to declare their frustration, but the bottom line is that we should take a model as exactly that: a model; not a lift-and-shift-expecting-to-work-out-of-the-box-from-day-one thing. I am not supporting that models are holy grails, but they do give you a baseline from where you can work yourself upwards.
For me the key takeaways from the Spotify model are these:
- Create a flat structure and make Leadership accessible to everyone. Doing this brings unity in the Tribe and the feeling that “we’re all in this together” (see Gemba walks).
- Try to create a Supporting Structure instead of a Reporting Structure
- Focus on the product not the process (processophilia)
- Increase collaboration by including the people who need to work together in the same Tribe
- Promote openness, because how else are we going to co-create this product?
- Enable swifter feedback, since we’re all in the same Tribe and can closely inspect other people’s work
- Promote customer engagement since customers are the actual consumers of our product
A business will always be a business, will always have to work within its certain constraints, will always have deadlines, interdependencies and tight budgets. The key is to be able to adapt within these constraints and to be able to do the best you can within these constraints. No, you won’t be an Agile powerhouse or create an exemplar, but at least you could try to experiment with incremental work, quicker releases and focus on the value that matters to your end consumer. That’s the true, pragmatic approach when you are running a business.
And hey, in the end, any model will be what you make out of it, either you call it Spotify, Google or Donald Trump, it doesn’t really matter. What matters is the appetite to promote good values that resonate with your employees and keep your customers happy.
[1] Joakim Sundén https://vimeo.com/240125835
[2] https://www.mckinsey.com/business-functions/organization/our-insights/the-journey-to-an-agile-organization#
