After Month 5’s Tribes in Practice, Month 6 was mostly about adaptation.
It’s all about the Tribe Leaders…
Two months into running our proto-Tribes we still had no Tribe Leaders. There is very little published about how/when/who to make Tribe Leaders in the Spotify model, and it’s one of the biggest un-documented questions I noticed a year ago when I was researching Tribes:
“I’m looking into the Spotify model in detail at the moment, and noticed that info is thin on the ground about the larger-scale items: good and bad practices for Tribes, gotchas and guides for Tribe Leads, etc. … do you know anyone who’d be willing to chat about their experiences?” — me, 2018
It was obvious from the moment our Tribes went live that the quality of the Tribe Lead(s) would be enormously influential on the success or failure of each Tribe, and probably of the company itself. There was a lot of fear and caution from the very top people in the company about picking the “wrong” people for the roles. In a largely autonomous organization, these individuals would be the most significant exceptions to the “everyone’s equal” rule, while also wielding enormous power and influence.
But without active TL’s, the Tribe concept kept breaking down.
VISION: You cannot have a decentralized project plan without clear local vision holders who constantly refine and interpret the vision for the teams, and keep them aligned with that vision. Our autonomous structure was inherently dependent upon TLs to do this interpretation (flowing down from Founders) and alignment (flowing up from teams).
CONTEXTUAL ACCOUNTABILITY: teams and individuals could hold each other accountable, but no-one had the perspective and motivation to hold people accountable to higher-level concepts and needs. Where larger initiatives needed the collaboration of 3, 4, or even 5 teams there was immediate drift on the shared goals, as the teams’ own goals pulled the group away from the initial need. No-one was watching out for that or correcting it — only TLs would have had the combination of: visibility, time, and motivation to do this.
SUPPORTING INDIVIDUALS: We had a brilliant but inexperienced set of Product Owners (PO) — each was highly experienced in their own fields, but they were all new to the PO role itself. This meant that a lot of issues came up where the POs weren’t sure how to react or handle it, weren’t sure what was appropriate — and here they should have had direct backup and intervention from the missing TLs.
MAKING TEAMS THRIVE: Less obviously related, the communication between teams stumbled. Communication overall was still good — and person-to-person communication great — but team-to-team communication dropped significantly, and no one person seemed able to pull it back to where we need. Partly that’s inevitable from the rapid growth of the company (doubling in size every 8 months), but with hindsight it was clear that TLs would probably have helped significantly.
We’re a company that celebrates and promotes Autonomy, so … what did we do?
Adaptation: Product Owners as “Acting Tribe-Leads”
The Product Owners stepped into the vacuums created by the missing TL’s, each in their own way. Mostly they fell-back on their own habitual ways of project-managing or organizing teams.
Some devolved the organizational work, creating “sub-teams” of 2 people in each team, so that they could remain PO’s, but their team shared the burdens of project-management.
Some acted more like TLs, not only pro-actively “adopting” multiple related teams in parallel (as a PO / Scrum Master hybrid), but further co-ordinating work on the projects of other PO’s teams to fit with their own.
Some even switched to waterfall (with the blessing and buy-in of their teams).
I have huge respect for the tireless work of all the people involved. But I wouldn’t do that again — it places too much on the shoulders of a small number of people, and feels to me like a recipe for burnout.
