At Welcome, our software teams are organized into squads composed of full stack engineers, a product manager, and a product designer. This structure helped our team focus on a single part of the platform, obsess over customer problems, and ship products autonomously to solve these problems.
However, as with any team structure, were some shortcomings. Most notably, best practices from different squads didn’t always make their way out, and a lot of cross-cutting concerns were not being prioritized. To solve for these deficiencies, we decided to complement our squads with the addition of engineering guilds.
How we use engineering guilds
We define an engineering guild as a group of engineers with a common technical focus and a goal of sharing best practices with the rest of the team. The purpose of a guild is to implement positive changes to an area of our platform. Guilds can also be thought of as the connecting tissue between the squads, giving engineers the ability to:
- Collaborate and communicate outside their squad.
- Discuss, evangelize and learn specific technical topics.
- Share knowledge and best practices across the entire engineering team.
- Help Welcome engineering develop reusable patterns for cross-cutting concerns.
Squads focus on products and guilds focus on specific technical topics that span multiple squads.
Some examples of the guilds we’ve implemented include the Design Library Guild, which is responsible for building reusable react components, the Performance Guild, which standardizes performance measurement across our platform, and the Testing Guild, which is responsible for improving our tests.
Ingredients of a guild
Implementing guilds are one thing, but making them truly effective requires following a few best practices. Here are some of the elements that we considered when introducing guilds in order to increase their chance of success.
Setting a mission is the most important aspect and a basic requirement when first creating a guild. Missions should serve to ensure:
- The guild exists to serve the needs of the organization, and that emphasis is placed on learning about emerging technologies, as well as (and perhaps most importantly) how to apply them to the tech stack.
- The guild helps to solve a problem or a set of problems that the team is grappling with.
- The guild’s work alleviates the concerns of many.
The overall mission of a guild is ongoing, so there should be a list of smaller goals that ladder up to the guild’s general objective. Here are some tips to keep in mind:
- Goals should be set at a periodic cadence (e.g., our guilds set goals quarterly).
- Goals can range from generating a pattern that solves a problem, to applying an existing pattern to a use case.
- Tactical goals can be set around concrete changes to your platform (e.g., upgrading a version of your application, improving performance to a certain part, etc.).
- All goals should have a well-defined outcome that can be measured (e.g., improve performance by 5%).
Every guild must have a coordinator. The coordinator should ensure that:
- The guild’s goals are set.
- The guild is meeting at a regular cadence.
- Everyone on the guild is held accountable.
- The work of a guild is recorded so that it can be shared with the rest of the team.
- Any changes or updates are communicated to all teams.
Membership to a guild is not a long-term commitment, but there should be a minimum period of time required so that team members don’t switch too quickly. Mapping membership to guild goals is a suggested best practice to ensure that the guild can be successful in achieving its goals without worrying about membership fluctuations. If a guild has quarterly goals, then members should commit to the guild for at least a quarter.
Some additional practices we follow at Welcome include:
- Everyone is encouraged to be a member of at least 1 guild.
- Since we have teams in New York and Dhaka, we urge all guilds to have members from multiple geographies.
- We emphasize and encourage members to share their knowledge across their guild.
How do you communicate and spread knowledge within guilds? Here are some examples of the processes that we use at Welcome. You’ll notice that we rely on a mix of technology and face-to-face meetings to ensure all lines of communication are open. (Note: Some of the tools are specific to our tech stack, so feel free to use the tools that are available to your team.)
- Public Slack channel: This allows others to ask the guild questions, which is important since one of the guild’s primary purposes is to share knowledge.
- Guild meetings: These are organized by the guild coordinator at some pre-defined cadence to:
- Discuss topics pertaining to a guild’s focus and talk about the latest trends and patterns.
- Provide updates on a guild’s work.
- Plan and assign a guild’s work.
- JIRA Board: This provides transparency into a guild’s work and keeps members accountable.
- Confluence page: This is an internal, public page that documents the guilds’ missions and goals, and allows for sharing best practices with the rest of the engineering team.
What have we learned from our guilds?
After 6 months of operating as guilds, here are some of the key learnings we’ve come across since we first rolled them out:
- Be prepared that some guilds will fail. As long as the failure rate is low, you should accept this as part of adding guilds to your team structure.
- Not all guilds will be equally successful. However, if there are some strategic initiatives you plan to run through guilds, make sure that they are on track to succeed.
- The team needs to set aside time to do all of their work. (We allocate a full day every sprint for the team to focus on their guild work.)
- Create a mechanism of accountability across guilds early. (We didn’t have this set when we first started, but have since introduced ways to promote accountability. For example, we implemented a “Guild fest” where all guilds present their quarter’s work to the entire team.)
- Be open to feedback and be prepared to change the process depending on the culture and operations of your team.
- Make sure that there is someone who manages the guilds. This person must be able to:
- Sell the idea of guilds to the team and the organization at large.
- Own the process and guidelines for guilds.
- Hold the guilds accountable and make sure they aren’t underperforming.
If your team structure is not set up to efficiently solve cross-cutting concerns, and you have identified that things are falling through the cracks, then we highly recommend giving guilds a chance. Plus, it will help your engineers grow and give them additional avenues to build expertise and pursue technical interests. As with anything, you should figure out a way to make it work for your team and the broader organization.