Search

Building a Guild



A lot of people heard about Spotify company structure of Guilds and tribes. We at Wix.com have a similar structure that has evolved over time and influenced by their ideas, however we have our own interpretation of the structure and the role of the Guild.


In this article I will try to walk down memory lane and describe my experience in building the first Guild (back-end JVM Guild) in Wix, which is now the role model of all the other Guilds at the company, and how it has evolved from the time I joined Wix when we had one back-end team of 4 developers to a about 100 back-end engineers in the back-end guild.


The Guild model did not start right away, when you are a relatively small startup all you have is teams, and this is exactly what we had. We had one server team (4 engineers) that was basically responsible for all the back-end development at Wix. As there was a demand for more back-end engineers the team grew very slowly. As with a small startup the recruitment process was very picky and we were only looking for the best engineers. At the course of a year I have only recruited 4 senior engineers. While this is very slow at this stage of the company it was very important to pick only the best engineers you can find, as these are the core engineering team that will help to build and shape the Guild and the engineering culture at the company in the future.


At this point where we had around 10 engineers we were pretty much functional teams, where everybody knew almost everything and I could move people from project to project according to the company's priorities.


As we continue to grow (doubling the number of people every year) we saw that we are very good in focusing our efforts in some areas where are that point the company decided to invest, but were neglecting other existing products that had to compete on shared engineering resources but without any priority.


At this point we realized that we need dedicated engineers for each product group (at least for the big ones). We still didn't have a name for that but I had essentially assigned some developers to be dedicated on some products while the other still remained shared resources.


As Wix continued its growth we had different groups of people who worked on different projects and were less engage with each other. So what we started to do is to formalize our engineering culture. While we always had a strong ownership and DevOps culture we started more and more being involved in knowledge sharing activities in order to keep our engineering teams on the cutting edge and learn from each team's experience.


At this point we started to have discussions about how to structure the company. We looked around and found the Spotify paper. We realized that while we don't have a name for our current structure it resembled to what Spotify had. So we adopted some of the naming and agreed that we should be working at a form of Guilds that are defined by a profession; and Gangs, which are the product teams. Initially we only had the engineering Gangs who were dedicated to a product with all the other as shared resources across products.


This was the point where the role of the Guild had started to form.


The Guild is the one who is responsible for the person's profession thus the Guild has the following responsibilities:

  • Recruitment (Hiring and firing)

  • Assignment to product teams according to the company's priorities.

  • Setting the professional guidelines.

  • Training.

  • Set the engineers compensation (salary, bonuses etc).

  • Create an engineering brand for the company.

  • Be responsible for the professional development / career of the engineers.


As Wix continued to grow we started to have more and more projects and product teams. What we realized then is that while having dedicated engineering teams (Gangs) is not enough because there was a bottleneck on the other shared resources. Also we had multiple products that had a common domain. What we wanted to do is to give as much independence to each product domain / vertical.


So once more we had to evolve and created what we call now a "Company." A company is like a startup within Wix, it has all the resources it needs (developers, product manages, analysts, UX engineers, marketing etc) in order to progress fast and create the best product they can do regardless if, the other products at Wix.


At this point the Guild also had to take on more responsibilities. While we want the "Companies" to progress as fast as they can, the "Companies" also has to keep alignment with Wix as a whole. Another issue is that we expect these "Companies" to create products that compete in the free market with other startups and big companies, but with limited resources.


The Guild now needs to play a big role in enabling the success of the "Companies" within Wix. If each "Company" had to develop everything on their own, for instance the frameworks, deployment, taking care of the infrastructure, monitoring etc. they would not stand a chance to compete with whole companies that are doing the same product with more resources. So the Guild now took another responsibility in taking care of all the infrastructure, deployment pipeline, and core services that all the"Companies" share. For instance is we see a service that is needed in more than two companies (for example mailing service), we develop it in the Guild (which has its own core services teams) and all the other "Companies" can use this service, thus focusing only on the product itself and not having to worry about the infrastructure.