We Started Spotify Tribes last month, so what happened next? Mostly we focussed on product and company challenges (Tribes were a means to an end), so there wasn’t much time available to do more than see how Tribes progressed on their own, and make corrective actions later.
Lesson 1: Hire at scale if you want to build at scale
The previous month I talked about the gap between the set of specialist roles we now needed (in the Tribes model) and the talented people we already had. We approached this as something we could recruit for piece-meal: one person focussed on Tribe Leads, a small team focussed on Product Owners, and Agile Coaches were initially ignored because of budget constraints (and the perception that we probably would be OK without them).
It turns out: as with traditional Scrum, although some roles seem almost trivial, Tribes needs all the key roles to be in place simultaneously in order for the approach to work at all.
We should have treated it like hiring an entire company/team from scratch. When I worked in the videogames industry we often went from 0 to 60 with very little notice: a project would suddenly be “greenlit” with the budget jumping overnight from $250k … to $10million, or $25million, or even more. This led to a standard practice of insta-hiring 20–30x specialist roles at once, in parallel, since you needed a substantial team running at once for any of them can get any meaningful work done.
Switching to Tribes felt quite similar to that, with a similar core equation (figures for illustrative purposes only; varies by project and team complexity):
Until you hire c. 95% of your final team, the team you have is capped at c. 15% of total output
e.g. even when you’ve hired 3/4 of the people, and you’re paying 3/4 of your budget every month … you’re still only getting 1/5 of what you’re paying for!
This is not how hiring in Statups and SMEs normally works, and I think the mindset of “MVP” and Lean Startup can easily catch people out here. Tribes is more like large-scale org/team recruitment, and requires a more enterprisey, “simultaneous, highly co-ordinated”, hiring approach.
Lesson 2: Nearly-flat org structures have extra urgent need for Career Progression docs
In theory, we had a flat structure of cross-functional teams. Within each team, we had a Product Owner who was no more or less than the other team members, but merely a specialised role within the team. Attached to each group of teams (say: one for every 5 teams) were a few extra roles: Tribe Leads, Head of (or VP of) Engineering/Marketing/Product/etc. Potentially (depending on how you do Tribes) there would also be senior but non-managerial discipline experts (within Chapters, and/or within Guilds, and/or floating among Tribes).
In practice … we had a flat structure of cross-functional teams, with Product Owners taking on nearly all the responsibilities of co-ordination and planning, up to and including the work of Tribe Leads.
But “Horror Vacui” (“nature abhors a vacuum”): With no Career Progression Framework in place, anyone who wanted to advance in their career started to see the Product Owner roles as the only way to progress their salary, seniority, career, etc.
I’d recommend simply taking Monzo’s open-source framework (it’s on Github!), fork it, make any obvious tweaks needed to fit your org, and then start using it, warts and all. Simply update it week to week as and when people identify problems.
Lesson 3: Before switching to multiple Tribes, re-title someone as Tribe Leader
Going to multiple Tribes was confusing enough; doing it when a lot of people in the company didn’t know what a Tribe “is” (in a day-to-day, visceral, sense) was asking a lot; possibly too much. In particular, the organization needs to get a feel for what the Tribe leadership does and how it works (whether you choose to have one Tribe Lead, or to have multiple leading roles working together).
It will still be difficult for the TL to transition once you go to multiple Tribes, because they’ll go from owning “everything” to owning “only what’s in my Tribe, and having to discuss the rest with some peers”. That’s hard for them and for everyone else. But at least it sets expectations early and gives teams time to practice it.
It’ll feel weird and clunky, but it lets your org divide-and-conquer a large problem space, instead of trying to change/solve/fix everything at once.
Lesson 4: Aggressively use 1-to-1s and group Cultural Onboarding sessions
I mentioned in Month 2 that we’d started doing “Cultural Onboarding” sessions for cohorts of new joiners (typically 4–6 staff at a time, a few weeks after they joined the company), and that this helped them adapt to our highly “autonomous” culture.
But as we transitioned to Tribes, those onboarding sessions also became a convenient place to air (and answer) some of the confusions and concerns about how Tribes work on a individual level. Similarly with the 1-to-1 meetings, and I modified the script for these meetings to specifically ask people how their experience of Tribes was going, prompting lots of feedback and airing of problems we could then act upon.
Lesson 5: Define one or more “Social Contracts” / Charters between teams and key roles
With hindsight, our entire system of autonomous teams relied upon a custom Social Contract (although we never called it that) between the Founders and the Employees. We documented it, within presentation slides, and as notes to the slides — but I believe it would have worked better if we’d elevated the status a bit. A lot of the teething problems we had with Tribes grew into much bigger problems because of confusion over what individuals had a right to expect/demand of each other, and what they should/should not be promising to others.
Some recurring examples:
- What authority does a Product Owner have? And what independence does their team have? Where do the PO’s responsibilities start, and where do they end?
- What problems will the Tribe Lead solve, what will they leave to the teams, what will they leave to the POs, what will they leave to the supporting Tribe leadership (if you have any)?
- What limits and guard-rails do the Tribe, and the Tribe leaders in particular, place on the autonomy of the teams? What promises do the teams and individuals make to the Tribe and to the Tribe leaders that go above and beyond what exists in a non-Tribes structure?
Continued in Part 6: Leading Spotify Tribes…
