This continues the story from Towards Spotify’s Tribes: the second month…
Recap
- Scaling up rapidly from 15 Engineers, forecast 2x–3x growth per year
- 3–6 months ago we decided to adopt “autonomous teams” at cultural level, Tribes at company level, and Scrum at team level
- First two months focussed on: practical learnings from Autonomous Teams (“managerless”), and: give teams the chance to try most of Scrum’s artifacts without being dogmatic about doing Scrum itself
A busy month
This month we launched our flagship product. It went well, everyone did a great job. We also launched a decentralized internal Roadmap for product development, easing a switch to having multiple Tribes.
Our Engineering group was growing fast through hiring, and boosted by the “Autonomous Teams” ethos (which caused people from other disciplines to agglomerate into the new, cross-functional, teams). There are two problems that kept popping up:
- We were approaching the upper limit for efficient team-to-team communication. As an exceptionally innovative product company, redefining an industry, we couldn’t afford to bog-down our comms.
- As a growing, ambitious, startup we were desperate to parallelize, and stop being constrained to having only one cross-functional initiative at a time.
Some concrete examples:
How many sprinting teams can do their per-sprint demo on a frequent (weekly/fortnightly) cycle to each other before the meeting breaks the deadly 1.5 hour barrier?
How many sprint-review meetings can stakeholders attend per sprint before it’s too costly — more than half a day of their time?
How many people are in the room for All Hands meetings before you can’t easily hear each other speak due to the distance across the room?
The hardest step: Your second Tribe
As a small company growing into the Tribes model (as opposed to a large company swapping one model for another), moving from zero Tribes to any Tribes is a huge change. You have a tribe already (it’s your entire company; that’s essentially where the Tribes idea came from) but it’s implicit, and the real challenge only kicks in once you have two or more.
Here are a few questions we discovered that were assumed or hidden:
- What (possibly conflicting) responsibilities do teams and individuals have towards: Company vs Founders vs Tribe vs Teams?
- What reporting is part of the Tribe, vs what is part of the employee’s job? e.g. Do all-hands meetings still mean the whole company, or only the Tribe? Do we need two streams of “all hands” meetings now?
- What functions (HR? Finance?) are shared across all Tribes, and what functions are separated per-Tribe (HR? Budgets?)?
- What are the responsibilities of a Tribe Lead that are the same as a Founders, and what are separated? Even with a single responsibility, is it performed differently by a Tribe Lead?
- When is a Founder acting as a Founder vs as a Tribe Lead?
Driving without a Roadmap
For historical reasons (our startup was founded to solve some huge Engineering challenges) our company had no dedicated Product roles when we started. Testing the waters with Scrum, and then trying to switch to Tribes, shone a bright light on this gap.
We aggressively sought out a potential company-wide Product Manager, did many hiring interviews, engaged expert Product Manager consultants, but when we didn’t find the right people we wanted, we had to move forwards anyway.
During the previous months (month 1 and 2), we elevated a few self-selected Engineers to trainee Product Owners (in the Scrum sense). I used training materials from Scrum to up-skill these people, planning to move to Scrum eventually.
But we had no Product Roadmap, and no-one with the time and training to create one. To date, the Founders constantly act as interpreters and broadcasters for the vision they’d started with, but with 30+ people to get it out to, that wasn’t scalable. Normally I’d throw this problem to a Head of Product, or CPO, but we didn’t have one (yet). Several people internally tried to make coherent roadmaps, but found the scale of the problem overwhelming.
Eventually, we adopted a process along the lines of OKRs. The Founders provided:
- A couple of sentences to define the goal of each Quarter
- A couple of key metrics for the Quarter
- Three named Tribes each with a purpose defined relative to the above
…and the teams in turn provided:
- A short phrase and a longer sentence to define the team’s overall purpose
- (for half the teams): A monthly metric for the team
- (for the other half): A 3-word phrase of goals every 2 or 3 months
Lesson 1: Company-wide Communication failed subtly but early
We temporarily shut down the Scrum-like Sprints to make way for planning and implementing the split to multiple Tribes — because it was going to take “weeks, not days” to plan. With hindsight, that wasn’t communicated clearly enough to the teams (saying it in the regular all-hands meeting isn’t enough; at 40 staff, many people aren’t in that meeting, and with something this new and upheaving, it usually takes multiple re-tellings for everyone to get it).
Lesson 2: De-centralizing the Roadmap without Product people is hugely time consuming
It worked, but it required a Founder to devote weeks to nothing but shepherding the process. So much was being discussed and planned during this time that teams who started early — who thought they understood their position in context with the other teams — quickly found everything had changed around them, and had to do a second round of planning.
Lesson 3: People quickly embrace Autonomy once they have it
During the confusion and communication dip described above, many people feared that the Autonomous Teams experiment was being shutdown. After a few weeks of this, an initiative was started by a handful of staff to “Save our Autonomous Teams”. One of the original goals of the Founders was to empower, unblock, and push their staff to be more independent and more bold, and this definitely fulfilled that.
Lesson 4: Cross-functional teams are hard outside of Product Development
Our Engineering teams have embraced it and are taking advantage of the autonomy they’ve been given. People and teams are seeing unowned problems or opportunities, and making them happen, on average more than one a week.
The commercial (Sales, Marketing) teams looking over at their peers in Engineering wanted in on this too, and I was tasked with figuring out how and why it had taken root so quickly in Engineering, and trying to replicate it.
How do you kickstart cross-functional, agile, scrum-like, autonomy in a non-product (e.g. Sales, Marketing, HR) team?
Most obvious answers come back to things that are tied to Product Development, and a “Product-Delivery” ethos. Without continuously generating shippable increments, and milestoned achievements that monotonically improve what’s in the wild, a lot of the rules of thumb break down.
(ultimately, I think we came closest with Customer Development and Customer Success teams that we setup later on. Looking back, I think these exist in the border between Sales/Marketing and Product/Development, maybe explaining why they were easier to get traction with than pure Sales or Marketing teams)
Lesson 5: Scaling the 1-to-1 meetings
With meticulous scheduling and delegation I’ve been grown my fortnightly 1-to-1 meetings to circa 20 staff while continuing my day-job. But we’re at 40 staff total, and doing that many meeting would be a full-time job. So we’ve started experimenting with different ways of scaling this.
One of our Engineering team started his own initiative (autonomous teams are great!) to run 4-person off-site group sessions, with himself as Chair/Facilitator. We found that these overlapped with the 1-to-1s in a positive way, taking some of the pressure off, and increasing the extent to which people felt able to solve problems themselves.
I’m also optimistic that a move to multiple Tribes might make the problem go away. I’ve been looking at having the leaders of each Tribe commit to slightly formalised 1-on-1s with their team, with tracking to check the meetings are happening etc, splitting them across the Tribe Leaders (some companies use only one Tribe Lead; others (like Spotify) have up to three people sharing the role). That’s de-facto what we’ve been doing to date, with our (implicit) 1-tribe model.
Continued in part 4: “Starting Spotify Tribes: Month 4”…
