Why does ONE ZERO need guilds?
The whole guild project started when I moved between teams. When I joined the new team, I realized they had a long way to go before they'd reach output like the first team's. It was clear to me that if we wanted to move fast, we needed a process for sharing knowledge between teams, so we could learn from the first team about things it had already dealt with and save precious time.
We realized the purpose of the guilds in the organization was to bring order to the chaos. We were missing a cross-functional team that would handle the things that hurt everyone. A team that would build infrastructure. It was clear to all of us that we were moving very fast, so there were places we never had time to go deep on. Before the guilds, whenever something needed in-depth work, one of the teams would stop its day-to-day work and focus on it. To avoid that, we wanted to build a body that would handle this on an ongoing basis. On top of that, we had 6 teams, and we wanted them to speak the same language. We realized we needed to create a shared standard for working together. Another point that mattered to us was onboarding new employees. Until then, we had no structured process. New employees could land on a busy team that wasn't able to give them the knowledge they needed when they started. That can be an unpleasant way to enter an organization, and we wanted to change it.
How were the guilds set up?
At first, my idea was to build a learning community. The motivation was to let people keep learning and growing within a defined framework. Beyond that, a learning community creates a commitment to learning, as well as connections between people. It mattered to me to move from a focus on solving problems to a focus on sharing knowledge. For example, if we're working with a particular technology, passing the knowledge our team has built up on to other teams.
I pitched the idea to the CEO as a win-win for everyone: employees feel the company is investing in them, it enriches the organization's knowledge, and in the end it produces better programmers. He loved the idea and said, "That's a really great idea. I've always wanted my organization to be a learning organization." We had a green light to start! I began meeting with the relevant people (the CTO, the Chief Architect, the group lead and others), and together we shaped what we needed and wanted to build.
We started with a regular conversation between me and the lead of the second team, where we'd fill in the gaps and share what each team was working on. From there we moved to a weekly meeting, a tech talk. Each team sent a representative who gave an update on the day-to-day work: solutions to problems we'd run into, what we'd focused on that week, and where we planned to go technologically. Through those weekly conversations we saw the need for sharing and its value, and we started thinking about how to take it a step further.
What are the guilds and how do they work?
We have 4 guilds: Backend, Knowledge, Data and Quality.
The Backend guild focuses on building infrastructure and reaching the places the development teams don't have time to get to.
The Knowledge guild focuses on creating knowledge that helps employees use new systems and technologies more easily. It supports the Backend guild. Say a decision is made to adopt a new tool: their job is to produce talks and workshops on how to use it.
The Data guild owns the organization's data. It brings together all the places where data lives in the organization and works on how it can be channeled into additional uses.
The Quality guild focuses on the quality side of the product. It does work parallel to the Backend guild, in the world of QA.
Each guild has protected time, which varies from guild to guild. At first the rule was one day per sprint dedicated to the guild, and over time that changed to fit each guild's needs. The Backend guild, for example, meets for 2 days across 2 sprints, while the Data guild meets once a week. What really matters is setting aside time when people can't be pulled back into day-to-day work, time that managers and leadership have agreed to. Today it's a given: a guild day is time you don't touch.
Beyond that, once a quarter we hold the guild fest, which all guild members take part in (everyone's invited). It's a real event. We all get together and make a whole celebration of it. At the event, each guild master presents the goals and tasks their guild worked on over the last quarter, and we set the goals for the next one. Every quarter we define anew where we want to go and what we'd like to push forward that quarter. We break those points down into goals and tasks, which go to leadership for approval, and from there we're off.
When did you know the guilds were working?
The moment I knew it was working was the first guild fest. About 100 people from development, all the guild members, gathered in the kitchen, and each guild master presented what their guild had done over the last quarter. It was simply moving. Seeing all our talk and planning turn into something real and whole, and seeing the work done in each guild, was amazing. Far beyond what I expected.
Day to day, we see a high level of participation in the guilds. A lot of people take a really active part. We also track certain metrics on an ongoing basis. For example, one of the metrics we set a KPI for is onboarding. We decided we wanted everyone who finished onboarding with us to say, "This is the best onboarding I've had in a long time!" And we really got there. There are other metrics we aim for, such as social media reach and satisfaction rates for the talks given to the teams. On top of that, in terms of process, we see people using the tools and processes the Backend and Quality guilds produce.
Cracking the win-win: how do you make sure both the guilds and the organization get value?
The win for the guild
Guild members grow technically, personally and socially. The Knowledge guild, for example, helps people build talks, from the idea to the dry run before the talk, and even with writing the LinkedIn post once the talk is done. It also creates a more pleasant work environment: guild members build connections and friendships with people from other teams.
The win for the organization
The guilds create standardization across the organization and let us go deep in the places that matter to it. Beyond that, they develop our people, and employees feel the company is investing in them and in their learning.
What challenges did you face?
- A major challenge early on was recruiting guild masters. I led one guild, but we were still missing 3 guild leads. I looked for people who were really passionate, because you're leading something that doesn't exist yet. People I could trust, who spoke a similar language and could understand my goals and where I wanted to get to. I look for someone who knows how to rally people and how to turn the guild's goals into real tasks. It's not easy work. Beyond that, the first guild master matters enormously. They set the initial voice and tone, and they do the first round of rallying people. Whoever takes it on has to connect with the concept, with the professional side and with the personal side of the role.
- Another challenge is bringing employees into all the guilds. We don't require people to take part; it's up to them. Some guilds don't have this problem: everyone wants to be in them. The Backend guild, for example. We research new technologies there, and that work can be more interesting than the day-to-day. With the Knowledge guild, on the other hand, we really have to rally people to join. Sometimes people are nervous or shy about giving a talk, and that takes work. This quarter, for example, we want the talks to be more business-oriented, beyond just technical. So I'll approach the product people and try to bring them on board. They're usually very busy, but once they're guild members with time set aside for it in their work week, it removes barriers and helps me bring them in.
- How do you give value to both new employees and veterans? For new employees, the guilds can be a great springboard: a way to meet more people, learn and build expertise. Veterans, on the other hand, work on the more foundational infrastructure technology, because they know it in depth and it's very interesting work. They also teach the new employees, and through teaching they learn themselves and become even more expert.
Tips for a successful community
- Leadership support. Without it, this simply won't happen. If people don't have time during the week to dedicate to the guild, it can't happen. There are always new features, production issues, or just sick days and personal matters. Once you set aside time for it and everyone knows it's part of the sprint, it happens.
- Understand that the guild has to serve the organization and its goals. That means every guild will look different. You can't copy-paste, because it simply won't work. The guild has to fit the goals of the specific organization it's part of.