Why does Lemonade need a Frontend guild?
The Frontend guild brings together people in a single professional discipline. At Lemonade, work is organized in squads. Unlike functional teams (a development team, a QA team and so on), a squad includes all of those professional units and can work autonomously. A squad might include Frontend and Backend developers, an analyst, a QA person and a designer, and they can work on their own without dependencies. That's great for efficiency, but it can also feel a little lonely at times. On top of that, a developer's manager may not come from the same professional field, which makes it harder to give that developer the tools to grow professionally. In that situation, developers will handle their day-to-day tasks, but they'll find it harder to develop and grow in the organization.
The guild format addresses that. It brings together Frontend developers from different teams, and there they can share experiences from their daily work, talk about and learn new technologies, share best practices, and enrich each other's knowledge through talks and by going to conferences together.
How did the guild come about?
When I joined Lemonade 3.5 years ago, the company had 30 developers, 6 of them in Frontend. We worked in a squad model, so every Frontend developer had their own domain. We wanted to figure out how to ensure shared code quality and how to create consistency in the code and in the standards we wanted to set at Lemonade. So we started meeting weekly in a forum called the Frontend Guild Meeting. Each meeting opened with everyone sharing what they were working on, a kind of daily standup just for the Frontend people.
The guild also matters because it reduces fragmentation in the code. Without forums like these, you can end up with 2 Frontend developers working in 2 different technologies. That can work for an organization in its early days, but a year later, as the organization grows, you have 2 technologies and the fragmentation can get very large. It hurts recruiting too, since you need to hire developers for each technology. It also hurts our ability to grow and ship new features quickly in the future, because we can't move people between teams quickly when we need to. That can really hold back the organization's growth.
The Frontend Guild Meeting was a place for:
- Developers to talk through and get advice on problems they run into day to day, for example when their team lead doesn't know a particular technology.
- Planning the future of Frontend. Since there was no Frontend architect or anyone leading Frontend, it really was a community, and we talked about how we wanted Frontend to look in the future.
- Understanding how Frontend fits into the company's projects and changes. When there was a requirement to change the architecture and we wanted to understand where Frontend fit in, we held a discussion focused on how we were going to have an impact and what tools we needed for the company to grow well.
What is the Frontend guild and how does it work?
When we started out, we were 6 Frontend developers. Over time the company grew, more and more developers joined, and we realized it no longer made sense for everyone to share what they were working on in a forum like that. So we split the weekly meetings into sub-guilds by area. That means everyone working on user-facing products meets once a week for that standup, and everyone responsible for the back office does the same.
We also upgraded the classic guild meeting into an enrichment session. Every 2 weeks everyone gets together, and we have a range of topics we want to talk about, whether they relate to the company's technology or are purely for enrichment. This gives guild members several things: learning new things, picking up soft skills like building presentations and public speaking, and checking whether the technology they're presenting could be adopted at the company. It works really well for us. We record all the talks and recommend that every developer who joins the company watch them. We even add translation so they're useful for English speakers too. It adds a lot to the guild.
Lemonade is structured as mini companies, each focused on a particular area, for example a mini company for pet insurance or car insurance. Each mini company has a Frontend tech lead who takes part in running the guild. I lead the guild together with a team of Frontend tech leads. Together we make decisions, keep our developers updated and involve them in decisions as much as possible.
As the guild lead, I'm more connected to the company's stakeholders and to where we see the company a few years from now, both in terms of technology requirements and in terms of the people we need in the organization to lead the changes we want to make. I pass that knowledge down through the teams.
The guild's goals fall into 2 types:
- Classic Frontend KPIs: how fast our pages load and how fast developers can ship new features. We always measure these and see change in them.
- How satisfied developers are day to day. That's made up of how much they feel they're developing and thriving in the organization, and how much influence they feel they have over the technologies we use. We measure these with tools. As the guild lead, these goals interest me just as much as the first type. I think they're as important as how fast we get our pages to users.
Beyond the weekly meetings, the guild's routine is that developers finish the guild meeting, everyone goes their own way, and the day goes on as usual. Each developer works in a squad on their ongoing tasks. When they run into a dilemma or a problem they need to solve, they turn to the guild for help, either through the tech lead or through our Slack channels. Our Slack channels are very active, and we encourage developers to share the problems they run into and to suggest new ideas. We also develop discussions in the Slack channels. It matters to us to hear a range of opinions, so we try to develop the conversation and see, for example, whether the problems people raise can be solved and whether they're worth raising for discussion.
Beyond me and the team of tech leads, there's also a guild master, a role that rotates among developers about once a year. The role is more administrative in nature, and its purpose is to get Frontend developers more engaged with the guild. For example, the guild master reaches out to people and suggests ideas for them to talk about, and also spots people who want to work on soft skills like public speaking. Another part of the role is finding external talks.
When did you know the guild was working?
I knew it was working when we got feedback from candidates who didn't even pass our process and told us, "Honestly, I've never been through such a fun and considerate interview process in my life." That didn't only resonate with our candidates. It also built a guild of people who really love interviewing and really love working with the people we hire afterward. And beyond that, we took this process and applied it across the whole company. We replicate the entire pipeline, from the moment we bring new people in to the moment they're part of the organization, across the rest of the organization. It works really well because it creates a tight-knit community that works together with shared principles and with technology everyone knows.
Beyond recruiting, the guild has given us less technological fragmentation, which raises code quality, improves our ability to work in code we don't know, and speeds up processes, including development. There's a desire to apply the model we built in other parts of the organization.
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 development, a sense of connection and cohesion among guild members, leading technology processes in the guild and in the organization, and building expertise in relevant areas.
The win for the organization
Less code fragmentation and work with consistent technologies, the ability to move quickly between teams, better recruiting and retention, and forward-looking, strategic planning for Frontend.
What challenges did you face?
- Adopting new technologies. When we want to adopt a new technology, we could come in and say that from today everyone uses it. That's a problematic process, because the knowledge about the technology doesn't exist in the organization yet, not everyone will necessarily connect with the reasons for bringing it in, and some may not understand what was wrong with what we did until now. Our way of handling it was to approach a developer we thought could be passionate about the technology and suggest they evaluate it and give a talk about it at the guild meeting. If it works well, the developer gets excited about it and we get a lot of engagement from all the developers. It didn't come from the top. It came from a developer, and their excitement created excitement in others. Suddenly people come to me and say, "Shay, I want to bring in this library. Is it a good idea?" And I say, sure, watch the talk Alex gave and let's run with it. Suddenly the whole thing works. It spreads like a virus.
- Building engagement between developers in the guild and the rest of the Frontend people, or with additional Frontend technologies. As part of the guild we're working on an open source library that brings all of the Frontend infrastructure and organizational knowledge into one place. Over the past year we measured developer engagement, and we see a significant rise in that metric. Developers want to work on more than their ongoing tasks: they want to work on this library too, because they want to improve Frontend capabilities across the whole organization.
- Making sure everyone gets value from the guild, at every seniority level. The value veteran employees get from the guild varies from person to person. Some are more engaged and some less. As we said earlier, some people prefer to focus on their ongoing tasks. Maybe their team works more intensively, or maybe building Frontend infrastructure doesn't interest them, and that's fine too. The tech leads and I reach out to the people who are less engaged. Our size makes that possible: we're 35 developers. Even when someone is less involved, we know where they are in their professional development and we stay in touch with them.
- The recruiting process. It mattered to us to build a recruiting process that evaluates people beyond a very precise skill set, and that is fun for the candidates themselves, even if they don't pass, because the experience of being rejected is just as important as the experience of getting in. We also wanted to create a good experience for the interviewers themselves. Within the guild we created a mini guild of 6 Frontend developers at different seniority levels who conduct interviews. This mini guild meets once a month and has a Slack channel. The monthly meetings are dedicated to thinking about questions and sharing problems and dilemmas they ran into during interviews. The Slack channel is very lively too, to the point that it was the happiest channel at Lemonade. For me, the big success was taking the Frontend interviewing method and copying it to other parts of the organization.
Tips for a successful community
- Understand what it means to lead a guild. Guild leads usually come from the technology side; they're ICs. It's very easy to slip into dealing only with architecture or design. You have to pay attention to the other part of leading a guild: managing the people, even though you're not actually their manager. That means knowing how the developers in the organization want to grow, managing a pool of skills shared across the whole organization, and encouraging developers to share their knowledge with the whole organization.
- Work together with the direct managers of guild members, so you understand their needs: personal, technological and career-related.
- Work together with the rest of the organization, especially its leadership.
- Whoever leads the guild needs to connect all of the above to the organization's technology requirements and translate those requirements into concrete technology work.