Building Guilds for Cross-Tribe Knowledge Sharing

Start and sustain voluntary, company-wide guilds that share knowledge, tools and decisions across tribes, using what research on Spotify's guilds found.

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 guild is a voluntary community of people across the whole company who share an interest in a practice, such as web development, testing or agile coaching. In the Spotify model it is the loosest structure: no manager, no fixed membership, and no formal authority. Its job is to recover the economies of scale that autonomous squads lose.

The 2012 paper by Kniberg and Ivarsson explains the problem guilds solve: the tester in one squad may be wrestling with a problem the tester in another squad solved last week. It describes a guild as a more organic, wide-reaching "community of interest" that wants to share knowledge, tools, code and practices. Anybody who is interested can join any guild, and each guild has a "guild coordinator". The paper's examples include a web guild unconference, where web developers from across Spotify met in Stockholm to discuss their field.

Guilds are a form of what Etienne and Beverly Wenger-Trayner call communities of practice: "groups of people who share a concern or a passion for something they do and learn how to do it better as they interact regularly" (Wenger-Trayner). Their point that a shared job title alone does not make a community, unless members interact and learn together, is the most useful test for whether a guild is real.

There is also direct research on Spotify's guilds. A study published in Communications of the ACM in 2020 examined four of Spotify's sponsored guilds and found clear benefits alongside real difficulty keeping members engaged as the company grew (Smite et al., Spotify Guilds). This skill uses those findings to design a guild that lasts. The output is a short guild charter, a set of channels and activities, a coordinator, and a way to judge whether the guild is worth keeping.

How It Works

A guild runs on voluntary effort, so it lasts only if members get something from it. The CACM study describes a loop from earlier research: engagement helps a community create more value, and more value draws more engagement (Smite et al.). Everything in this skill is aimed at starting that loop and keeping it turning.

The study found that Spotify's guilds use a mix of activities. Most have regular meetings and seminars, yearly unconferences lasting two to four days, email groups and chat channels. Meetings are where decisions and ideas are exchanged; seminars are for learning from internal and external experts. Some guilds use requests for comments, where any member can propose a technical change in a shared template and collect review from the whole guild, which lets them make decisions asynchronously. The largest guild in the study, for backend development, had no scheduled meetings at all and relied on a volunteer group of 40+ members answering questions in its support channel (Smite et al.).

Engagement is uneven, and that is normal. The study reports that only 20% of members regularly engage in guild activities. It concludes that few attendees at regular meetings is not necessarily a sign of failure, and recommends offering several kinds of activity so members can take part in different ways (Smite et al.).

Two barriers stand out. The first is time: members reported lacking dedicated time for guild work and feeling that it was not recognized by management. The second is scale: as Spotify grew across several locations, guilds suffered from detachment and fragmentation, and some split into regional sub-guilds. The study recommends that large, distributed guilds offer both regional and cross-site activities, and it stresses that management support matters for engagement.

Spotify distinguishes sponsored guilds, which have an explicit sponsor and a budget per member, from non-sponsored ones that receive no direct funding. You do not need a budget to start, but a guild that aims to set company-wide practice, or to run an unconference, will need a sponsor.

Step-by-Step Guide

Step 1: Find a topic with real pull

Look for a practice that several squads or tribes share and struggle with: repeated questions in chat, duplicated tools, or inconsistent approaches that cause problems. A guild built around a live problem attracts members; one created because an org chart has a gap does not. Check that people in at least two or three tribes care about it. Name the guild after the practice, such as "web development" or "data privacy".

Step 2: Recruit a coordinator and a few seed members

Find one person willing to coordinate and a handful of practitioners willing to contribute early. The coordinator organizes activities and keeps the guild visible; they are not a manager. Agree with the coordinator's manager how much time the role takes, since lack of dedicated time was a major barrier in the Spotify guilds study. Plan for the coordinator role to rotate later.

Step 3: Write a short charter

Write down the guild's domain, who it is for, and what it aims to produce, such as shared tooling, guidance or decisions on a practice. State that membership is open and voluntary. If the guild will make decisions that affect squads, say how, for example by request for comments. Keep it to a page so newcomers read it.

Step 4: Set up channels and a place for artifacts

Create a chat channel for questions and a shared space for guides, decisions and recordings. Make the channel the default place to ask about the topic, so answers accumulate where others can find them. Link the space from team onboarding material. Artifacts outlast meetings and are what most peripheral members use.

Step 5: Run a first session around a concrete problem

Open with a problem members actually have, such as comparing how three squads handle a shared concern. End with something useful: a decision, a draft guide or a list of open questions with owners. Record it and post the notes. The first session sets expectations; a status round with no outcome signals that the guild is another meeting.

Step 6: Offer several ways to take part

Combine regular sessions, a question channel and occasional larger events such as an unconference or a lunch-and-learn seminar with an internal or external speaker. Different members will use different channels; one fairly inactive member in the study said the question channel had helped them most. If members are spread across locations or time zones, offer regional sessions plus occasional cross-site ones.

Step 7: Get recognition and, where needed, sponsorship

Make guild work visible to managers by sharing what the guild produced and which squads used it. If the guild needs a budget for events or tooling, find a sponsor. Ask managers to count guild contributions in performance conversations, since contributors in the study felt their time was not valued otherwise.

Step 8: Review health and decide whether to continue

Every few months, ask members whether the guild helps them and whether they would miss it. Look at what it produced and who used it as well as at meeting attendance. If the guild no longer has pull, close it and archive its artifacts. Closing a guild that has done its job is a success, since the community can reform if the need returns.

Best Practices

• Keep membership open and voluntary. The original paper says anybody who is interested can join any guild, and mandatory guilds lose the goodwill that makes them work.
• Judge guilds by value rather than attendance. The CACM study found that only a minority of members engage regularly and that low meeting attendance is not necessarily failure.
• Build artifacts as well as meetings. Guides, decision records and answered questions in a channel serve the majority of members who never attend a session.
• Use written proposals for decisions. A request-for-comments process lets a guild agree on a technical change across time zones without a meeting.
• Protect the coordinator's time. The coordinator carries most of the guild's energy; without agreed time, they burn out and the guild stalls.
• Split by region when the guild outgrows one room. Spotify's larger guilds formed regional sub-guilds and kept cross-site events, a pattern the study recommends for distributed companies.

Common Mistakes

• Mandating guilds from above: A guild created by decree and filled by assignment rarely finds a purpose. Start from a problem people already feel.
• Treating low attendance as failure: Most members of any community of practice are peripheral. Check whether they use the guild's artifacts and channel before closing it.
• Giving the coordinator no time: Coordination done after hours fades within a few months. Agree the time with the coordinator's manager up front.
• Letting the guild become a status meeting: Sessions without a problem or an outcome lose members. Each session should produce a decision, an artifact or a clear next question.
• Confusing guilds with chapters: A guild has no line management and no fixed membership. If the group needs a manager or formal standards for a tribe, that is a chapter.

References

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

Related Skills

• Running Chapters for Craft Excellence
• Organizing Squads into Tribes for Alignment
• Forming Autonomous Squads with Clear Missions
• Balancing Squad Autonomy with Organizational Alignment
• Scaling Agile with Spotify Squads and Tribes
• Adapting the Spotify Model to Your Organization
• Evaluating Spotify Model Tradeoffs and Failure Modes

Sources

• Henrik Kniberg and Anders Ivarsson: Scaling Agile @ Spotify (2012)
• Smite et al.: Spotify Guilds, Communications of the ACM
• Wenger-Trayner: Introduction to communities of practice

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