Let's talk
All episodes

The Engineering Guild at HoneyBook

Boaz Adato, Engineering Guild Lead

How the guild helped the company make the shift to AI and improve both velocity and the engineers' experience.

HERecorded in Hebrew. Below is an English summary of the key takeaways.

If the organization says "we can't spare 20%," and then you look at the teams' velocity, you see they're not spending 20%, they're spending far more than that, just in a scattered, uncoordinated way.

Episode summary

About HoneyBook

HoneyBook has been around for about 12 years and is a platform for managing small businesses. The company was founded by Oz and Naama Alon and Dror Shimoni after they saw how inefficient it was to manage vendors around a wedding. The product lets small businesses (Creative Entrepreneurs) run their business smartly: contracts, invoices, automations, and more.

The company started with weddings and expanded into more verticals, mostly during COVID. Today it operates only in North America and has nearly 300 employees, 180 of them in Israel (mostly R&D).

Why does HoneyBook need an engineering guild?

Until about 3 years ago, when HoneyBook had grown to roughly 180 engineers in Israel, the company was facing significant challenges. The migration from Angular.js to React was moving too slowly, the frontend lacked testing infrastructure, and the dev teams' velocity was starting to drop. Boaz, who had been a developer at the company for 7 years, was handling these projects "on the go," on the side, but realized they had become too complex to run informally.

At that point, as he moved from Eilat to central Israel, he was offered the chance to formalize the guild work and lead it officially. The need was clear: big projects could no longer be handled on the way, and the organization needed a mechanism for handling cross-cutting issues in a proactive, organized, and efficient way.

How was the guild established?

The guild grew out of a team in Platform, which already handled things like DevOps, security, and the Design System. The understanding was that Platform deals with problems that have already come up, while the guild would be proactive and think about the overall vision and the important projects.

At first, Boaz expected the work to be very engineering-driven and orderly, but very quickly, within 2 or 3 months, he realized the main challenge was organizational: communication, building consensus, and understanding what really matters. The guild started with large projects led by directors, like cross-cutting testing and monitoring, while it began building its own principles and processes.

An important early step was defining the guild's core principles. One of the engineers took the initiative to do his own research and defined 5 core engineering principles, which helped clarify what "a guild whose goal is to improve velocity" actually means. Another engineer mapped the product's domains, a long effort that later became a significant foundation.

How is the guild structured?

The guild includes every engineer in the organization: backend, frontend, data scientists, QA automation, and more. There's a weekly one-hour meeting for the whole guild (All Hands), plus dedicated meetings for specific groups: backend, frontend, AI, and so on.

At the core of the guild is a team of about 8 Tech Leads, each owning a specific vector (performance, tests, refactoring, modularization, and so on). There are also Product Tech Leads: experienced engineers taken out of the teams who report to a director. Their job is to make sure the teams can move fast and are aware of what matters. They also raise issues to the Tech Leads forum.

The organization agreed to invest 20% of engineers' time in guild initiatives, large and small. That time is allocated dynamically: sometimes to a big project like AI infrastructure, and sometimes to distributed improvements across the teams.

The guild works flexibly. Sometimes it's "all hands on deck" for a major project, and sometimes it's distributed work within the teams. Communication starts in hallway conversations, continues in channels, and reaches guild meetings where relevant content is presented.

What's the win-win of the guild?

The win for employees:

  • A sense of influence over where the organization is heading
  • The ability to contribute beyond the day-to-day work
  • Professional growth and recognition of their abilities
  • Pride in the profession
  • Exposure and speaking opportunities at conferences, on blogs, and at meetups
  • Spreading knowledge and building social connections across teams

The win for the organization:

  • Higher velocity
  • Solving cross-cutting problems that individual teams wouldn't solve
  • Saving time and resources (instead of every team dealing with the same problem on its own)
  • The ability to respond quickly to major changes (like the shift to AI)
  • Cross-disciplinary collaboration (data scientists with developers)
  • Better code quality, stability, and production readiness
  • Faster feature delivery

For example: when the company decided to make a big shift to AI at the start of the year, the guild set up a task force from all the teams, brought together a core from the Platform team, and in 6 weeks (2 weeks of research and 4 of building) created an AI infrastructure that let all the teams work with AI quickly and efficiently. The group was deliberately designed to include people from every team, who would later go back and spread the knowledge, and it worked beautifully.

What challenges did you face?

The main challenge: this isn't an engineering problem, it's an organizational one!

The engineers know what needs to be done technically, but the real challenge is in organizational communication, in understanding when to do things, and in evolving the guild the right way.

Specific challenges:

  • Convincing managers and leadership: explaining why the guild needs 20% of the time, and showing that if you don't explicitly allocate that time, it still gets spent, just inefficiently (things break, support tickets go up, panels stop working).
  • When to do things: don't impose everything from the top. Choose the right things at the right time. All Hands meetings, for example, only started once the guild was ready, and at first they had to put a sign on the coffee machine ("Don't make coffee between 4 and 5 on Wednesday") so the noise wouldn't disturb the meeting.
  • Democracy versus decisiveness: most decisions are made collaboratively, but sometimes you have to stop things and say "this is too early" or "this is too big a change."
  • Staying relevant: don't disconnect from the day-to-day. The Tech Leads go and contribute to the product themselves, so they experience the processes firsthand and understand how the engineers feel.
  • Measuring the right way: at first there was a wish to adopt advanced measurement platforms, but it turned out to be too early. So Boaz chose simple metrics: dev cycle, with Work Life Balance as a guard metric, and realized that first you need the internal processes that will adopt the measurement.
  • It's not one size fits all: every organization is different, and you have to fit the guild to the organization's size, culture, and stage.

Tips for a successful guild

  • Democracy and collaboration: Boaz rarely digs in his heels and says "this has to happen." Most decisions are made together with the Tech Leads and the teams, because it's hard to decide whether A or B matters more without hearing from the people who see and feel it.
  • The right evolution at the right time: don't impose everything from the top. Choose things that work and expand them gradually. If you come and say "come to guild week, next week we're refactoring this because I decided," it won't work.
  • You need strong people at the core: experienced, versatile engineers who understand engineering broadly and have worked across many disciplines. But again, the problem isn't an engineering problem.
  • Connecting to the business, and top-down: it's important to stay connected to the product and understand where the business is going. When the shift to AI came, the guild responded right away. But some long-term work (like modularization) won't be reflected in the business metrics, so you have to know how to balance.
  • The importance of meetings: Boaz doesn't see a guild working really well without guild meetings. But you have to bring relevant content and encourage people to come forward with their own initiatives.
  • Communication and sharing: a lot of work on the Engineering Brand, telling the story internally and externally, recognizing the interesting things people do, and encouraging talks at conferences and blog posts. This grows the activity and gives engineers a stage.