Agile Transformation: Chapters & Chapter Leads

This will make more sense to folks who are familiar with the Spotify model (even though Spotify themselves like to point out that there is no ‘Spotify model’ per se); but I wanted to talk a little about Chapters and the role of the Chapter Lead.

For those who are unfamiliar, I’ll introduce you to the concept of a Chapter. But first, let’s recall what existed prior; folks within a given role (e.g. a Data Engineer) typically are part of a Data Engineering team who report to a Data Engineering Team Lead / Manager (i.e. they are typically siloed). However, in the agile world, teams are composed of folks with a wide range of skills (i.e. ideally all the skills needed to deliver their work), any given Data Engineer might be part of a team with folks performing different roles, and may even be the only Data Engineer within that team.

This means that there’s plenty of opportunity for that person to become isolated from / disconnected to their core discipline and fellow practitioners.

Therefore a Chapter is a construct designed to provide all the benefits of a formerly siloed structure (i.e. keeping folks connected with their core discipline – focused on learning and development), but also supports some important agile principles and practices (i.e. facilitating self-organising, cross-functional teams).

And, of course, a Chapter Lead is the individual who leads any given Chapter – often with similar line management responsibilities you saw in the siloed structure (e.g. approving leave, performance management, professional development, etc.).

But Chapters are so much more than a convenient method of having someone approve your leave when working in a cross functional team. Chapters are intended to collectively help chapter members:

• achieve ‘mastery’ in their given discipline
• understand ’how’ to do their work to a high standard

You’ll notice I used the word ‘collectively’; as it’s not necessarily solely for the Chapter Lead to decide everything, but create a dynamic learning environment where chapters thrive and members are helped to achieve mastery and excellence in their field.

But in large organisations, Chapters can still be quite small units. To continue with the previous example, you won’t typically have every Data Engineer reporting to the one Lead. So multiple Chapters need to exist.

But then, how do you ensure each Chapter doesn’t become disconnected / isolated? That’s where a Chapter of Chapters (CoC) comes in; as a useful mechanism for Data Engineers to stay connected and work towards mastery across the entire organisation.

Note that in this context a CoC is different to a Guild – which is less formal and tends to act more as a ‘community of interest’, or similar.

Add your thoughts or comments on what you’ve seen work well (or not) with Chapters & CoCs.