Why does Wix need guilds?
Wix is a huge company with hundreds of developers. For the company to keep growing and moving forward, you need standardization in how people work and a high level of collaboration, alongside the autonomy each product group needs in order to deliver. Guilds are a flexible model that lets the organization balance autonomy, collaboration and company-wide standards.
How did the guild get started?
The guild came about naturally, as part of Wix's evolution as a company. I was the first team lead at Wix 12 years ago, back when we had just 2 teams: Server and Frontend. As Wix grew and more product groups were added, members of my team started moving to other product groups. I realized I needed a way to do 2 things at once. On one hand, collaborate with other groups and feel comfortable sending my engineers to work on other teams. On the other, preserve the team's culture and, just as important, the methodologies we'd built and the level of excellence we'd reached through hard work. That's how I created our professional community. The emphasis was on sharing knowledge and methodologies. We worked this way for about 2 years, until Spotify published its famous white paper on its guild model. That's when we realized we were working in very similar ways, and that we had actually built guilds too. It came from the ground up and grew from there.
As the company kept growing, we realized, by then with the backing of global management, that this model had to run formally and company-wide. Until then it was just something that happened. Once we understood it had a name and that it worked, we set out to put it on the organizational agenda, and we wanted to do it in a meaningful way. We invested time and money in it, and after a lot of debate we agreed that 20% of developers' working time would go to guild activities (working on other teams, building professional excellence, learning, contributing to infrastructure and so on). It wasn't an easy decision. There were debates and there were fights. But to me, 20% is the minimum for a guild to be meaningful. Anything less is more of a hobby, or a nice-to-have with no real impact.
The first formal guilds started in engineering, but today every domain at Wix has a guild (Backend, Frontend, Mobile, QA, Product, UX, HR, Security, Legal and so on).
What is an engineering guild and how does it work?
A guild is a community that brings together people who share the same profession but don't sit in the same product group. At Wix, product groups work very independently. We call them companies or groups, and each one operates like a startup in every sense. The guild is the professional community that unites everyone in a given profession (Backend, for example), no matter where they work inside Wix day to day. People have a dual affiliation: professionally they belong to the guild, and for their day-to-day focus they belong to their group. On top of that, guilds sometimes take on sub-topics, and each guild has smaller groupings within it, like a development managers' forum.
Because it's a professional community, part of what we do is seminars, enrichment days, talks, and a lot of learning and knowledge sharing. What makes our model unique is that it's an "operational guild." Its purpose goes beyond sharing knowledge: it actually sets the professional standard in each domain, and the guild and its members become stakeholders in the company within their field. The guild recruits, for example. Each guild has to be consulted on raises (because the professional standard is defined there). It also has goals and it delivers. A guild might take on a goal like making the organization's work processes easier.
A big part of what guilds do is develop standards. The Product guild, for instance, owns the Wix product book, which lays out in full what product development at Wix looks like and what's expected of every developer. This comes out of deep work we did and keep doing. We actually took people, placed them in the different groups, learned the work there and the needs and pain points of each group, and gathered feedback. Based on that, each guild can set the professional standards within Wix and build tools and processes that help every group in the organization. This isn't some ivory tower deciding top-down what everyone does. A guild is everyone, it belongs to everyone. It's an ongoing working group with representatives from different teams across the organization. Once the standards are in place, we spread that knowledge across the organization and embed it, through the guilds as well, of course. We want to share the knowledge we've built up and worked on. What happens in the guilds shapes company-wide work processes at the global level.
In terms of structure, it's important to note that every guild looks different (and each has hundreds of members). Engineering guilds, for example, are built around a leadership group in which each member owns a specific area (recruiting, onboarding and so on). Under them are people handling operations, development, infrastructure and more.
Measuring success is tricky, because knowledge is hard to measure. We know we're producing better engineers. What we do measure are the improvements we make to Wix's infrastructure, the ones we identify as needed based on feedback or needs coming up from the field. Those you can measure. Did I improve development time? How much time did I save the groups by handling something centrally that each of them would otherwise have handled on its own? That's how we define KPIs, and it also creates standardization.
When did you realize the guild was working?
I never expected this idea to succeed the way it did. It caught on inside the company, and then it caught on across the industry. There's hardly a company in Israel that hasn't come through Wix, or through my office, to learn about this model. I also didn't expect this level of support from management, with the CEO saying outright that the guilds are one of the secrets of Wix's success.
When we built the model, we never forced anyone to join. It was always voluntary. I remember that even at the very beginning, people who weren't part of the team the guild was created for suddenly wanted to join. We also see the guild's goals being met. For example, instead of developers leaving, working in guilds really helps with retention, because people get exposed to other groups and realize they still have a lot of room to grow. Most internal mobility happens after guild members spend a "guild week" working closely with another group, getting a "taste" of what goes on elsewhere. We get a ton of feedback that people stay at Wix because of the guilds, since it's such a unique model in the ecosystem and gives so much professional value.
Cracking the win-win: how do you make sure both the guild and the organization get value?
The win for the guild: professional value and personal growth, connections to other groups, and a path to lateral career development within Wix.
The win for the organization: better company-wide ways of working, a consistent and high standard, time and money saved, employee retention and internal mobility.
What challenges did you face?
- Early on, when we were trying to define what a guild is and how to make it truly meaningful in the organization, there were endless debates, not to say fights, over how much time developers would give to guild activities. We eventually settled on what I saw as the minimum, 20%, but it was very hard. Development managers wondered how they were supposed to work with developers who, technically, were only with them 4 days a week. Developer time costs a lot of money and can hold up product development. In the end I convinced them to try it for a few months and see that it brings value despite the challenges. In that short time we showed that the organization could work better and more efficiently. We developed methodologies and taught the organization how to work. We were the first to do this, and there were no methodologies or tools. That, by the way, is one of the values that still guides us: the guild is not a mandatory model in the organization, it has to keep showing that it brings value.
- There's sometimes a fear of standardization. Teams and groups can be attached to their own way of doing things. That's why it's important to do it well and to know where to stop. You have to walk the fine line between what you standardize and what you leave alone. At the same time, Wix is a huge company with hundreds of developers. You have to create standards, or the company gets stuck and can't move forward.
- Leading a guild is a real challenge. There's a built-in conflict in guild work. Guilds speak the language of quality and standardization, while groups speak the language of delivery and deadlines. So developers who lead a guild have to balance those 2 forces and find the middle ground. That means motivating people without formal authority, getting them on board, and constantly showing that the guilds bring value.
Tips for a successful guild
- Enthusiastic support from management, together with a real commitment of time and money. We dedicated 20% of everyone's working time at Wix to guild work. That's a serious commitment, and luckily management supported it wholeheartedly. If you don't have enough time to do something that brings value, why do it at all? It's just a waste.
- Keep looking at what's working and what isn't, so you bring value and justify the guild's existence. That's true with management, with guild members, and with the whole organization, which wants to see results.
- Invest in the social side of the guilds. Of course there are fun days, company parties and all that good stuff, but at the end of the day we build close relationships between guild members by working together. For example, we have a "guild week," when guild members get to work on a completely different team or on guild-related projects. We try to do it in pairs, ideally of people from different groups, so there's a chance to meet and connect with new people. That's a kind of KPI we watch: figuring out how to connect people and encourage them to do a guild week.