Tribes in London
Spotify itself was born in Sweden, and one theory about Tribes is that the model worked so well for them precisely because it fits with Sweden’s unique cultural mindsets. If so, there is a real risk that other nationalities may simply not be able to adopt it. Can we do it elsewhere? What will need to change? What new will we learn?
In London, we have quite a few large startups that have been practicing variants of the Tribes model for years (e.g. Monzo (750 staff), and of course there’s Spotify’s own London office :)), and enough value has been seen that strong interest has spread out to the earlier-stage London tech community (fast growth companies with 50–150 staff), with many such companies adopting the model in recent years. It feels a good time to start taking the lessons learned by both large and small companies in London, analyse it, and promote the results back to the London tech community.
Last month I offered to run a talk devoted to this topic, and within 24 hours had more than 50 CTOs and VPs Engineering ask to come. (In the end, we did a small Unconference, with an audience of 25. It was great, and we’ll be repeating it soon). This is something that London tech startups are clearly strongly interested in!
In feedback from the event, Bimal Shah praised the ad-hoc “Key concepts of Tribes Model in under 5 mins” that Tim Kimball gave at the start (well-volunteered, Tim!), and suggested we make this a regular feature. That inspired me to record and share my own understanding of the model as it stands in mid 2019.
Spotify’s Tribes — Core terminology
These terms are not under debate. These are worth memorising before you try to discuss the model, otherwise you’ll be rapidly confused / confuse others. If I got some wrong, this is the point where you spare my shame and correct me.
Scrum — if you don’t know Scrum inside-out, go learn it first. In my opinion, this is a necessary pre-requisite to have any chance at architecting or leading a Tribes model. You should be adept at selling Scrum to cynics, because you know exactly what “ScrumBut” is, and you can see it a mile off.
Squad — literally: a rename of Scrum Team.
Agile Coach — literally: a rename of Scrum Master (SM had two original meanings, one of them was very much Agile Coach, and “Scrum Coach” would have been a much better name for Scrum Masters, in my opinion).
Product Owner — literally: the same as in Scrum
(project management) — literally: for the individual teams: Scrum
Tribe — a collection of Scrum Teams / Squads, operating as a single business-unit
Chapter — all the people in the company (not limited to a single Tribe) who share a job-title/discipline/function. e.g. “Product Owners”, or e.g. “Front-End Developers”, or e.g. “Growth Marketers”. This is a formal, official group (part of company structure).
Guild — all the people in the company loosely interested in a shared subject (not limited to a single Tribe). This is an informal, semi-unofficial group.
I interviewed Tribes practitioners across London companies from 50 to 5000 employees (most of them in the range 150–500), including some former Spotify employees, and spent 3 months investigating reports of what worked and why. Common themes emerged of items that companies were doing differently vs doing the same.
Spotify’s Tribes — Shared Features
These are the ones almost everyone does the same.
Use Scrum within each team: the model was invented for scaling Scrum, so you should expect the majority of teams to be using Scrum!
Tribes are the size of small (e.g. early SeriesA funded) startups: the model wins the benefits of small company structure by limiting the size of each Tribe
Each Tribe has a unique vision and goal: Each Tribe has a purpose shared by all the Squads (Scrum Teams) within that Tribe. They operate as semi-independent business units
Spotify’s Tribes — Debated Features
Terminology — a lot of companies have ethical concerns about emotionally-loaded terms such as “Tribe” (implies warfare), “Chapter” (implies a religion), and “Guild” (implies commercial protectionism). As a European, I find these terms problematic, and I’m happy to rename them — but they are the words Spotify chose, so for clarity I use them whenever talking about the model with other companies.
Guilds — as a largely informal grouping, a lot of companies (especially the smaller ones — 200 staff or fewer) don’t bother with Guilds. The staff are free to create and run these as they wish, with varying amounts of corporate support provided.
Chapters — it’s confusing to have two managers, two teams, two hierarchies to report to. Most companies use them, but very small companies (100 staff or fewer) often don’t use the Chapters, or use them very lightly. Reasons for not using them, or watering them down, mostly seem to be because it’s a confusing concept: traditional teams and departments become Squads and Tribes, but there’s rarely a direct equivalent of Chapters in the pre-Tribes org structure.
Tribe Leaders — Spotify had three roles leading each Tribe: a “super Product Owner”, a “super Engineer”, and a “general leader” (my summaries). Spotify’s original explanation seemed anaemic to me, and I don’t feel it had enough debate/exploration when the model was published. Unsurprising then that almost every company I’ve spoken to has their own different template for the leaders of a Tribe. Some companies have a single leader. Some have five leaders. Some have a number that is chosen by each Tribe itself.
Chapter Leads — some companies have Chapter Leads and make them Line Managers; all companies I’ve met that grew beyond 250–500 staff formally converted their Chapter Leads into Line Mangers at some point (including Spotify). Some companies have Chapter Leads but they only do people-management. Some companies have them only do project-management. Some have no Chapter Leads (or very loose, informal, leads).
My current preferred version of Tribes
I see each Tribe as a largely autonomous business unit within a company. Each Tribe has to be self-contained — it has its own sales, marketing, design, development — to fulfil a meaningful business-wide vision. Where exceptions and tweaks have to be made to the Tribes Model, I prefer to make them within individual Tribes, encouraging the Tribes themselves to make intelligent decisions about what needs changing for their peculiar circumstances, and trusting them to use that independence wisely.
I see Tribe Leads as almost identical to Google Product Managers — the “mini-CEO of a single Product” — a person who runs all of the financial, product, people of the Tribe and is singularly responsible for delivering an externally-visible outcome, usually a KPI, to the rest of the company (and, specifically, delivering to the actual CEO/board). This — like Scrum and its proactive transparency do on a per-team level — guarantees the CEO and the company the accountability they need that lets them devolve power and autonomy to entire Tribes of teams.
I see a lot of overlap between the Products inside companies like Google that are run by Product Managers … the Projects in Videogame companies that are run by Executive Producers … and Tribes with their Tribe Leads. The frequently-touted benefits of powerful PMs and EPs mirror the benefits of Tribes — but Tribes share the power out more evenly and effectively, leading to more people getting more done, with less Command-and-Control, all-or-nothing, machismo.
I see Chapters as a well-intentioned mistake. A principle of project management (and Scrum!) is to have one person ultimately deciding what work is done / what order. Squads and POs already do this, led by the Tribe leadership — but Chapters muddy the waters by providing a second, out-of-band, work stream that is less visible, less well-managed (doesn’t directly use Scrum), etc. I see Chapters as the opportunity for capturing ideas and work that PO’s and Squads would potentially ignore or forget — but I believe this can be done without turning Chapter Leads into Project Managers and Line Managers.
I see Tribe Leadership (apart from the single Tribe Lead) as VP level people within a company, but semi-coupled to specific Tribes. I see the leadership as an exceptionally powerful opportunity for each Tribe to further customise itself to solving the challenges facing that particular Tribe: one Tribe should have a VP Engineering, another should have a VP Marketing, and a third could have both simultaneously. Depending upon the size of the company and the size of the Tribes, and the experience level of the VPs, I would expect individual VPs to work with anything from a single Tribe through to 4 or 5 Tribes in parallel.
I see Tribes as limited in size to the largest size your Tribe Lead has the skill to run as a single small company without breakdowns in communication, speed, and effectiveness. In practice, this means approximately 40-50 people per Tribe, with Tribes being ineffectual below about 3 squads (20–25 people) because of the overhead added by the Tribe structure, and slow and clunky above about 60 people (approx 10 Squads).
A different take on Tribes?
Please share your own learnings here! I’ll do some followup posts with details of the major changes I’ve seen in how London companies appear to be doing it, but first-hand accounts are much better.
Also … we’ll do another Tribes Unconference soon , and I’m asking the attendees from the first one to add their own perspectives on what is good and bad about the model.
