Running Chapters for Craft Excellence

Set up and run chapters, the groups of same-skill specialists in a tribe, so people keep learning their craft and line management is settled.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

A chapter is the group of people with the same skill inside a tribe: all the backend engineers, all the web developers, or all the testers, even though each of them works in a different squad. Chapters are the horizontal line in the Spotify model. Squads decide what to build; chapters help people build it well.

The 2012 paper by Kniberg and Ivarsson calls the chapter "your small family of people having similar skills and working within the same general competency area, within the same tribe". Each chapter meets regularly to discuss its area of expertise and its specific challenges. The chapter lead is the line manager for chapter members, with the traditional responsibilities of developing people and setting salaries, and is also part of a squad, which keeps them in touch with day-to-day work.

Chapters are also a main target of criticism. Jeremiah Lee, writing about his time at Spotify, argues that chapter-based management of engineers left the product owner without an engineering peer and left no single person accountable for a squad's delivery (Lee, Spotify's Failed #SquadGoals). He quotes former agile coach Joakim Sundén describing chapter leads as servant-leaders who "don't have really any accountability for the delivery". Anyone running chapters needs an answer to that problem.

This skill covers both halves: making a chapter valuable for craft, and deciding the management design deliberately. The output is a chapter charter that names the members, the lead and the lead's responsibilities, the craft standards the chapter maintains, the meeting rhythm, and a written rule for resolving conflicts between a squad's needs and a person's growth.

How It Works

The paper describes the chapter as one axis of a matrix "weighted towards delivery" (Kniberg and Ivarsson). People spend most of their time in their squad, which decides what to build. The chapter is for sharing knowledge, tools and code, and the chapter lead's job is to facilitate and support that. The paper borrows Mary and Tom Poppendieck's "professor and entrepreneur" model: the product owner is the entrepreneur who wants to move fast, the chapter lead is the professor who wants things built properly, and the tension between them is meant to be healthy.

That tension only stays healthy if the roles are clear. There are two common designs. In the first, the one the paper describes, the chapter lead is the line manager: they run one-on-ones, career development and pay, and they work in a squad themselves. In the second, line management sits somewhere else, often with an engineering manager for each squad or group of squads, and the chapter lead is a craft lead without direct reports. Atlassian's summary describes chapters as typically led by a senior technology lead "who may also be the manager" (Atlassian), so both designs are in use.

The first design gives engineers a manager who understands their craft and lets them move between squads without changing manager. Lee's account is that the second benefit was small at Spotify because teams were long-lived, and the first came at the cost of delivery accountability. The second design fixes accountability but asks more of the chapter lead's influence, since they cannot rely on formal authority.

Whichever design you choose, the chapter's craft work looks similar. Members agree on a small number of baseline standards, review each other's significant design decisions, mentor newer members, and bring back what they learn from other chapters and guilds. At Spotify, squads were typically led by a product owner, a technical or chapter lead and an agile coach working together, which puts the craft perspective inside each squad's leadership (InfoQ).

Chapters are small and local by design, which separates them from guilds. The paper says chapters are always local to a tribe while a guild usually cuts across the whole organization, and that a guild often includes all the chapters in its area plus anyone else who wants to join. If a craft topic needs the whole company, it belongs in a guild.

Step-by-Step Guide

Step 1: Identify chapter boundaries within the tribe

List the skills present across the tribe's squads and count the people with each. Form a chapter where several people share a skill and would benefit from a common practice. Where a skill has only one or two people in the tribe, point them to the relevant company-wide guild instead of creating a very small chapter. Expect uneven distribution; the paper notes some squads have lots of web developers and some have none.

Step 2: Decide the management design

Choose whether the chapter lead is also the line manager, as in the original paper, or whether line management sits elsewhere. Write down who is accountable for each squad's delivery under your choice, because that is the gap Lee's critique identifies. Tell every chapter member who their manager is and why. Do this before appointing leads, since the choice changes who is a good lead.

Step 3: Appoint chapter leads

