Breaking Silos with Guilds

Guilds are a straightforward yet powerful technique for preventing silos. A guild is a group of people who work on different teams but share a common interest or skill set. The neat thing about guilds is that since they’re just a group of people with a common goal, and since it’s so easy to talk via chat and video call, you too can help form guilds in your company: no top-down approach required.

You may be wondering why we’re covering guilds if they don’t need a manager to form them. The reason that they’re worth covering is that they’re another useful tool for you to suggest to your staff to solve common problems, which in turn increases their confidence and autonomy. You’re also well-positioned as a manager to help connect others as guilds get off the ground. You may also want to get involved yourself!

Guilds concern themselves with the following matters:

• Discussion and progression of best practice across an interest or discipline.
• Information sharing across multiple teams.
• Improving the visibility of that interest or discipline within the company.

For example, you could have guilds that concern themselves with the following:

• How the department uses JavaScript, from standardization of use of particular frameworks, code ownership of shared utility libraries, to owning the department-wide linting configuration to ensure that code looks and feels the same regardless of the author.

• Visibility and promotion of security throughout the development process. Each member of the guild brings back the best practice and knowledge to their own team and raises any concerns from the team up to the guild to discuss.

• Unity of design and UX practices across different teams and products.

• Championing of diversity and inclusivity across teams, culture, and the hiring process.

Guilds don’t have to be all about code and frameworks. In theory they can be about anything that contributes to the company and its culture. One of the most widely known implementations of guilds is at Spotify,^[10] where guilds are only a small part of how they subdivide agile teams. Since Spotify is a large and forward-thinking company with regards to team structure and agile methodologies, they have the following named groups of people:

• Squads, which are cross-functional development teams.

• Tribes, which are collections of squads that work in a related area, such as infrastructure.

• Chapters, which are groups of individuals of a common skill set within tribes.

• Guilds, which are groups of individuals across the whole department with a common interest.

It’s easier to collapse the latter two into just “guilds” for the purposes of this book and for your initial implementation. The Spotify implementation of this structure also has implications for line management, which aren’t necessarily of interest to us right now, but you can read their white paper in the footnotes if you’re interested. For now, let’s just stick to a guild being a group of people that share a similar skill set or interest.

Helping to form guilds may be a good choice for you if you hear the following common concerns:

• That teams are reinventing the wheel because they were unaware that there was code to reuse elsewhere.

• That technology choices are beginning to diverge because it’s easier for teams to go their own way rather than learning about what’s going on elsewhere in the department.

• That there are unexpected surprises (with design, compatibility, speed, and so on) when teams commit their work into the main codebase.

• That engineers are feeling disconnected from what other teams are working on.

Guilds can help you out greatly here, giving those that participate a chance to share information, raise issues, and have others help work through individual and collective problems.

If you’re thinking of starting a guild for an interest or skill set then it’s as simple as having a conversation with others who share that interest or skill set and beginning to meet up. Here’s a handy list of things that you can do that can get a guild off the ground. Remember that it doesn’t have to be you that gets a guild started. This is simply a tool that you now know to encourage anyone within your team or even your whole department to try out.

• Announce the guild’s intentions. Simply sending out an email or chat message is a good way of getting started. Outline what the guild is for, highlight some of the reasons that it would be beneficial, and solicit interest from others in the department. Guilds can operate across a spectrum, spanning from sharing and discussion to action and delivery. Make it clear where this particular guild sits.

• Choose the members. From those interested, try and get a good balance of people so that as many teams are represented as possible so that the core group isn’t too large (it helps to have the core guild function represented by a smaller group, but anyone else can contribute) and so that potential members will have the time to contribute properly. It’s natural to think that a JavaScript guild needs all of the most senior engineers to be part of it, but less experienced engineers can learn a lot by participating and also can have more motivation and time to contribute.

• Choose a leader. The leader doesn’t have any explicit power over anyone else, but someone needs to be responsible for setting up and running the meetings, coordinating the discussion, and keeping documentation up-to-date.

• Choose a time to meet. Depending on the people in the guild, it may be that most discussion happens asynchronously. However, having touchpoints where the guild gets together to discuss pressing issues, even if it’s just once a month, is invaluable for creating rapport between the members and also giving the guild momentum.

• Create the communication channels. Again, your mileage may vary. Perhaps a public chat channel would suffice so that anyone can participate. Maybe a mailing list would be better suited to the company. Optimize for reaching the largest number of people with your communications, since that increases the output and impact of the guild.

• Decide how to document the guild’s work. Think about where you’d like to store any documentation related to the guild, such as meeting minutes, information about the guild and how to contribute, and the outcomes of any decisions that have been made.

Guilds may not last forever. Sometimes a guild has served its purpose and may need disbanding or merging into other guilds. Alternatively, guilds may grow and need partitioning into subsets with more specialized focuses.

Going back to our networking analogy, guilds are a good example of multicast communication patterns in your department. As you participate in guilds, think about their output. How can you spread the knowledge and progress of the guild further? Perhaps you could have a monthly broadcast email that keeps the rest of the department up-to-date with what you’ve been working on. Another good broadcast strategy that you can start from the bottom up is getting technical talks going. We’ll look at that next.