Building Guilds for Cross-Tribe Knowledge Sharing
This skill teaches you how to launch, structure, and sustain voluntary, company-wide guilds that move knowledge, tooling decisions, and best practices across tribe boundaries so that autonomous squads do not reinvent the wheel in isolation.
Start by identifying a recurring pain point or knowledge gap that spans multiple tribes. Recruit a passionate guild coordinator, define a lightweight charter with a clear purpose, and schedule a regular cadence of open meetings. Keep participation voluntary and focus each session on a concrete artifact such as a shared standard, tool recommendation, or lessons-learned document. Measure health through attendance trends and contribution frequency, not mandated KPIs.
Outcome: You have a functioning guild with a clear charter, a named coordinator, a regular meeting cadence, and a shared artifact repository that people across multiple tribes actively contribute to and reference in their daily work.
Prerequisites
- A working squad and tribe structure (or equivalent autonomous team topology)
- Familiarity with the Spotify Squad Model's chapter and tribe concepts
- At least two tribes whose work overlaps in a shared discipline or technology area
- Basic facilitation skills for running open, voluntary group discussions
Overview
Guilds are the third major structural element in the Spotify Squad Model, sitting alongside squads and chapters. While squads own product delivery and chapters build craft excellence within a single tribe, guilds cut horizontally across the entire organization. They are voluntary communities of interest where anyone, regardless of tribe or role, can join to share knowledge about a topic they care about. Topics range from narrow technical concerns like "front-end testing patterns" to broad organizational themes like "continuous delivery" or "data privacy." The defining feature of a guild is that nobody is required to show up. That voluntary nature is both the guild's greatest strength and its biggest operational risk.
The concrete problem guilds solve is knowledge fragmentation at scale. When an organization grows past two or three tribes, the informal hallway conversations that once kept everyone aligned disappear. Without guilds, each tribe develops its own conventions for logging, its own deployment scripts, and its own opinions about which database to use. Duplication multiplies, onboarding gets harder, and costly mistakes get repeated. A well-run guild creates a lightweight, low-overhead channel for surfacing these divergences early and converging on shared standards when convergence makes sense, while still respecting squad autonomy.
The artifact a guild produces is not code (that is the squad's job) or a career development plan (that is the chapter's job). A guild produces shared knowledge assets: decision records about tooling choices, curated playbooks, recorded demos of internal tools, written retrospectives on cross-tribe incidents, and recommended defaults that squads can adopt or consciously deviate from. By the end of this skill, you will have a repeatable process for identifying guild-worthy topics, recruiting a coordinator, writing a lightweight charter, launching the first session, and measuring ongoing health so the guild does not decay into an empty calendar invite. This skill is a key element of the spotify engineering culture that made Spotify's scaling model famous, and it is the one most organizations struggle to replicate because voluntary participation requires genuine value delivery every single session.
Guilds also serve as a social glue layer. In organizations where people identify strongly with their squad or tribe, guilds create cross-cutting relationships that make collaboration smoother when two squads need to integrate features, resolve an incident together, or negotiate a shared API contract. The relationships formed in guild meetings reduce coordination friction in ways that no formal process can replicate.
How It Works
A guild works because it exploits intrinsic motivation rather than managerial authority. People join because the topic matters to their daily work and the guild delivers something they cannot get from their squad or chapter alone: exposure to how other parts of the organization solve similar problems. This is the core mechanism. Every time a guild member hears "we tried that approach in Tribe B and here is what broke," the guild has justified its existence for that week.
The underlying model is a lightweight community of practice. Communities of practice theory (Wenger, 1998) tells us that a healthy community needs three elements: a shared domain, a community of people who care about that domain, and a practice consisting of shared resources. Guilds map directly to this: the domain is the guild's charter topic, the community is the voluntary membership, and the practice is the set of artifacts the guild maintains. When any one of these three elements weakens, the guild decays. A guild with a domain but no active community is just a Slack channel nobody reads. A guild with community but no practice is a social club that produces nothing lasting. A guild with practice artifacts but no shared domain becomes an unfocused dumping ground.
Guilds differ from chapters in two critical ways. First, chapters are mandatory. If you are a front-end engineer in Tribe A, you belong to the front-end chapter in Tribe A. Guilds are opt-in. Second, chapters operate within a single tribe and have a formal leader (the chapter lead) who has people-management responsibilities. Guilds cross tribe boundaries and their coordinator has zero managerial authority. This distinction matters because it means a guild coordinator cannot fall back on positional power. They must earn attention every session by delivering value.
The rhythm of a healthy guild follows a pattern: a regular cadence (biweekly or monthly), a rotating set of contributors who present or demo something, a shared channel for asynchronous discussion between meetings, and a repository of artifacts that accumulates over time. The cadence creates predictability. The rotating contributors distribute the burden and keep content fresh. The asynchronous channel handles the quick questions that do not need a full meeting. The artifact repository is the durable output that outlasts any single session.
One important mental model is the "gravitational pull" concept. A guild with strong gravitational pull produces artifacts so useful that people reference them even if they never attend a meeting. A guild with weak pull depends entirely on the social energy of meetings and collapses the moment the coordinator burns out. Your goal when building a guild is to maximize gravitational pull by ensuring each session leaves behind something tangible: a written decision, a shared template, a recorded demo, a curated reading list. This is how the spotify engineering culture sustained guilds at scale. The artifacts did the recruiting.
Finally, understand that guilds have a natural lifecycle. Some guilds should be temporary. A guild formed to help the company migrate from one CI system to another should dissolve when the migration is complete. Treating every guild as permanent leads to zombie guilds that drain attention. Build sunset criteria into the charter from day one.
Step-by-Step
Step 1: Identify a guild-worthy topic through pain signals
Look for recurring signals that knowledge is fragmenting across tribes. Concrete signals include: the same bug class appearing in two or more tribes within a quarter, duplicate tooling being built independently, repeated questions in company-wide Slack channels that get different answers depending on who replies, and onboarding documents that contradict each other across tribes. " Collect responses and cluster them by theme. A theme that appears in three or more responses from different tribes is a strong guild candidate.
The output of this step is a short list of 2-4 candidate topics, each with the names of people who raised it and a one-sentence description of the pain.
Tip: Do not start with the topic you personally find most interesting. Start with the topic that the most people across tribes independently named. Voluntary communities only survive when the pull comes from the participants, not the founder.
Step 2: Recruit a guild coordinator and two to three seed members
The guild coordinator is not a manager. They are a facilitator and curator. Look for someone who is respected in the topic area, has social energy for organizing, and works in a tribe that is not the political center of the topic. This last point matters because a coordinator from the dominant tribe can inadvertently turn the guild into an extension of that tribe's opinions.
Approach your candidate directly and explain the time commitment: roughly 1-2 hours per week for scheduling, curating agenda items, and maintaining the artifact repository. Then identify two to three seed members from different tribes who will attend the first three sessions no matter what. These seed members provide social proof that the guild is cross-tribe, not a single-tribe initiative wearing a guild label. The output is a named coordinator and a committed seed group of 3-4 people spanning at least two tribes.
Tip: If nobody volunteers to coordinate after you explain the role, that is a strong signal the topic does not have enough organic energy to sustain a guild. Do not force it. Revisit in a quarter.
Step 3: Write a lightweight charter
The charter is a single document, ideally one page, that answers five questions: What is this guild about? ) Who is this guild for? ) What does success look like in six months? ") How will we meet?
) When should this guild sunset? ) Write the charter collaboratively with your seed members during a 30-minute synchronous session. Post the finished charter in a company-visible location like a wiki or shared docs folder. The charter is your recruiting tool, so make it scannable and specific.
Tip: Avoid vague purpose statements like "share knowledge about testing." Instead write "converge on a shared set of integration testing patterns that any squad can adopt, reducing the current fragmentation where five tribes use five different approaches." Specificity attracts the right people and repels tourists.
Step 4: Set up communication channels and an artifact repository
Create two things before the first meeting. First, a dedicated asynchronous channel (Slack channel, Teams channel, or equivalent) named with a consistent convention like #guild-[topic]. Post the charter as the channel's first message. Second, an artifact repository.
This can be a wiki space, a shared folder, or a section of your internal docs site. The repository needs a simple structure: a landing page that links to the charter, a meeting notes folder, and a decisions or standards folder. Do not over-engineer the structure. You can reorganize later once you know what the guild actually produces.
Invite the seed members and anyone else who expressed interest during Step 1. The output of this step is a live channel with the charter pinned and an empty-but-structured repository ready to receive the first session's artifacts.
Tip: Name the channel and repository identically so people can find one from the other. If your company has a guild directory or internal wiki index, add the new guild immediately. Discoverability is half the battle for voluntary communities.
Step 5: Plan and run the first session around a concrete problem
The first session sets the tone for everything that follows. Do not make it a meta-discussion about the guild's purpose. Instead, pick one concrete problem from the pain signals you collected in Step 1 and structure the session as a working session to address it. A strong format for the first meeting: 5 minutes of context-setting (the coordinator reads the charter aloud and explains the ground rules, particularly that the guild is voluntary, there is no hierarchy, and anyone can propose agenda items), then 20-25 minutes of a structured discussion or demo around the concrete problem, then 10 minutes to agree on a tangible next step and assign a single owner.
The tangible next step might be drafting a shared standard, building a comparison matrix of current approaches across tribes, or recording a demo of one tribe's solution for others to evaluate. End the session by confirming the date and topic for the next meeting. Post meeting notes in the artifact repository within 24 hours. The output is a set of meeting notes, one assigned action item, and a confirmed next meeting.
Tip: Keep the first session to 30-40 minutes. Voluntary meetings that run over an hour develop a reputation for being time sinks, and attendance drops after the second session.
Step 6: Establish a sustainable cadence and rotating contributions
After the first session, lock in a recurring calendar event. Biweekly works for most guilds. Monthly is acceptable for guilds with a narrow, slow-moving topic. Weekly is almost always too frequent for a voluntary group and leads to burnout.
" and get a name on the spot. This rotation is critical. If the coordinator runs every session, the guild becomes a one-person show and dies when that person gets busy. Aim for a different contributor each session.
The coordinator's job between sessions is lightweight: send a reminder 48 hours before the meeting with the agenda, post a summary within 24 hours after, and keep the artifact repository organized. The output of this step is a recurring meeting with a rotation list and a clear norm that contributions are distributed.
Tip: If you cannot find a volunteer to lead the next session, shrink the format. A 15-minute lightning talk is easier to commit to than a 40-minute workshop. Lower the barrier rather than canceling.
Step 7: Grow membership through artifact gravity, not announcements
Resist the urge to send company-wide announcements begging people to join. Instead, focus on making the guild's artifacts so useful that people find them organically. When a guild produces a decision record about which logging library to use, post it in the relevant company-wide channels where engineers already discuss logging. When someone in a different tribe asks a question the guild has already answered, link them to the guild's artifact and mention they are welcome to join.
This pull-based growth ensures that new members arrive because they have a genuine need, not because they felt socially obligated. Track membership and attendance loosely: a simple count of unique attendees per session over time. Healthy guilds typically stabilize at 8-20 active participants. Larger than 20, consider splitting into sub-guilds.
Smaller than 5 for three consecutive sessions, revisit whether the topic still has energy.
Tip: The single most effective recruiting technique is when a guild artifact saves someone outside the guild an hour of work. That person becomes an evangelist without being asked.
Step 8: Measure guild health and decide whether to evolve or sunset
Guilds do not need KPIs, but they do need health signals. Track three indicators quarterly. First, attendance trend: is the number of unique attendees per session stable, growing, or declining over three months? A steady decline over two quarters is a sunset signal.
Second, artifact production: has the guild produced at least one new or updated artifact per month? If not, the guild may have shifted from a community of practice to a social gathering, which is fine but should be acknowledged. Third, cross-tribe participation: are attendees still coming from multiple tribes, or has the guild collapsed into a single-tribe group? If participation has narrowed to one tribe, the guild has likely been absorbed by that tribe's chapter and can be dissolved.
At the six-month mark, revisit the success criteria in the charter. If the guild has achieved its stated goals, celebrate the accomplishment and either sunset the guild or write a new charter for its next phase. The output is a quarterly health summary shared in the guild channel and with tribe leads.
Tip: Sunsetting a guild is a sign of success, not failure. A guild that achieved its purpose and dissolved gracefully is worth far more than a zombie guild that persists out of inertia.
Examples
Example: Web Platform Guild at a 120-person SaaS company with four tribes
A SaaS company has grown to four product tribes, each with two to three squads. Three of the four tribes have front-end engineers using React, but each tribe has drifted to different state management approaches, component libraries, and testing strategies. New hires are confused because the "right way" to build a component depends on which tribe they join. A senior front-end engineer in Tribe C notices that the same rendering bug was fixed independently in Tribes A and C within the same month.
The engineer runs the pain-signal survey from Step 1 and finds that 7 out of 12 front-end engineers across three tribes mention "inconsistent component patterns" or "duplicate utility libraries" as a recurring frustration. She recruits a coordinator from Tribe A (not her own tribe, to avoid Tribe C dominance) and two seed members from Tribes B and D. " Success in six months: a published component style guide and a shared testing utility package. Sunset criteria: when the style guide is adopted by at least three tribes and the testing package is in use.
The first session is a 35-minute working session where one engineer from each tribe demos their current component structure in 5 minutes, followed by 15 minutes of group discussion to identify the three largest divergences. The output is a decision record listing the top three areas for convergence. Over the next three months, the guild produces a shared component template, a recommended testing approach document, and a migration guide. Attendance stabilizes at 9 people.
At the six-month mark, three tribes have adopted the shared patterns. The guild rewrites its charter to focus on performance optimization, entering a new phase.
Example: Data Privacy Guild at a 300-person fintech with eight tribes
A fintech company operating in multiple regulatory jurisdictions has eight product tribes. The legal team has flagged that different tribes are implementing GDPR consent flows inconsistently, creating compliance risk. There is no central engineering authority for data privacy because each tribe owns its own data pipeline. The VP of Engineering asks whether a guild could help without creating a top-down mandate that would violate squad autonomy.
The VP identifies a privacy-aware engineer in Tribe E as coordinator and asks (not mandates) her to explore interest. She posts in the engineering-wide Slack channel: "I am exploring whether a Data Privacy Guild would be useful. " Within a week, 14 engineers from six tribes respond. She recruits seed members from three different tribes and writes a charter: purpose is to create a shared consent-flow reference implementation and a data deletion playbook.
Success criteria: both artifacts reviewed by legal and adopted by at least five tribes within six months. The first session brings 11 attendees. The coordinator presents a 10-minute overview of the regulatory requirements (provided by legal) and then facilitates a 20-minute mapping exercise where each tribe describes their current consent flow in two sentences. The guild discovers that three tribes have nearly identical implementations and two have significant gaps.
Over the next four months, the guild produces a reference consent-flow library, a data deletion runbook, and a quarterly audit checklist. Legal reviews and approves all three. The guild sunsets after seven months because the artifacts are stable and maintained by the platform team. 5 hours per person per month for active participants.
Example: Incident Response Guild at a 60-person B2B startup with two tribes
A small B2B startup has two product tribes. They have experienced three significant production incidents in the past quarter, and each time the response was ad hoc. Engineers from both tribes scrambled without a shared playbook, communication was chaotic, and the post-incident reviews produced recommendations that were never tracked. The CTO wants to improve incident response without hiring a dedicated SRE team.
The CTO asks an engineer from Tribe A who led the best post-incident review to coordinate the guild. With only two tribes, the coordinator recruits one seed member from each tribe plus an on-call engineer from the platform team (three seed members total). The charter is tight: purpose is to create a shared incident response playbook and a blameless post-incident review template. Success in three months: both artifacts published and used in the next incident.
Sunset criteria: when the playbook has been used in two real incidents and the review template is integrated into the team's standard process. The guild meets biweekly for 30 minutes. Session one: the coordinator walks through the last incident timeline and the group identifies the three biggest coordination failures. Session two: one member presents an incident response framework they found useful at a previous company and the group adapts it.
Session three: the group reviews a draft playbook and stress-tests it against a past incident scenario. By week six, the playbook and review template are published. The next real incident uses both artifacts, and the post-incident review identifies two improvements to the playbook. The guild runs one final session to incorporate those improvements, then sunsets.
Total lifespan: 10 weeks, four sessions, two durable artifacts.
Example: Machine Learning Guild at a 500-person e-commerce company with twelve tribes
A large e-commerce company has twelve product tribes. Five of them have hired ML engineers in the past year, but these engineers are scattered across squads and have no shared forum. Each ML engineer is choosing their own model serving infrastructure, experiment tracking tools, and feature store approach. The Head of ML (a new role) wants to create alignment without centralizing all ML work into a single tribe, which would conflict with the company's squad-based autonomy model.
The Head of ML identifies two coordinators (not herself, to avoid the guild becoming a management tool) from different tribes. They run the pain-signal survey and find that all 14 ML engineers across five tribes name "no shared experiment tracking" and "duplicated feature engineering" as their top frustrations. The charter defines two success criteria at six months: a recommended experiment tracking stack evaluated and documented, and a shared feature store proof-of-concept available for any squad to use. The guild launches with 12 attendees from five tribes.
The first session is structured as a lightning round: each tribe's ML engineer describes their current stack in three minutes using a shared template (model serving, experiment tracking, feature store, monitoring). The coordinator compiles these into a comparison matrix and posts it in the artifact repository. Sessions two through four each tackle one area of the matrix: a member presents their approach, the group discusses tradeoffs, and the guild votes on a recommended default. By month four, the guild has published a recommended experiment tracking setup with a migration guide and a shared feature store library that three tribes adopt.
The guild continues beyond six months but rewrites its charter to focus on ML model monitoring and fairness evaluation. Membership grows to 18 as the artifacts attract ML engineers from tribes that had not initially participated. The guild becomes a signature element of the company's spotify engineering culture, cited in recruiting materials.
Best Practices
Keep guild meetings to 30-40 minutes and protect the end time ruthlessly. Voluntary participants will forgive a dull session, but they will not forgive a session that consistently steals an hour from their sprint work. If you find you need longer sessions, schedule them as separate, infrequent workshops rather than extending the regular cadence.
Produce a tangible artifact from every session, even if it is just a one-paragraph decision record or a link roundup. Artifacts are how a guild compounds value over time. A guild that meets regularly but writes nothing down is indistinguishable from a hallway conversation, and it delivers zero value to people who could not attend.
Rotate the presentation or facilitation role across members every session. This prevents coordinator burnout, exposes the guild to diverse perspectives from different tribes, and creates a sense of shared ownership. If the coordinator runs every session, the guild becomes a podcast with one host, and the audience eventually stops showing up.
Write the charter with explicit sunset criteria before launch. This removes the social awkwardness of dissolving a guild later and normalizes the idea that guilds are tools, not institutions. Common sunset triggers include: the migration is complete, the standard has been adopted by all tribes, or attendance has dropped below five for three consecutive sessions.
Post guild artifacts in the channels and wikis where people already look for answers, not just in the guild's own repository. A logging standard that lives only in the guild wiki helps nobody who does not know the guild exists. Cross-posting is the highest-leverage activity a coordinator can do.
Schedule a brief retrospective every quarter where guild members answer three questions: What has the guild done well? What should change? Should this guild continue? This creates a structured moment to adjust cadence, topic scope, or coordinator role before problems become entrenched.
Respect the voluntary principle absolutely. Never let a manager mandate guild attendance or track who does not show up. The moment participation feels compulsory, the guild loses the intrinsic motivation that makes it work. If attendance is low, the correct response is to make the sessions more valuable, not to guilt people into attending.
Keep the coordinator role lightweight by using simple templates for meeting notes and agendas. A three-bullet agenda template (topic, presenter, desired outcome) and a four-section meeting notes template (attendees, discussion summary, decisions made, action items) save 30 minutes of overhead per session.
Common Mistakes
Launching a guild for a topic that only one tribe cares about
Correction
This happens when an enthusiastic individual conflates personal interest with organizational need. The signal to watch for is that during the recruitment phase, you cannot find seed members from more than one tribe. If the topic only resonates within a single tribe, it belongs in a chapter, not a guild. Chapters are the correct structure for discipline-specific excellence within a tribe.
Guilds exist specifically to bridge tribe boundaries. Run the pain signal survey from Step 1 honestly and accept the results.
Treating the guild as a decision-making body with authority over squads
Correction
Guilds recommend, they do not mandate. When a guild starts issuing directives that squads must follow, it violates the autonomy principle that makes the Spotify model work. This usually happens when a senior engineer coordinates the guild and unconsciously wields positional influence. " The fix is to frame all guild outputs as "recommended defaults" with an explicit note that squads may deviate if they document their reasoning.
The guild's power comes from the quality of its recommendations, not from organizational authority.
Over-engineering the guild's infrastructure before proving demand
Correction
Some organizers spend weeks building elaborate wiki structures, custom dashboards, and onboarding guides before the first meeting. This front-loads effort on the coordinator and creates sunk-cost pressure to keep a guild alive even if it has no traction. The symptom is a beautiful wiki with no content and a coordinator who is already tired. Start with a single Slack channel and a shared document for the charter.
Add infrastructure only as the guild produces artifacts that need organizing. Let the structure follow the content.
Running every session as an open discussion with no structure
Correction
Unstructured discussions feel democratic but consistently produce meetings where the loudest voices dominate and quieter members stop attending. The pattern is that the first three sessions feel energetic because of novelty, then attendance drops as people realize they can predict who will talk and what they will say. The fix is to use a consistent session format: a short presentation or demo by a rotating member, followed by structured Q&A or a specific exercise, ending with a concrete action item. Structure gives quieter members a clear entry point to contribute.
Letting the coordinator role become a full-time job
Correction
This creeps in gradually. The coordinator starts writing all the meeting notes, preparing all the presentations, maintaining the wiki, answering all the Slack questions, and evangelizing the guild to new hires. Within two months, the coordinator is spending 5-8 hours per week on guild work and their squad lead is unhappy. The symptom is that no one else contributes artifacts.
The fix is to delegate aggressively from the start: rotate note-taking, rotate presentations, and assign artifact ownership to the person who proposed the topic. The coordinator's job is to schedule, remind, and curate, not to produce.
Ignoring the guild when attendance plateaus at 3-4 people for months
Correction
A guild with persistent low attendance is sending a clear signal that either the topic has been resolved, the sessions are not delivering value, or the topic is too narrow to sustain a cross-tribe community. Many coordinators interpret low attendance as a personal failure and respond by sending more reminders or broadening the topic to the point of incoherence. The correct response is to run a brief retrospective with the remaining members. Ask whether the guild should narrow focus, change format, merge with another guild, or sunset.
Low attendance is diagnostic data, not a character flaw.
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.
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.
Running Chapters to Build Discipline-Specific Excellence
How to establish and facilitate chapters—groups of specialists across squads within a tribe—to standardize practices, mentor members, and manage career growth.
Frequently Asked Questions
How many guilds should an organization have at one time?
There is no fixed number, but a useful heuristic is one guild per major cross-cutting concern that cannot be addressed within a single tribe's chapters. For a company with 4-6 tribes, 3-5 active guilds is typical. For 10+ tribes, 6-10 guilds is reasonable. The constraint is attention, not structure. Each engineer can realistically participate in one or two guilds without it affecting their squad work. If you find yourself with more than 10 guilds, audit whether some have overlapping scope and should merge.
How is a guild different from a chapter in the Spotify model?
Chapters are mandatory, operate within a single tribe, and are led by a chapter lead with people-management responsibilities (career growth, performance). Guilds are voluntary, span the entire organization across tribe boundaries, and are led by a coordinator with no managerial authority. Chapters build discipline-specific excellence within a tribe. Guilds share knowledge and converge on standards across tribes. A front-end engineer belongs to their tribe's front-end chapter automatically, but they choose to join the Web Platform Guild because they care about cross-tribe component consistency. See [running chapters for craft excellence](/skills/running-chapters-for-craft-excellence) for more on chapters.
What should I do when guild attendance drops below five people?
Run a quick diagnostic before reacting. Ask the remaining members three questions: Is the topic still relevant? Are the sessions delivering value? Would a different format help? If the topic has been resolved (the standard was published, the migration is done), celebrate and sunset the guild. If the topic is still relevant but sessions feel stale, change the format: try lightning talks, pair-debugging sessions, or guest speakers from outside the company. If multiple people say they value the guild but cannot make the time slot, experiment with a different day. Persistent low attendance after these adjustments is a clear signal to sunset.
Should guild coordinators get formal recognition or dedicated time from their squad?
Yes, but informally. The coordinator role typically requires 1-2 hours per week. The coordinator's squad lead should be aware of and supportive of this commitment, treating it like any other cross-team responsibility. Some organizations include guild coordination in performance reviews as a "multiplier" activity. Avoid creating a formal title or bonus structure, as that can shift motivation from intrinsic to extrinsic and attract coordinators who want the recognition more than the community. The best recognition is visibility: mention guild accomplishments in all-hands meetings and attribute the work to the coordinator and contributors by name.
How do I prevent a guild from becoming dominated by one tribe or one senior engineer?
Build rotation into the structure from day one. Rotate who presents, who takes notes, and who proposes the next session's topic. Explicitly recruit seed members from multiple tribes and track cross-tribe participation quarterly. If participation narrows to a single tribe, the coordinator should actively reach out to engineers in other tribes with a specific invitation: "We are discussing X next week, and I know your tribe does this differently. " For senior-engineer dominance, use structured formats like round-robin input or anonymous pre-session polls, which give quieter members equal voice.
Should I build a guild before or after establishing chapters within each tribe?
Establish chapters first. Chapters create the within-tribe craft communities that give engineers a home base for their discipline. Guilds work best when chapter leads from different tribes notice they are solving the same problems independently and want a cross-tribe forum to converge. Launching guilds before chapters exist often means the guild tries to do both jobs (craft development and cross-tribe sharing), which makes its scope too broad and its meetings too long. See [organizing tribes for alignment](/skills/organizing-tribes-for-alignment) for guidance on sequencing these structures.
Can guilds work in a remote or distributed organization?
Guilds are arguably more important in remote organizations because the informal hallway knowledge sharing that co-located teams enjoy disappears entirely. Run guild sessions as video calls with the same 30-40 minute structure. Invest more in the asynchronous layer: the Slack channel should be active between sessions with links, questions, and short write-ups. Record sessions and post recordings in the artifact repository for people in different time zones. Some remote guilds rotate between two meeting times to accommodate different regions. The key adjustment is that artifact production becomes even more critical, because remote participants who miss a session rely entirely on the written output.