If you’ve hung around the high-tech space over the past few years, you’ve probably come across the term guild at least a few times. These days, most companies that have grown past the few-developers-in-a-garage phase establish (and pride themselves on) a guild.
At Gong, we’re proud to have a guild, too.
As a front-end developer at Gong, in this post, I’ll focus specifically on our front-end guild, but many of the things I share here can also be applied to guilds for back-end developers, mobile, DevOps, and more.
This post will shed some light on why to start a guild at your company and how to actually do so in a way that has an impact on the company and the people that are part of it.
I start out with some background, followed by concrete steps we’ve taken (and you can, too):
- Terms and background
- Setting goals for the guild
- The guild’s structure and processes
- Creating a roadmap for the guild
- Getting buy-in and support from management
- What’s next for us?
Terms and background
What is a guild?
According to dictionary.com, a guild is:
- An organization of persons with related interests, goals, etc., especially one formed for mutual aid or protection.
- Any of various medieval associations, as of merchants or artisans, organized to maintain standards and to protect the interests of its members, and that sometimes constituted a local governing body.
- Botany. a group of plants, as parasites, having a similar habit of growth and nutrition.
Even without getting into the tech terminology, we can see that a guild is a group of people with something in common and the desire to improve together.
It works in nature with plants and parasites, so why shouldn’t it work at a company?
One of the first (or maybe even the first) tech companies to take this seriously and create a guild was Spotify. (You can read about it here.)
The idea snowballed, inspiring other companies around the world.
If the biggest and brightest companies are doing it, you should, too, right? Well, not so fast… Building and getting value out of a guild takes work, so, like everything, you should be able to identify a real “why” for your guild. Otherwise, it’s likely to fall flat on its face or even become a bottleneck — exactly the opposite of what’s supposed to happen.
So, why should you start a guild?
There are lots of reasons to start and have a guild. In a moment, I’ll share the reasons behind ours, here at Gong.
First, however, a word on how R&D is structured at Gong: Our R&D team is organized into pods, a decision made by the company leadership to make our work and delivery of Gong products faster and more streamlined. (Read more about our pods and other aspects of our unique culture in this post by Ohad Parush, our EVP of R&D.) At other companies, like Spotify, pods are called squads, but the idea is the same.
A pod or squad, is, according to Cambridge Dictionary, “a small group of people trained to work together as a unit.” In high-tech, this usually refers to a self-sufficient unit that comprises everything it needs to work fast and smoothly.
Each pod at Gong consists of a team lead, product manager, product designer, content writer, and developers (back-end, front-end, cloud experts, and more depending on the specific needs).
The advantage of pods is that they have the agility and they’re totally focused on the product (unlike, for example, infrastructure teams, which can become a bottleneck and are often too far removed from the product). The challenge, however, is that a team made up of pods lacks owners for the infrastructure-related tasks and other cross-company processes.
Since each pod is responsible for a product or specific, significant element of our SaaS product, what we need is someone who can take ownership of cross-company tasks.
That’s where the guild comes in.
The guild might be responsible for:
- Infrastructure tasks
- Knowledge sharing
- Onboarding new developers
- Bringing architecture decisions to the table and making the final decision
- Work directly with the company’s management
- …and at least 10 other things.
Before creating and assigning responsibilities, however, it’s most important to determine, as a team, your main pain points and, therefore, goals for the guild.
To come up with goals for the Gong guild (try saying that ten times fast…), we started by turning to the crowd wisdom of the developers in the guild.
We created a poll with around 15 questions divided by subject (e.g., delivery, quality, knowledge, guild structure). We structured the poll in a way that would enable us to actually define and measure the progress down the road, as well as get clear directions for what to handle first.
After the poll, we split into 4 roundtables, each with about 5–7 participants to enable open discussion. Each table was responsible for a different area and was led by a “table lead,” who led the discussion and gathered the ideas and common thoughts.
The conclusions from the poll and roundtables helped us zero in on the following top priorities at Gong:
- Design system upgrades and more tests
- Delivery time improvements (specifically improving the speed of the local environment)
- Knowledge sharing (specifically more lectures on specific subjects we encounter every day as developers at Gong)
- The guild’s agenda, structure, and “titles”
In other words, we whittled it down from over 10 “big ideas” that we thought we should be responsible for to 4 areas that were super specific and focused. The rest (onboarding, recruiting, and more), while important, aren’t as high priority and central, based on the crowd's wisdom.
With that list in hand, we would have an easier time defining goals that actually make an impact.
First, though, let’s jump to #4 on that list: The guild’s agenda, structure, and “titles” because it sets the foundation for everything the guild can, and can’t, do.
Guild leadership, structure, and processes
There are lots of different ways to divide up tasks and responsibilities among members of a guild. And it’s easy to fall in love with other companies’ guild roles and titles: guild ninja, guild moderator, guild magician, guild [something strange]… Yup, those are real titles that companies use.
But it comes back to that central “why”: Why do you want a guild? What do you really need?
At Gong we used the data from the polls and roundtables we did (plus learnings from prior guild meetings) to find the right titles and structure for us (and it’s still a work in progress…):
Guild Master: This person leads the guild. At Gong, the guild master is a very experienced developer who spends around one day a week on guild tasks and management. He isn’t expected to do all the guild tasks himself or split them with one other person (that was one of the mistakes we made before the roundtables…). Instead, he’s responsible for delegating tasks in a smart and efficient way. (At some companies, the guild master is a full-time job, and that individual is responsible for leading and executing the guild’s tasks. That’s not the case at Gong.)
Guild Leads: We have a few guild leads. Each one is the owner of a big goal or pain point and is responsible for making it happen and working to eliminate any stumbling blocks that may be standing in the way. They spend a couple of hours a week (tops) on their focus area, and they often work closely with the guild master, but not always. Some examples of guild leads are: meeting agenda lead, knowledge-sharing lead, design system lead, testing lead, and more based on actual needs we have, rather than guesses or feelings.
Besides the titles, we also came up with specific guidelines for guild meetings, so they’re as effective as possible:
- Keep meetings short and sweet so participants can get as much as possible out of them
- Put together an agenda that combines new stuff people are working on with new things people want to present and teach (short sessions only — longer lectures are scheduled outside of the guild meetings)
- Schedule no more than two 1-hour meetings per month — everyone’s time is valuable and we care about respecting that; if we cover everything before the hour is up, we end early
- Leave a 7–10 minute slot at the end for participants to ask anything they want
Outside the guild meeting, we do lots of offline things, too, such as:
- Huddles, an open forum where team members can present or suggest new architecture, ideas, or libraries and lead/participate in a discussion about it to decide the next steps
- Lectures by people both inside and outside Gong to enrich knowledge among the front-end developer team
- Slack channel for offline questions/consulting, meetups, new posts, and more
- Guild contributors — Each quarter, the leads of each pod provide the names of developers who are willing to volunteer for the guild and participate in infrastructure tasks for 1–2 weeks (It’s actually really fun, I swear!)
And now: The roadmap!
As I mentioned at the beginning, besides the guild’s main activities and priorities, we’re also responsible for infrastructure and cross-company tasks. So, once we set our goals (and considered other responsibilities), we put together the roadmap.
The roadmap is a crucial part of making sure that the guild remains focused and being able to measure its effectiveness. We created a task roadmap with the priorities and sub-tasks for the next two quarters and presented it to our tech leaders (EVP of R&D, group leads, etc.) to get buy-in and time to work on it beyond the normal product tasks each developer already has.
At Gong, we chose 3 main goals to drive the roadmap:
- Design system
- Testing our components
- Local environment and faster deployment process
(And one optional 4th goal for the future: TypeScript)
I won’t get into the sub-tasks and timelines here, but with these goals clearly defined, we could then start working and easily navigate and divide up tasks among developers.
Getting management involved
This was the point at which it made sense to get management involved.
Once we had a rough roadmap in place, we scheduled a couple of meetings with our leadership to present our process, goals, pain points, and final roadmap and ensure alignment on how we plan to carry it out, how much time we can allocate towards guild tasks, and overall expectations.
By working through the details with the company management, we were able to get more buy-in. After all, when people are involved in decision-making, rather than having it dropped on them, it’s more likely to succeed, even if it means compromising a bit. And from our side, that support from the leadership gave us the motivation and momentum we needed to get things moving.
(It’s worth mentioning that we got our EVP R&D involved from the very start to ensure full alignment between guild goals and company goals.)
When the front-end guild was started at Gong around 2–3 years ago, it was just 5 developers. Since then it’s grown significantly, making it clear that we needed to find a way to operate and scale more sustainably and intentionally. About 6 months ago, we started all the processes I’ve described here.
Thanks to our roadmap and a clearer structure, there’s more clarity surrounding the guild — what it does, how it works, etc.
Still, there are many challenges ahead, including:
- Boosting the engagement of the developers in the guild
- Proving to ourselves and to company management that we actually make an impact (with facts and figures to back it up)
- …and lots of other challenges we don’t even know about yet.
As Ohad wrote in his post about Gong’s culture, we love our developers and our guild, but we’re not in love with our guild: we’re constantly looking to learn from other developers and guilds at other companies (shoutout to Daniel from Outbrain!) so we can make changes and improve the way we work.
As the guild, we constantly remind ourselves that our role is to solve the real pains Gong developers have — not to invent stuff that doesn’t exist and that might distract us from what really matters.
We may have a long way to go, but we think we’re off to an exciting and promising start…
Special thanks to all the people who were involved in the process we started.
Yasmin, Moshiko, Ran, Shmulik, Valentin, Eli, Amir, and the rest of the FE Guild at Gong!
Does your company have a guild? Do you have questions about our guild or thoughts about guilds in general? Drop them in the comments or reach out! I’d love to hear from you and bring new ideas to our next meeting or huddle.
Want to be part of a kickass team that writes awesome code by day and geeks out on guild stuff, erm, also by day? We’re hiring! Check out our open positions here.