This continues the story from Towards Tribes: Month 3…
Following the groups laid out in the Roadmap from Month 3, we now have two mini-Tribes of 15–20 people each, and a third “placeholder” Tribe for the teams that didn’t neatly fit into either main Tribe.
Most of our learnings this month were about Roadmaps and the nature of development at early-stage companies. For me there was nothing new here — it’s standard stuff for anyone who deals regularly with Product Development (whether on the Product side or the Developer side). Also, I was spending a lot of my time on a separate initiative — working closely with a few Sales, Marketing, and Engineering people to kickstart a new Customer Development (Lean Startup) team.
The Tribes-specific stuff is going to be brief…
Lesson 1: Choose your Tribes to be in tension with one another
Our two main Tribes were defined by a single sentence each — but those sentences were intrinsically in opposition. One Tribe was working to reduce variation and rate-of-changes (in order to increase predictability, throughput, stability), while the other was working to add product features and innovation (to increase utility to customers, and increase the addressable market).
I spoke to a few CTO/VP Engineering people about this, who’d done Tribes before at medium and large scale. Overall, they felt it was a good thing, with one person suggested that it may even be essential to the long-term success of the model.
My understanding: Tribes are hugely autonomous but each Tribe isn’t the sole source of revenue or development, which causes a tendency over time to stagnate and/or veer off-course, without the normal company corrective forces of sales targets or delivery dates.
Tension between Tribes strongly counteracts this, creating a situation where Tribes continuously hold each other accountable, as if in a tug-of-war. If Tribe A stops holding Tribe B accountable, B pulls ahead and inherently/accidentally pushes A behind. This in turn directly increases the pressure on A to question what B is doing and why.
This isn’t the only way to provide course-corrective pressures and incentives (and I’m working on the assumption that you have a healthy company culture where this pressure never becomes overbearing), but it seems a strong and simple one to create and maintain.
Lesson 2: A Roadmap should not be a reporting structure
I generally use roadmaps for two things: communicating from “vision holders” to “people who will realise the vision”, and for doing strategic “what if?” planning. Further down the line, they are also a useful starting-point for Product Owners to build their own detailed plans, and for Sales teams to provide simplified (and sanitized) public roadmaps for customers.
We used the new roadmap like that. But we also tried using it in the opposite direction. It seemed a good way to maintain coherence while we had 2–3 Tribes all forging new paths. I think that caused us (collectively) to put a lot of the wrong things in there, and later to ask the wrong questions, while providing true but unhelpful answers.
Why did we do this? We didn’t start off with all the specialist people/roles we needed, so we had to compromise a little and (temporarily) adapt.
Tribe structure
We tried to give each team a Product Owner, but we didn’t have enough trained POs to go round, we had no trained Agile Coaches (a.k.a. Scrum Masters), and we no Tribe Leads. Trying to switch over to a new org structure while also actively growing into it, and doing that fast, isn’t easy.
The plan was to hire and/or internally source Tribe Leads within a month. On the PO side, I started aggressively hiring for two new POs, while self-selecting Engineers stepped in to most of the vacant PO roles and we (myself and the two already-trained POs) provided some very light touch on-the-job training.
Continued in Part 5: Tribes in Practice…
