a.k.a:
Converting a 20-person, autonomous, functional/siloed, Engineering-heavy Startup into an effective, cross-functional, 50-person company, using Spotify’s Tribes model.
Quick links:
Spotify’s Tribes model?
A quick outline of the core concepts — as we understood them— is here: “London tries Spotify’s Tribes”
Documenting the Journey
Over the course of half a year, I wrote monthly articles on the main challenges and learnings we had with the Tribes model. Getting this to work, and work well, is a highly iterative process. Looking back, I have polished answers to many questions — but those answers emerged from the specifics of our situation and our experiences along the way. Your organization needs to find the answers that work for you.
By writing it as we went along, I hope to better explain “how” to start the journey, or “how” we dealt with the setup, the early days, etc. Followers can’t jump to our endpoint, since they need to iterate and tweak the way to theirs. Documenting our journey is one way I can make it easier: you can start from where we started, and then craft your own journey from there.
The People…
There’s a long list of people I credit with the success of this, from the people who published their own experiences at Spotify and elsewhere, .. to those outside the org who kindly gave us their experiences and advice .. to those within our teams who went above-and-beyond to make sure it worked out well.
Outside the company, special thanks go to: David Morgantini, Keith Mitchell, Paul Egan, Timothy Kimball, and all the people who came along to the first London Spotify-Tribes-Model Unconference.
5 months before starting
The company was still transitioning from “research-oriented: projects are done when they’re done” to “product-oriented: projects have to be delivered in some kind of working form at a set date”.
The process we’d evolved was known as Gates. Development would generally move forwards without any long term planning, and milestones would be vaguely offered and often slipped or redefined completely (to match reality: prediction of delivery dates was almost impossible). But when a delivery was especially needed — e.g. to have something to show to partners, customers — a Gate would be created.
The head of engineering — one of the company founders — would bring the whole engineering team together for a week to focus on the problems at hand and all outstanding features. Then he would work with the teams to define delivery schedules for all of them on a set timeframe (typically a month or few). Gantt charts would be built. Specification docs would be written. The big push would begin, towards delivering the promised features for that Gate.
2 months before starting
Several teams desperately wanted and needed longer term planning, and the obvious first step was to bring in some Project Mangers, Engineering Managers, or other kind of line-management (with a team of 5–10 direct reports, we’d need 2–3 immediately). It seemed a good idea at the time.
I realised we needed a new approach when I tried to hire our first Engineering Manager (job spec went live 14th November 2018).
Through standard recruiting approaches I had our first 10 qualified candidates the next day, and phone screened them over the days that followed. A recurring theme was that we needed something no-one was really in a position to provide: we wanted a manager who wouldn’t attempt to “manage” anyone.
I saw clearly that we had classic problems caused by lack of any Product person (PM, PO, etc) — and lack of Engineering Managers. No prioritization was happening. Task planning was limited — globally — to a week or two if you were very lucky. Everything was ad-hoc, chaotic, and stressful.
As I talked through some of this in more detail with a Founder, he talked about his desire to one day achieve “truly, fully, cross-functional teams — e.g. sales and marketing people embedded in every software team”, and I realised that what both he wanted, and the teams wanted, was a way to manage work and people without having managers.
1 month before starting
With the direction clear, we agreed to run ahead with “eventually”, but to make it “this year” or even “now”. The Founders started a series of weekly all-hands meetings where they presented the company culture they wanted both now and in future, and why, and hosted long debates with all staff on what this might mean, how to achieve it, and improvements/changes the staff wanted.
In parallel, I picked a starting point for what we wanted: at small scale, I knew we’d want something very similar to Scrum. At large scale, Spotify’s 2012 Tribes model seemed less obvious but pretty close — it uses Scrum for the individual teams, and provides a largely Manager-less corporate structure that they scaled to 1000+ headcount. We’d have to create our own version, but it gave me shared vocab for speaking to other people, and for analysing what had been tried by others. I reached out to my network and found some former Spotify staff, and many people who had already tried the model in their own companies (headcounts from 10s to 1000s). I interviewed each of them, trying to learn as much as possible about the good, bad, and their suggestions for improvements.
I started calling it a “managerless” structure (with air-quotes) and created a slide deck to communicate the driving forces from the business (SCALING! … and a desired Culture), the roles of Managers, and our ideas on providing all those roles without creating (even by accident) Managers within the org.
My early fears were about Leadership (critical to fast growth startups in my experience) and Career Progression (hilighted by a couple of team members, and at first a big worry of mine). I knew communication would be absolutely overwhelmingly critical: cultural change always requires this, and creating a new kind of culture even more so.
And … GO!
Coincidentally the wider business hit a critical point where we needed to refocus most of the engineering teams onto one aspect of our product — this had become the critical path for the launch event that would be the peak of the last 5 years of work.
The Founder who lead the engineering side of the company chose this as the moment to put the whole re-organization into play. It would simultaneously allow us to refocus more people onto a small number of problems, and be a small, time-boxable test-bed for our ability as an org, and as individuals, to try the new ways of working.
(up to this point we were limited by the vertical specializations of teams — cross functional teams would be less efficient per person, but increase the productivity/delivery rate per product)
In the spirit of one of our new company principles — Fail Fast! — he announced it “effective immediately” :). We weren’t ready! Most of the plan existed in two people’s heads — his and mine. But (like being a parent for the first time): you’ll never be “ready”, you need to just go for it.
By this point, I’d dropped the “managerless” nomenclature, in favour of a more nuanced understanding (c.f. the “How to have Managers in a Managerless Org?” presentation).
Week 0: What we didn’t do
Pair Programming? Nice idea, no time to consider if good or bad for us; impossible to introduce to a Manufacturing + Workshop + Hardware + Software (+ Sales + Marketing) company — only makes sense for ONE of those nouns.
CPO / Product Manager? Too late; after 2 years of failed hiring attempts, and 3 months of more intense hiring attempts, even if they arrived tomorrow they wouldn’t have time to write the Product roadmap, Vision, etc that we need immediately — we’d be flying without them anyway, so adding them today adds little or nothing. We’ve got to find a way without them either way.
Many other great ideas? No time; and teams already about to be put under considerable cognitive load to simultaneously adopt wholly new practices, clean-up/refactor some not-great habits they’d developed, and finally: pull each other along at the same time because some teams had never even heard of the concepts before.
Weeks 1 and 2: Communicate, Communicate, Communicate
We communicated the changes to the Engineering division as a whole in two all-hands meetings, one for the Founders’ 1-year view of “why” we needed to change. The other, a few days later, for the operational changes, suggested practical details (still high-level!), and a focus on the cultural background and reasons. We worried a lot about making sure everyone had time between meetings to digest the info, to feedback problems and concerns, to add their own ideas and choose to adopt / engage with the changes.
In weeks 1 and 2, my office-hours doubled. Most of that was unscheduled meetings to bring individuals up to speed, spread across as many disparate teams and functions as possible. It felt like driving a train at full speed, with a crane overhead laying track in front of the wheels just in time. My own focus was to educate people on the meaning behind “Teams, not People”; from prior experience, this and “responsibility matches authority” were the two hardest-to-digest and most critical concepts for people to understand and embrace.
With hindsight, these meetings (I wasn’t the only one doing them) were probably more valuable than all the other things we worried about. They provided safe environments for people to criticise and kick the tyres, giving them much more confidence to commit themselves and engage. But they also created the first wave of believers in the new system, people who — in the weeks that followed — became exemplars for their teams, showing them how to adopt the new structure and how to thrive in it.
Based on the first few days of high-importance concerns and issues raised by the team, I wrote a 3-page manifesto/pitch explaining the cultural aspects and purpose (and the biggest challenges) and why the company had chosen now to do something so risky and innovative. Two of the 1-on-1 meetings lead to people asking for a FAQ (so they wrote one! And we shared it with everyone).
(Briefly: we’re inspired by Spotify’s Tribes (giving people something they could google for much more detailed info/discussion), but adapted to our unique culture; we’re doubling-down on our cultural goals; we’re knowingly accepting some increased costs in return for the benefits; and … we’re decentralizing both decision-making and responsibility)
It was only half-planned, but we were already laying the strong structures for the month to follow: If you see an opportunity or problem, raise it publicly, then take ownership of fixing it.
Weeks 3 and 4: Backfilling the critical pieces
This part I’m writing up 4 weeks in arrears, and looking back it’s stunning quite how much happened how quickly. In my mind, I felt we’d spent almost a month doing the things of weeks 1 and 2, and another month doing week 3.
We launched without Chapters (although one of the most senior Engineers had identified a long-list of fears and challenges that would cause us a lot of harm, and which Chapters would almost completely solve).
We launched without ScrumMasters/AgileCoaches, and with zero teams that had ever done Scrum before (1 in 3 had done “ScrumBut…” before).
We didn’t know what “Done” meant.
1/3 of teams had never used JIRA, 1/3 had barely used it at all. All now had to use it together, in the same way, to facilitate people moving between teams.
Our people did an amazing job of coping with huge change in very short time, of pro-actively trusting each other, and enthusiastically engaging with a rush of new concepts.
We ran workshops on “What is a User Story”, we created short checklists of the meetings that teams should have each Sprint (and 2-sentence guides to what each meeting was for). We kicked-around a lot of ideas about how to move communication from 1-to-1 (old way) to team-to-team (new way).
But ultimately, the biggest win here was Sprint Demos. (A month later, the individual feedback from Engineering has been unanimous delight with the Demos and what it did for inter-team communication.) I couldn’t get buy-in for Sprint Reviews at first (legitimate concerns over time-cost, distraction, etc), but Demos were easier to introduce and explain.
And a quick shout-out to Founders Factory, whose demo format I shamelessly copied (ahem; was inspired by): we pulled in our Sales and Marketing teams, and got them to help us turn the Demos into a celebration from day 1. As a team we’d had a history of being too humble about accomplishments, of focussing on our failures and letting our successes slide by with barely a nod. We set out to change that.
Continued in part 2: “Towards Spotify’s Tribes: the second month”
