First, What are Guilds?
Guilds, have been popular for a while, I think they gained their popularity mainly from Spotify, but they existed before with different names, such as: Interest groups, Working groups and so on…
Thanks for the intro Raz, but What are Guilds?!?!?
Instead of saying it in a shitty version, I’ll quote this article here: https://medium.com/webcom-engineering-and-product/agile-guilds-the-yodle-way-47dc00f6cd3a
A guild is a group of people who work on different feature teams and meet with some frequency to discuss a specific competency. Feature teams are multidisciplinary teams that are organized to create a product or feature in a product. For example, an engineering team may have an architecture guild rather than having an architecture team. The difference being that an architecture team sits together and primarily interacts every day with each other, while an architecture guild’s members sit with different feature teams and focus on the goals of that team, while also having a focus on architecture.
Why Guilds?
Each one of your feature teams (assuming you have them) is operating in a confined space, where ideas and learnings don’t flow between them usually, this helps each team to achieve their goals in a focused way…
It’s not a bad thing, this mode of working helps each team to achieve their goals and to reduce noise.
So this way of working is great to achieve goals, but, it doesn’t enable people to communicate with other members in a different team outside of their feature team in an organic way to talk about what interests them
A grass-roots movement at Wikimedia realized that they share an interest related to accessibility, the idea is to support that more and to allow people to do that and institutionalize it
The Typical Guild Model
Most agile companies (especially ones practicing scaled agile) have guilds that focus on a specific competency. The guild members are completely decentralized — meaning they work on separate teams, report to different managers, and are deeply familiar with the product and customers that their feature teams focus on. According to Scaling Agile @ Spotify, these guilds only organize “to share knowledge, tools, code, and practices”.
This construct has worked well for many companies. Feature teams still have access to services that would classically have been provided by centralized teams — in fact, they now have greater access, with less effort, and with more perspective because they are sitting next to the person who provides it and is in standup meetings with them every day. The individual guild members still have their centralized competency specific mission and now have the added benefit of seeing how that mission is realized by seeing the impact of their work first hand.
How do you get there?
Easy, The Accessibility group at Wikimedia paved the way and made it realize how easy it is, You basically should allow people some time to create channels on Slack/email groups, maybe scaffold a meeting every X weeks if they need it, to discuss those things, to tell people that they are encouraged to do so…
To empower your employees to share knowledge and ideas, to give them a framework of how it works (what does it mean? how much time is allowed to spend? do we have a budget? and so on).
The idea is to allow people to learn, share info, grow in the direction they are passionate about and in the end infuse their team with the knowledge they acquired in the guild they are a part of.
The motivation for an org?
Aside from having knowledge sharing, to enable conversations between members, Guilds have the power to also shape your culture, if you want to drive DevOps culture, DevOps guild is a good way to do that in a non-intrusive way, alongside hiring the right people, you give them a space to share their thoughts with the rest, without them telling others what to do, but rather share ideas and let others learn…
One last thing – Survival of the fittest
As a manager, we also need to enable guilds to die if they have no traction, no need to force them, if a guild doesn’t work, it’s OK to try again, support it more, but also to allow a guild to disband… it’s not a failure if a guild had a good run, but then the members didn’t have what to talk about anymore.
Some real-life stories
At Wikimedia, we posted our guild model, guidelines and enabled people to suggest guilds, this was such a win to see all those guild proposals
What are the areas it should improve?
- Architecture – if we will have an Architecture Guild, that might be the right replacement to having an Architect… people that share ideas and share knowledge between the teams.
- Frontend Engineering- As we have 2 different teams using VueJs, knowledge sharing between those team could be great
- Frontend Spec, Design, Prototyping- A Dev/UX/PM guild about creating and communicating about what our users see from our products.
- Performance
- Databases
- Testing
- Analytics
- Dev-Ops
- Management
- Wiki* culture
- Accessibility – Making our products accessible to diverse users. (There already is a working group)
- And so many more things that I’m not smart enough or creative enough to think about!
The wish is to create a system to allow people’s ideas to flow into the day-to-day, but without disturbing the day-to-day.
To give people space work in a focused environment, but also, have a point of passion.
Somehow I Manage 