Running Chapters to Build Discipline-Specific Excellence Across Tribes, Squads, Chapters, and Guilds
This skill teaches you how to establish and facilitate chapters, the discipline-specific groups that connect specialists across squads within a tribe, so you can standardize craft practices, run effective mentoring, and own career growth paths for your people.
Define each chapter around a single craft discipline like backend engineering or UX design. Appoint a chapter lead who serves as both people manager and craft authority. Hold regular chapter meetings for practice reviews, knowledge sharing, and tooling alignment. Track career growth through structured competency frameworks. Chapters connect specialists scattered across squads so craft standards stay consistent while squad autonomy remains intact.
Outcome: You produce a functioning chapter with a clear charter, a regular cadence of meetings, a shared competency framework, and a mentoring structure that raises craft quality across every squad in the tribe while giving each specialist a defined career growth path.
Prerequisites
- Understanding of the Spotify Squad Model's basic structures (squads, tribes, chapters, guilds)
- An existing tribe with at least 3 squads containing overlapping specialties
- Familiarity with people management fundamentals (1:1s, feedback, career conversations)
- Access to your organization's competency framework or willingness to create one
Overview
Chapters are the organizational glue that keeps craft disciplines strong when specialists are distributed across autonomous squads. In the Spotify Squad Model, each squad owns its mission and operates with high autonomy. That autonomy is powerful for delivery speed, but it creates a real risk: specialists working in isolation, diverging on standards, and losing access to mentorship from peers who share their discipline. Chapters exist to solve this problem. A chapter groups all practitioners of a single craft (say, all iOS engineers or all UX researchers) within one tribe under a shared chapter lead. The chapter lead holds people management responsibility, runs regular craft-focused meetings, and maintains the competency framework that defines what good looks like at each level of seniority.
The concrete artifact you produce by running a chapter well is a living system, not a one-time document. It includes a chapter charter (purpose, scope, membership), a meeting cadence with standing agendas, a competency matrix mapping skills to career levels, a mentoring rotation pairing junior and senior members, and a shared set of craft standards (coding conventions, design principles, testing protocols, or whatever applies to the discipline). When this system works, every specialist in the tribe knows where to go for career guidance, how their work is evaluated, what standards they should follow, and who they can learn from. Quality becomes consistent across squads without requiring a centralized command structure.
The skill sits at the intersection of people management and technical leadership. Unlike forming autonomous squads, which focuses on giving teams clear missions and end-to-end ownership, running chapters is about the horizontal layer that connects people doing similar work. And unlike building guilds, which are voluntary communities of interest spanning the entire organization, chapters are formal, tribe-scoped, and carry real managerial authority. Getting chapters right means your tribe can scale its headcount without degrading craft quality, because every new hire joins a chapter that onboards them into shared standards and pairs them with a mentor from day one.
How It Works
The chapter model works because it separates two concerns that traditional team structures conflate: delivery ownership and craft ownership. In a conventional team, your manager is often the person who assigns your work AND evaluates your craft growth. In a tribes squads chapters guilds structure, the squad owns delivery (what you build and when), and the chapter owns craft (how you build it and how you grow). This separation lets each concern get proper attention. The squad's product owner can focus on user value and delivery cadence. The chapter lead can focus on code quality, design standards, hiring, career progression, and mentorship.
The chapter lead role is the linchpin. This person is not a project manager or scrum master. They are the most experienced practitioner of the discipline within the tribe, AND they carry formal people management responsibilities: conducting 1:1s, writing performance reviews, approving promotions, resolving craft disagreements, and setting hiring standards. This dual role is what gives chapters their authority. A guild facilitator who only convenes optional meetings has no teeth. A chapter lead who owns your career progression has real influence over how you work.
Chapter meetings function differently from squad ceremonies. Squad standups, retrospectives, and planning sessions are about coordinating delivery. Chapter meetings are about raising the bar of the craft itself. A typical chapter meeting might include a code review walkthrough of a recent production incident, a demo of a new testing framework someone adopted, a discussion about whether to standardize on a particular API pattern, or a collaborative review of a junior member's work to calibrate feedback. The cadence is usually biweekly or monthly, not daily. The output is updated standards, shared learnings, and calibrated expectations.
The competency framework is the chapter's most important long-term artifact. It defines what skills and behaviors correspond to each career level (junior, mid, senior, staff, principal, or whatever your ladder uses). Without this framework, promotions become political and inconsistent. With it, every chapter member can self-assess, identify gaps, and work toward the next level with their chapter lead's guidance. The framework also gives the chapter lead a defensible basis for compensation and promotion decisions, which reduces perceived unfairness across squads.
One subtlety that practitioners often miss: chapters should not become bottlenecks for squad decisions. The chapter sets standards and provides guidance, but the squad decides how to apply those standards to their specific context. If a chapter mandates that every service must use a particular database, but a squad has a legitimate technical reason to choose differently, the squad should be able to make that call, document the rationale, and move on. Chapters that become approval gates destroy the autonomy that makes the Spotify Squad Model work in the first place.
Step-by-Step
Step 1: Identify Chapter Boundaries Within Your Tribe
Start by listing every distinct craft discipline represented across your tribe's squads. Pull the roster of each squad and tag each person by their primary discipline: backend engineering, frontend engineering, UX design, data science, QA, product management, etc. Group these tags and count the members in each. A chapter needs at least three members to justify its own structure, and ideally five or more to generate meaningful peer learning.
If a discipline has only one or two practitioners in the tribe, they should join a guild instead (see building guilds) or affiliate with a chapter in an adjacent tribe. Document the final list of chapters you plan to create, along with their initial membership rosters.
Tip: Resist the urge to create micro-chapters for every subspecialty. Having separate chapters for 'React frontend' and 'Angular frontend' when both groups share 80% of their skills fragments the community. Start broad and split later only if the chapter grows past 12-15 members and the subgroups genuinely have divergent practices.
Step 2: Appoint Chapter Leads with Dual Authority
For each chapter, select a lead who combines deep craft expertise with people management capability. The chapter lead must be someone the members respect technically, because their authority over standards and quality comes from demonstrated skill, not organizational hierarchy alone. At the same time, this person needs to handle difficult conversations: underperformance feedback, career disappointments, interpersonal conflicts between chapter members in different squads. Talk to tribe leadership and HR to confirm that the chapter lead will hold formal people management responsibilities, including 1:1s, performance reviews, promotion recommendations, and hiring decisions for their discipline.
If your organization separates technical leadership from people management, you will need to negotiate a hybrid role or accept that the chapter lead role carries less weight.
Tip: The best chapter leads are typically senior individual contributors who want to grow into leadership, not existing managers looking for more reports. Look for people who already informally mentor others and set standards through influence rather than authority.
Step 3: Draft a Chapter Charter
Write a one-page charter for each chapter that covers purpose, scope, membership criteria, and decision rights. ' The scope defines what the chapter owns (craft standards, tooling decisions, hiring bar, career framework) and what it does not own (delivery priorities, sprint commitments, product decisions). Membership criteria state who belongs: typically anyone in the tribe whose primary discipline matches the chapter, including contractors and embedded specialists. , how to implement a specific feature).
Share the draft charter with all prospective members and the tribe lead. Revise based on feedback before publishing it as a living document.
Tip: Include an explicit statement about what the chapter will NOT do. For example: 'This chapter will not approve or block squad architectural decisions. Squads consult the chapter for guidance but retain final decision authority over their own codebases.' This prevents the chapter from becoming a gatekeeping body.
Step 4: Build the Competency Framework
Create a matrix that maps the skills, behaviors, and outputs expected at each career level within the discipline. , technical depth, system design, mentorship, communication, scope of impact). For each cell in the matrix, write two to three concrete indicators that are observable and assessable, not vague aspirations. 'Designs and implements services that handle 10x traffic growth without architectural rework' is useful.
'Demonstrates technical excellence' is not. Validate the framework by asking two or three senior chapter members to independently assess themselves against it, then compare notes to check calibration. If the framework produces wildly different self-assessments from people you consider peers, revise the indicators until they converge. This framework becomes the backbone of every career conversation, promotion case, and hiring rubric in the chapter.
Tip: Borrow from existing public competency frameworks (Rent the Runway's, Etsy's, or CircleCI's engineering ladders are well-documented starting points) and adapt rather than inventing from scratch. Building a framework from zero takes months; adapting one takes days.
Step 5: Establish the Meeting Cadence and Standing Agenda
Set a regular chapter meeting rhythm, biweekly for chapters with 5-10 members, monthly for larger ones. Each meeting needs a standing agenda that balances structured content with open discussion. A proven structure allocates the first 10 minutes to announcements and updates (new hires, tooling changes, upcoming deadlines), the next 20-30 minutes to a prepared topic (a code review, a design critique, a postmortem walkthrough, or a demo of a new technique), and the final 15 minutes to open floor discussion where members raise cross-squad issues or propose changes to standards. Rotate the prepared topic responsibility so every member presents at least once per quarter.
Record decisions and action items in a shared document accessible to the entire tribe. Publish meeting notes within 24 hours so squad members who missed the meeting can stay informed.
Tip: Protect the open floor segment aggressively. It is where the most valuable cross-squad intelligence surfaces: 'We ran into this exact problem in Squad B last month and here is what we learned.' If the prepared topic consistently runs long and eats the open floor, shorten the topic or split sessions.
Step 6: Set Up Mentoring Pairs and Rotation
Pair each junior or mid-level chapter member with a senior member from a different squad. The cross-squad constraint is deliberate: it forces knowledge transfer across team boundaries and gives the mentee exposure to different product domains and codebases. Define a minimum commitment for mentoring: one 30-minute session every two weeks, with a structured agenda that covers recent work review, skill gap identification against the competency framework, and one stretch goal for the coming two weeks. Rotate pairs every quarter so mentees get exposure to multiple perspectives and mentoring styles.
Track active pairs and completion of sessions in a lightweight spreadsheet or wiki page. The chapter lead should review mentoring health monthly by checking completion rates and asking both mentors and mentees for qualitative feedback.
Tip: Do not make mentoring purely voluntary. In voluntary systems, the people who most need mentoring are least likely to ask for it, and the busiest seniors opt out first. Make it a default with an explicit opt-out process that requires a conversation with the chapter lead.
Step 7: Codify and Publish Craft Standards
Translate the chapter's collective expertise into a written set of craft standards that every squad can reference. These are not theoretical ideals. They are concrete, enforceable conventions: naming patterns, code review checklists, design system tokens, testing coverage thresholds, API versioning policies, accessibility audit requirements, or whatever applies to the discipline. Store standards in a location that is accessible during daily work, such as a shared repository, wiki, or handbook.
Each standard should include the rule itself, the rationale behind it, and any known exceptions. Version the standards document and review it quarterly. When a chapter member proposes a change to a standard, it should go through a lightweight RFC process: write the proposal, discuss it at the next chapter meeting, and either adopt, reject, or table for further investigation.
Tip: Start with the five standards that would have prevented your tribe's last three production incidents or quality escalations. This grounds the standards in real pain and gives them immediate credibility, instead of feeling like bureaucratic overhead.
Step 8: Run Quarterly Calibration and Career Reviews
Every quarter, the chapter lead conducts a calibration session with the tribe lead (or a peer chapter lead from an adjacent tribe) to review the progression of each chapter member against the competency framework. Prepare a one-page summary per member that includes their current level, key accomplishments in the quarter, areas for growth, and any promotion considerations. Calibration with a second reviewer prevents grade inflation and ensures consistency across squads. After calibration, the chapter lead holds a 1:1 career review with each member to share feedback, update development goals, and discuss trajectory.
These conversations should reference specific evidence from the competency framework, not vague impressions. Document outcomes and agreed-upon development goals so both parties can track progress in the next quarter.
Tip: Separate the career review conversation from the performance review conversation if your organization has a formal performance cycle. Trying to do career development and compensation discussion in the same meeting makes people defensive rather than open to growth feedback.
Examples
Example: Backend Engineering Chapter in a 40-Person Product Tribe
A product tribe with 6 squads and 40 people total has 14 backend engineers scattered across all 6 squads. Code quality varies widely: two squads write thorough tests, two write minimal tests, and two write none. Production incidents are three times more frequent in the low-testing squads. There is no shared coding standard, and each squad has adopted different frameworks for the same problems.
The tribe lead appoints a staff engineer as chapter lead and gives her 25% time allocation for chapter duties. She starts by surveying all 14 backend engineers on their current testing practices, framework choices, and pain points. ' The first three chapter meetings focus on establishing five foundational standards: minimum test coverage thresholds, a shared API design guide, a code review checklist, an incident response playbook, and a logging convention. Each standard is proposed as a lightweight RFC, discussed in a chapter meeting, and published in the tribe wiki.
Within two months, she sets up mentoring pairs: each of the four junior engineers is paired with a senior from a different squad. After one quarter, production incidents in the low-testing squads drop by 40%, and the chapter's biweekly meetings have a consistent 80% attendance rate. The competency framework is completed by the end of the second quarter and used for the first round of career reviews.
Example: UX Design Chapter in a B2C E-Commerce Company
A tribe building the checkout experience has 4 squads with 8 UX designers total. The company's design system exists but is inconsistently applied. Customer research is duplicated across squads because each designer conducts their own usability tests on overlapping user segments. The design manager left three months ago, and nobody is conducting 1:1s or career conversations with the designers.
The tribe lead promotes a senior designer to chapter lead, explicitly assigning people management duties including 1:1s, career reviews, and hiring. The new chapter lead's first action is a design audit: she reviews the last quarter's shipped designs across all four squads and documents every deviation from the design system. ' The chapter agrees on three immediate actions: consolidate research calendars so squads share participant pools, create a shared critique session every two weeks where designers present work-in-progress for peer feedback, and assign each design system gap to a specific designer to resolve. The competency framework is adapted from a public design ladder (Figma's published framework) and customized with the company's specific UX research and accessibility expectations.
Within one quarter, duplicate research sessions drop to zero, design system compliance rises from roughly 60% to 90%, and every designer has a clear picture of what their next career level requires.
Example: Data Science Chapter in a B2B Analytics Platform
A tribe of 5 squads building an analytics platform has 6 data scientists, each embedded in a different squad (one squad has no data scientist). The data scientists use three different ML frameworks, have no shared model validation process, and have never reviewed each other's work. Two of the six are junior hires from the last six months who received no onboarding into the company's data infrastructure.
The chapter lead, a principal data scientist, starts with a smaller, more intimate chapter format due to the six-person size. She institutes weekly 45-minute chapter meetings instead of biweekly, recognizing that the discipline needs intensive alignment. The first month's meetings focus entirely on standardization: the chapter selects one ML framework as the default (with documented exceptions), creates a shared model validation checklist, and establishes a peer review requirement for any model going to production. She pairs each junior data scientist with a senior mentor and creates a 90-day onboarding curriculum covering the company's data warehouse, feature store, and deployment pipeline.
The competency framework distinguishes between research-oriented and production-oriented data science tracks, acknowledging that the discipline has two distinct career paths. After the first quarter, model deployment time drops from an average of three weeks to one week because the standardized tooling eliminates rework. The chapter also identifies that the squad without a data scientist is making product decisions without data support, and recommends to the tribe lead that the next hire be allocated there.
Example: QA Chapter Bootstrapped in a Rapidly Scaling Startup
A 60-person startup has just adopted the Spotify Squad Model, organizing into 2 tribes with 4 squads each. Testing has been ad hoc, handled by developers. The company just hired its first 4 dedicated QA engineers and needs to establish quality practices from scratch across all 8 squads, with only one QA engineer per tribe initially and plans to hire more.
Because there are only 4 QA engineers across 2 tribes, the company creates a single cross-tribe QA chapter rather than one per tribe. The most experienced QA hire becomes chapter lead. Her first deliverable is a minimal viable quality standard: every squad must have at least smoke tests for critical user paths, a regression test suite that runs on every deployment, and a documented process for triaging bugs by severity. She runs the first chapter meeting as a working session where all four QA engineers collaboratively build the smoke test template that squads will adapt.
She creates a mentoring structure where each QA engineer is paired with a senior developer in their squad to cross-train on testing. The competency framework is intentionally simple at this stage, covering only three levels (junior, mid, senior) with five skill dimensions. As the team grows to 8 QA engineers over the next two quarters, she splits into two tribe-scoped chapters. The original cross-tribe chapter transitions into a QA guild that meets monthly to maintain consistency across tribes.
Test coverage across the company increases from near zero to 70% of critical paths within the first quarter.
Best Practices
Keep chapter meetings focused on craft, not delivery status. The moment a chapter meeting turns into a second standup or sprint review, members will start skipping it. If delivery concerns surface, redirect them to the appropriate squad ceremony and use the chapter time exclusively for skills, standards, and professional growth.
Publish all chapter decisions and standards in a shared, searchable location rather than keeping them in meeting notes or Slack threads. When standards live only in the memory of people who attended a particular meeting, new hires never learn them and existing members forget. A versioned wiki or handbook page that every squad can link to in their own documentation is the minimum viable publishing standard.
Give chapter leads explicit time allocation for their chapter responsibilities, typically 20-30% of their working week. Without protected time, the people management and craft leadership duties compete with squad delivery work, and delivery always wins in the short term. The tribe lead should account for this allocation when planning squad capacity.
Rotate the chapter meeting facilitator and topic presenter so that craft leadership develops across the chapter, not just in the chapter lead. If only the chapter lead ever presents or decides the agenda, the chapter becomes a broadcast channel rather than a collaborative community. Rotating also reveals emerging leaders who might become future chapter leads.
Calibrate competency assessments across chapters, not just within them. A 'senior' in the backend chapter should represent roughly the same scope of impact and skill depth as a 'senior' in the frontend chapter. Without cross-chapter calibration, you get level inflation in some disciplines and deflation in others, which breeds resentment and attrition.
Invite chapter members from adjacent tribes to attend as guests once per quarter. This cross-pollination prevents chapters from becoming insular and reveals divergent practices that should be reconciled. It also helps specialists build relationships beyond their own tribe, which makes future reorganizations less disruptive.
Track a small set of chapter health metrics quarterly: meeting attendance rate, mentoring session completion rate, time-to-competency for new hires, and voluntary attrition rate within the discipline. These four numbers tell you whether the chapter is adding value. If attendance drops below 60% or mentoring completion falls below 75%, something structural needs to change.
Common Mistakes
Treating the chapter lead role as a purely administrative position rather than a craft leadership role
Correction
When organizations appoint chapter leads who are good at scheduling meetings and filing paperwork but lack deep craft expertise, the chapter loses credibility. Members stop attending because the content is shallow and the feedback is generic. The signal to watch for is when senior members consistently skip chapter meetings or privately say the meetings are not useful. Fix this by selecting leads who are among the strongest practitioners in the discipline and who have demonstrated informal mentoring behavior.
The administrative work can be delegated to a rotating note-taker.
Allowing chapters to become approval gates for squad decisions
Correction
Some chapter leads, especially those with strong opinions about technical standards, start requiring squads to get chapter approval before making architectural decisions. This turns the chapter into a bottleneck that contradicts squad autonomy. The warning sign is when squads start complaining that the chapter is slowing them down or when chapter meetings get dominated by architecture review requests instead of craft discussions. Chapters should set standards and provide guidance, but squads must retain final authority over their own delivery decisions. Frame the chapter's role as 'consult and advise,' not 'approve and gate.'
Creating too many narrowly scoped chapters that fragment the specialist community
Correction
A tribe with 30 engineers might try to create separate chapters for backend, frontend, mobile, DevOps, QA, and data engineering, resulting in six chapters with five members each. These small chapters lack the critical mass for meaningful peer learning and create scheduling overhead that exhausts everyone. The diagnostic signal is chapters that regularly cancel meetings due to low attendance or where every meeting has the same three people. Start with broader chapters (e.g., 'engineering' or 'design') and only split when a chapter exceeds 12-15 members and the subgroups demonstrably have different practice needs.
Running chapter meetings as presentations with no interactive component
Correction
When every chapter meeting is a one-way lecture by the chapter lead or a guest speaker, members become passive consumers rather than active contributors. Attendance drops because people feel they could just read the slides. The fix is to make at least half of every meeting interactive: live code reviews where everyone comments, design critiques where attendees sketch alternatives, or calibration exercises where members independently assess a work sample and then compare ratings. Interaction is where the real learning and alignment happen.
Neglecting the competency framework after initial creation
Correction
Teams invest significant effort in building a competency matrix, use it for one or two promotion cycles, and then let it gather dust as the discipline evolves. Within a year, the framework no longer reflects the skills that actually matter, and promotion decisions drift back to gut feel. The warning sign is when chapter members stop referencing the framework in their career conversations. Schedule a quarterly review of the framework as a standing agenda item in one chapter meeting per quarter.
Assign specific sections to members for update proposals, and treat the framework as a living codebase that requires maintenance.
Isolating chapters from each other and from the broader organization
Correction
When chapters operate in silos within their tribe, the same problems get solved differently across the organization, and best practices never cross tribe boundaries. You will see this when a new hire in one tribe learns a completely different set of standards than a new hire in another tribe for the same discipline. Build cross-tribe connections by having chapter leads from the same discipline across different tribes meet monthly, sharing meeting notes organization-wide, and encouraging chapter leads to attend each other's sessions. This is where chapters and guilds complement each other: the guild provides the cross-tribe coordination that individual chapters cannot.
Other Skills in This Method
Organizing Squads into Tribes for Strategic Alignment
How to group related squads into tribes, set tribe size limits, appoint tribe leads, and maintain alignment across squads without sacrificing autonomy.
Scaling Agile Practices Using Spotify Structures
How to use the Spotify organizational model as a scaling framework, including when to split tribes, spawn new squads, and evolve governance as the company grows.
Evaluating Spotify Model Tradeoffs and Common Pitfalls
How to assess the pros, cons, and known failure modes of the Spotify Model so you can make an informed adoption decision and avoid cargo-culting.
Building Guilds for Cross-Tribe Knowledge Sharing
How to create and sustain voluntary, company-wide guilds that share knowledge, tooling, and best practices across tribe boundaries.
Balancing Squad Autonomy with Organizational Alignment
Techniques for setting guardrails, defining loose coupling and tight alignment, and using OKRs or mission briefs so squads stay autonomous yet strategically coherent.
Forming Autonomous Squads with Clear Missions
How to define, staff, and launch cross-functional squads with well-scoped missions, product ownership, and end-to-end delivery responsibility.
Adapting the Spotify Model to Your Organization
A step-by-step approach for implementing and customizing the squad/tribe/chapter/guild structure to fit your company's size, culture, and existing processes.
Frequently Asked Questions
How large should a chapter be before it justifies its own structure?
A chapter needs at least three members to generate meaningful peer learning and justify the overhead of a dedicated lead and meeting cadence. The sweet spot is 5-12 members. Below five, consider joining an adjacent chapter or forming a guild instead. Above 12-15, the chapter becomes too large for intimate craft discussions and should consider splitting into focused subchapters, each with its own lead who reports to a discipline director.
Should chapter leads also be embedded in squads, or should they be full-time leads?
For chapters under 10 members, the chapter lead should remain embedded in a squad and allocate 20-30% of their time to chapter duties. This keeps them grounded in daily practice and prevents them from drifting into pure management. For chapters of 10-15 or more, the chapter lead role becomes close to full-time and the person should step out of squad delivery work. The risk of a full-time lead is losing touch with hands-on craft, so schedule regular pairing sessions or code reviews to stay sharp.
How do I handle disagreements between a chapter's standards and a squad's preferred approach?
Default to squad autonomy for implementation decisions and chapter authority for quality standards. If a squad wants to use a different library than the chapter recommends, that is an implementation decision and the squad should be free to choose. If a squad wants to skip code reviews or ship without tests, that is a quality standard violation and the chapter lead should intervene. Document the boundary in the chapter charter. When genuine gray areas arise, escalate to the tribe lead for a decision and add the outcome to the charter as precedent.
How often should chapter meetings happen, and how do I prevent attendance from declining?
Biweekly is the most common cadence. Weekly works for small chapters in rapid alignment phases. Monthly risks losing momentum. To prevent declining attendance, make the content genuinely valuable, not just status updates. Rotate presenters so everyone has ownership. Keep meetings to 45-60 minutes. Share notes and outcomes so missing a meeting does not mean missing context. If attendance drops below 60% for two consecutive meetings, survey members about what they would find more valuable and restructure accordingly.
What is the difference between a chapter and a guild in the tribes squads chapters guilds model?
Chapters are formal, tribe-scoped groups with a dedicated lead who has people management authority. Membership is based on your primary discipline. Guilds are voluntary, organization-wide communities of interest with no formal authority. You join a guild because you are curious about a topic, not because it is your job title. Chapters own career growth, standards, and hiring for a discipline within a tribe. Guilds share knowledge and best practices across tribes. See [building guilds](/skills/building-cross-cutting-guilds) for the complementary skill.
How do I build a competency framework if my organization has never had one?
Start by borrowing. Many companies publish their engineering and design ladders publicly (Rent the Runway, Etsy, CircleCI, Buffer, Figma). Find one that matches your discipline and company size, then adapt it. Customization should focus on your specific technical stack, domain, and organizational values. Draft the framework, then validate by having three senior chapter members independently assess themselves and one junior member. If the assessments cluster as expected, the framework is calibrated. If they diverge wildly, the indicators are too vague. Plan on two to three iterations before the framework feels stable.
Should I set up chapters before or after organizing squads into tribes?
After. Chapters are scoped to a tribe, so you need tribe boundaries established first. Start by [forming autonomous squads](/skills/forming-autonomous-squads), then [organizing squads into tribes](/skills/organizing-tribes-for-alignment), and then create chapters within each tribe. Attempting to create chapters before tribes exist leads to ambiguous scope and chapter leads who do not know which squads their members belong to. The one exception is if you are bootstrapping with very few specialists, in which case a cross-tribe chapter or a guild may be the right interim structure.