Tribe-Squad-Chapter 2.0 – Chapters in a Service Oriented Organization

The famous Spotify Tribe-Squad-Chapter model inspired countless organizations across the globe to shape their organizational structure. The most revolutionary idea in this model was the chapter concept; it takes hierarchical setup (line management) away from the team or squad and makes it horizontal across the squads, thus a truly flat organization culture. The two most prominent (and revolutionary) changes it brings are

Better autonomy with group-of-equals by design

• The model ensures no hierarchical relationship between three roles (Scrum Master, Product Owner, and Team Members) – or all three are hierarchy equal within a squad. And it’s happening beyond the philosophical level, rather by design.

Overcoming hidden anti-patters of a performance review

• In the cases where team leaders are line managers, the performance evolutions are biased toward the project contribution and often ignore holistic skill development aspect. A person treated like a superhero in a project or team suddenly becomes redundant or liability when moved out of that team (since over the years, only that team/project-specific skill needs were valued and encouraged) …, it ends up creating skill-debt for the organization.
• The core focus of a chapter is the overall skill, competency, and career growth of chapter members beyond current team contribution. [contribution and performance in the team are essential, but it’s not the only criteria]. Also, the chapter lead doesn’t behave like a boss rather a servant leader, facilitating the chapter objective.
• Better empathy and compassion – as by design the chapter lead herself/himself must be playing the role of chapter member (chapter lead is never 100% role), so a chapter lead has a better understanding of day-to-day aspects of that role. {e,g. in a chapter of Business Analysts (BA), the chapter lead must actively be working as a BA}

With all these great things, the chapter is indeed one of the most revolutionary ideas around the people aspect in agile way of working, and many organizations benefited from it. [Except for those who use chapter name (or even structure) but chapter leads continue to behave like traditional people managers]

A big challenge however is HOW TO CARVE CHAPTER IN A SERVICE ORIENTED ORGANIZATION. Let’s look at this issue in depth

The image-1 below is showing the chapter setup in the Spotify model, this model works very well for product or delivery-oriented organizations. All squad within a tribe would potentially have common skill-role such as Business Analysts, Java developers, UI developers, UX, Designer, Tester so on and so forth. Irrespective of the squad may be working on different aspects of a product or maybe on completely different projects, the skill group (e.g. reacy.js developers) can be common in all, thus it’s both wise and easy to set up a chapter.

However, the same setup cannot be applied in the service-oriented organization such as cyber security or IT infrastructure, where Tribes and squads are organized around services such as Identity and access management, CICD pipeline, Product monitoring, Firewall, Window OS, Network, etc., etc. There is practically no possibility of having a common skill role across squads (until a squad is too big to call a single squad or have multiple sub-squads). The nature of skill and work of an ops engineer in the CICD squad would be completely different from an ops engineer in the Linux OS squad.

Leaders and organizations are struggling to find a chapter-like solution for service-oriented organizations, and in absence of a chapter, it creates the following challenges

• Who will lead the pack or who will be the line manager? And with an intuitive judgment, some organizations go for the Product Owner (PO) playing a double role of PO and Team lead; some go for the Scrum Master (SM) playing this dual role and in some cases a separate person playing team leaders.
• In all three scenarios, there would be a hierarchical relation between PO-SM-Team members; thus a hindrance to self-organization and agility at large.
• It also creates work overload on the person playing this dual role.

These challenges can be resolved with thoughtful design of the chapter, as shown in image-2 below

• There would be a chapter of Product Owners and a chapter of Scrum Masters similar to the Spotify model (horizontal ones).
• Each squad (organized around a service) is kind of a chapter in itself – going with three roles (PO, SM, Team member) ideology, the third role can be considered as a common skill-role within the squad thus a chapter in itself. And a person from this chapter would be playing the dual role of team member and chapter lead.
• This will create hierarchal independence between the three roles. And each can focus on their part autonomously.
• All the chapter leads with Tribe will be reporting to the Tribe lead. In other words, there would be a chapter of chapter leads. And the Tribe lead would be the chapter lead of that uber chapter.
• A couple of extremely important points (critical for the success of this model)

1. As stated earlier, the chapter lead should not behave like a boss, rather a servant leader facilitating chapter objective and members skill, competency, and career growth.
2. A chapter should not interfere in delivery aspects. All the Tribe level delivery / backlog / ceremonies such as PO sync or Scrum of scrums etc. should continue to be managed and participated by the Product Owners, Scrum Masters, and key members. Change in line management (org chart) should not influence the role of PO, SM and Tribe lead from backlog management and agile ceremonies standpoint.

I struggled with this challenge of a “meaningful chapter setup in service organizations” for many years. I feel I have the answer now, and sharing it with joy to all of you, with the hope that it may equally inspire and help you to design your chapter structure.