Pick leads who are respected practitioners in the craft and good at developing people. Keep them working in a squad for part of their time, which the paper treats as the way a chapter lead stays in touch with reality. Limit how many people each lead supports so that one-on-ones and reviews actually happen. Make the role visible so squads know who to ask about craft questions.

Step 4: Write the chapter charter

Record the chapter's members, its lead and the lead's responsibilities, the standards it maintains, and how it meets. Add a conflict rule: day-to-day priorities come from the squad and its product owner, while the chapter lead owns growth, craft quality and signs of overload. Name who decides when the two disagree. Keep the charter to a page and review it each quarter.

Step 5: Agree a small set of craft standards

Choose the few practices every member follows, such as code review expectations, testing norms or accessibility checks. Write each one down with its reasoning and an example. Leave everything else to squads, since squads choose their own ways of working. Revisit standards when the chapter sees repeated problems that a standard would have prevented.

Step 6: Set a meeting rhythm with a standing agenda

Meet regularly, as the paper describes chapters doing, to discuss the craft and specific challenges. A useful standing agenda has a short round of what each member is working on, one deeper topic such as a design review or a new tool, and any decisions on standards. Rotate who brings the deep topic. Cancel meetings that have no topic rather than holding them for form.

Step 7: Build mentoring and growth into the chapter

Pair newer members with experienced ones, and use the chapter to calibrate expectations for each level of seniority. Tie career conversations to observed craft work rather than to squad output alone, since the squad's results depend on many people. If the chapter lead is the line manager, use chapter reviews as input to performance conversations. If not, give the line manager a structured view from the chapter.

Step 8: Review the chapter each quarter

Ask members whether the chapter helps them do better work and grow, and whether they would miss it. Check whether squads find the chapter's standards useful or an obstacle. Look at whether any conflicts between squads and the chapter went unresolved. Adjust the charter, the standards or the management design based on what you learn.

Best Practices

• Keep the chapter lead in a squad for part of their time. The paper's reasoning is that daily work keeps the lead's advice grounded in real constraints.
• Settle delivery accountability before launch. Lee's critique is that without one engineering manager per team, disagreements had to escalate to several managers at once; decide who owns delivery in your design.
• Keep standards few. Squads choose their own way of working in this model, so a chapter that tries to standardize everything will be ignored or resented.
• Use chapters for real review. A chapter that only exchanges status updates adds a meeting without improving the craft; design reviews and pairing change how people work.
• Point sparse skills to guilds. One designer in a tribe gets more from a company-wide design guild than from a chapter of one.
• Measure chapter health by asking members. As the squad health check does for squads, a short conversation about whether the chapter helps is more useful than attendance numbers.

Common Mistakes

• Leaving the management design implicit: When nobody knows whether the chapter lead or someone else is the manager, people get conflicting direction. Decide and write it down.
• Turning chapters into functional departments: If the chapter lead assigns people to work or pools them for projects, the model has reverted to a traditional matrix. The paper describes Spotify rarely pooling people this way.
• Chapter leads with too many reports: A lead who also works in a squad cannot support a large chapter well. Split the chapter or add a second lead.
• Standards imposed without explanation: Rules without reasons get worked around. Write the reasoning for each standard and invite challenge.
• Ignoring the squad's delivery needs: A chapter that schedules craft work without regard to squad commitments creates the pull in two directions critics describe. Agree priorities with product owners.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: The Spotify Model

Related Skills

• Building Guilds for Cross-Tribe Knowledge Sharing
• Organizing Squads into Tribes for Alignment
• Forming Autonomous Squads with Clear Missions
• Balancing Squad Autonomy with Organizational Alignment
• Evaluating Spotify Model Tradeoffs and Failure Modes
• Adapting the Spotify Model to Your Organization
• Scaling Agile with Spotify Squads and Tribes

Sources

• Henrik Kniberg and Anders Ivarsson: Scaling Agile @ Spotify (2012)
• Jeremiah Lee: Spotify's Failed #SquadGoals
• Atlassian: Discover the Spotify model
• InfoQ: Don't Copy the Spotify Model
• Spotify Engineering: Squad Health Check model

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.