A lot of people heard about the Spotify company structure of Guilds and tribes. We at Wix.com have a similar structure that has evolved over time and been 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 four developers to a about 100 back-end engineers in the back-end guild.
The Evolution
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 (four 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. Over the course of a year we only recruited four senior engineers. While this is very slow, at this stage of the company it was very important that we only picked the best; these were the core engineering team that would help to build and shape the Guild and the future engineering culture of the company.
At this point, when we had around ten 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 continued to grow (doubling the number of people every year) we saw that we were very good at focusing our efforts on areas where the company had, at that point, decided to invest. However, we were neglecting other products as they had to compete for shared engineering resources but didn’t take priority.
We then realised that we needed dedicated engineers for each product group (at least for the big ones). We still didn’t have a name for it, but I had essentially dedicated some developers to specific products while other developers remained shared resources.
As Wix continued its growth, we had different groups of people who worked on different projects and were less engaged with each other. So what we started to do was to formalise our engineering culture. While we always had a strong ownership and DevOps culture, we started being involved in knowledge sharing activities to keep our engineering teams cutting edge so they could 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 realised that while we didn’t have a name for our current structure it resembled Spotify’s. So we adopted some of the naming and agreed that we should be working with the 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 others 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. We realised then that having dedicated engineering teams (Gangs) was not enough – 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.
“Companies” and Solidifying the Guild
So once more we had to evolve and created, what we now call, a “Company”. A “Company” is like a startup within Wix – it has all the resources necessary (developers, product manages, analysts, UX engineers, marketing etc.) in order to progress quickly and create the best product possible, regardless of the other products at Wix.
At this point the Guild also had to take on more responsibilities. While we wanted the “Companies” to progress as fast as they could, they also has to maintain alignment with Wix as a whole. Another issue found was that we expected these “Companies” to create products that compete in the free market, with other startups and big companies, but with limited resources.
Now, the Guild 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 competing with whole companies that are doing the same product with more resources. So the Guild now takes another responsibility in taking care of all the infrastructure, deployment pipeline, and core services that all the “Companies” share. For example, if there is a service needed in more than two companies (e.g. 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.
In order to keep alignment with the other “Companies”, make it easier for engineers to move between “Companies”, and share knowledge and best practices, all the “Companies” share the same infrastructure and methodologies. This is a tradeoff between freedom and velocity. You loose some freedoms but gain a lot of velocity as many of the things you need for your service are already there for you.
Now a “Company” may decide (in coordination with the Guilds) that using the existing infrastructure is the wrong solution for the product they own, and they want to develop on a different stack. They can do that, however they will need to take full responsibility over the whole application lifecycle, deployment, monitoring and integration with the other Wix ecosystem. Having to develop all the infrastructure on their own is a lot of work and usually time to market will be very long. So almost every “Company” opts to use the current infrastructure, although we have several cases where it was the right decision to develop some products on a different stack .
So, if I was to describe the line of responsibility between a “Company” and a Guild, I would say that a “Company” decides what to do, and the Guild says how to do it.
With the addition of “Companies” to Guilds, the Guilds now need to assume more responsibilities in addition to those mentioned before.
Align between “Companies”. The Guilds are horizontal while “Companies” are verticals.
Support the engineers working in the “Companies”
Guidance and review
Develop shared infrastructure
Improving development velocity
Temporarily help “Companies” in need with additional resources from the Guild.
Guild Masters
Guild masters are senior engineers whose responsibilities include supporting engineers in different “Companies”. Guild masters conduct reviews, training and mentoring. Additionally, since they are horizontal and work with many companies, they identify common issues, duplication of code between companies, understand the development bottlenecks and try to solve them. As a result of that they also pollinate “Companies” by bringing the best practices and lessons learned from one to the others.
Guild activities:
In order for the Guild to be able to take on these responsibilities, it needs developers’ time. So, at Wix, twenty percent of engineering time is dedicated to Guild activities.
Every Thursday we have a Guild day in which the Guild conducts training activities and Guild tasks. All the engineers from all the “Companies” are assembled in one place for the Guild day.
Here is the back-end guild day schedule:
10:00-11:00 – Guild retrospective where we discuss engineering dilemmas and lesson learned across “Companies”.
11:00-11:15 – Break
11:15-11:30 – Project spotlight – where someone presents a new project that is being worked on, some lesson learned and challenges they have faced
11:30-13:00 (usually not the whole 1.5 hours is needed) – Tech talk, which if it does not contain any sensitive information is also open to the public at a meet-up.
13:00–EOD – Lunch and Guild tasks. (The guild tasks are called “Games of Gangs”, but “Games of Gangs” we’ll discuss on another post).
This is just a small part of the story. I recently gave a talk at Devoxx UK about how Wix has evolved the company structure and the architecture to better scale its engineering department (and the whole company) to allow rapid software development which you can check out if you’d like to know more.
The post The Evolution of a Guild appeared first on Voxxed.