Case Study: Three Years at HoneyBook, From “Soft Consensus” to a Coherent Engineering Culture

There’s a particular kind of joy in seeing seeds you planted years ago take root. Watching an engineering organization grow over the course of several years, and seeing ideas we introduced become part of its everyday rhythm, have been some of the most gratifying parts of my work. This is the story of how a small engagement with HoneyBook evolved into a multi-year partnership that shaped everything from testing to architecture to culture. What began as a simple mission of technology evaluation and mentorship proceeded to the introduction of new system testing concepts and working with multiple engineers, and eventually resulted in a deep transformation of HoneyBook’s engineering culture.

The Humble Beginning

In July 2022, HoneyBook’s CTO Inon Stelman reached out to me, saying that three separate people he trusted recommended that HoneyBook engage my services, and that it probably means we should do something together. At that point in time, HoneyBook had a few dozen engineers, working within a pod structure that gave teams a lot of autonomy in how they built features and services. 

My first engagement was modest: help one team evaluate Go vs. JVM for a new service, and mentor one of their engineers in TDD while building it. We spent some time pair-programming a walking skeleton for the new service in both Go and Kotlin, learning a bit of ATDD along the way, and then the team held an internal debate - eventually deciding in favor of Go. We did some more sessions around the chosen Go implementation, and eventually the team did not need my services anymore and was free to pursue the development on their own. 

The Plot Thickens

A few months later, around the beginning of 2023, HoneyBook’s Director of Platform, Boaz, asked me to pair-programming with one of his team members, Nirel, around refactoring one of the product’s core sub-applications. HoneyBook’s product was then composed of a legacy Angular.js application, with several new sub-applications developed in React, with the general hope that someday, they will be able to retire the Angular.js app altogether. This React sub-app managed a key aspect of the system, and was mostly isolated from the parent Angular.js application - but the test coverage was lacking, consisting mostly of unit tests that did not actually assert the behavior, and Selenium-based E2E tests that took ages to run.

So, prior to any refactoring, I proposed something unusual: we begin by covering the areas we want to change with a small suite of fast, deterministic, full-system tests that:

1. Mount the entire sub-app,

2. Exercise the affected flows,

3. Stub IO cleanly with fakes and,

4. Fail fast locally, not two days later in CI.

Once we had the first suite running, something clicked. Boaz and Nirel saw the potential and asked: “Can we generalize this approach for the rest of the React application?”

And so we did. This testing methodology later became foundational to how HoneyBook built new React features - long before any formal engineering vision existed.

During the remainder of 2023 I worked with a ~dozen engineers across different pods, helping them migrate their Angular pages to React via ATDD, using our new system-testing framework and concepts. With each pod, I was focused on their domain, their data schema and their UI requirements. However, I started to notice and experience several problems in the engineering culture. 

Core domains were owned by no one, and so whenever someone needed to add a field to an entity, such as the account, they did so without regard to naming conventions or whether this data should actually reside inside the account. Needless to say, these domain entities were bloated to dozens of fields, some of them duplicated, and none of them with any clearly defined schema being enforced. There were some attempts to retrofit some Typescript interfaces in some areas of the app around these domain entities, but - for similar, historic reasons - the compiler did not actually enforce type safety (`strict: false`) and so these interfaces provided little safety.

When discussing this issue with my mentees, it became apparent that the reason behind this was deeply rooted in HoneyBook’s culture; top-down directives were considered obscene, and the company and its engineering organization grew around the concept of a “soft consensus”; if someone wanted to push a cross-company change, they needed to raise the consensus of interested parties inside the engineering organization, and saving that - nothing actually changed. Many aspects of this culture are actually beneficial, as everyone was happy to work at HoneyBook, and each pod was allowed to move independently of other pods - but at the expense of making long, strategic moves virtually impossible. 

Towards A Cultural Transformation

Mel Conway stated that “[O]rganizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”. A company’s culture is encoded to a great extent in its communication patterns, and as such, the culture is deeply entwined with the codebase and architecture. An engineering culture reliant on consensus rather than top-down information flow can be strong and resilient, but it needs some structure and formalities to prevent paralysis and to move forwards things that are bigger than a single pod. Especially if HoneyBook was going to grow to 100+ engineers.

By early 2024 the company was indeed scaling rather significantly. During my work with the different pods I regularly discussed the pain points with Boaz, and in April 2024 he asked me to help him and Nirel do something more ambitious: create a white paper depicting the vision for HoneyBook’s architecture and codebase for the next few years. Originally, the requirements were around monorepo maintenance, state management, testing and Domain-Driven Design.

But as we discussed the various subjects, I kept going back to my thoughts about the culture of soft consensus; I realized that in order for this process to be effective, we had to find a way to harness the company’s culture and drive change slowly, using existing relationships and soft processes, rather than try to impose big changes top-down; the company’s immunity system would have rejected such attempts and the effort would have failed miserably. Rather, we would facilitate a gradual and beneficial evolution of the culture, retaining the aspects that were still effective while introducing newer concepts that would support sustainable growth. What was originally intended to be an exercise in shaping the engineering vision gradually came to include the changes in HoneyBook’s culture required to successfully adopt the new ideas. And so Nirel and I spent several months talking to engineers, analyzing pain points, mapping domains, reflecting on org design, and iteratively composing a foundational document, comprised of:

Organizational Debt

HoneyBook had pods, but no true technical leadership layer. There were a few people with titles such as Tech Lead or Staff Engineer, both most of these were attrition-prevention measures rather than actual effective roles. As a result, no one was a stakeholder of engineering strategy, where progress was made by goodwill or luck, rather than actual intentional efforts. This also meant that ICs at HoneyBook did not have a clear career ladder in terms of professional progress as well as compensation. 

The vision introduced a long-needed backbone: designated tech leads, staff engineers for groups, principal engineers for company-wide concerns - all forming an Engineering Guild. Shared Guild-wide rituals such as guild tasks and meetings would strengthen ties between engineers of different pods and ease mobility. The work of staff+ level engineers would be transparent to the entire guild and so help clearly define the possible career paths for ICs inside HoneyBook; 

Clear domain modeling and ownership

We identified every major domain and their relationships, especially core business domains like invoices and contracts, and cross-cutting ones like the user’s account. We documented how unclear domain boundaries led to years of complexity - for example, invoices unnecessarily coupled to something called a project, limiting future product evolution. We envisioned a future where each significant domain was owned by a pod, with clear guidelines around the separation of concerns, and more importantly - the mere naming of something as a separate domain entity would create a shared mental model across the engineering organization.

Code layout and monorepo strategy

HoneyBook had drifted toward a “micro-frontend-ish” structure without the tooling to support it. We proposed a coherent monorepo strategy with pnpm and Turborepo to reduce accidental coupling, improve build times, simplify refactoring, and unify design system consumption. We defined the concepts of Apps and their relations to Domain entities, where each App would encapsulate clear and distinct user flows, and be testable independently using the system test principles we had developed.

From Concept To Reality

By the end of 2025, much of this vision is becoming reality. An Engineering Guild founded and is operating with tech leads, staff engineers, principals, regular guild meetings, a steering committee, a cross-team backlog, and an organizational mandate. The culture is still consensus-oriented, but the guild and its processes have created an environment in which raising consensus is easier and straightforward. These structures and concepts also helped HoneyBook make significant changes during the Agentic AI transformation era of early 2025. PNPM workspaces and Turborepo are becoming the backbone of a cleaner, more maintainable code layout. The system-test-driven migration approach scaled to the whole organization. It also allowed Honeybook to outsource parts of the migration to independent contractors, who could run only their designated app for migration, without needing to be exposed to the backend or other apps.

This journey would not have been possible without the efforts of HoneyBook’s strong but considerate leaders, and the positive and well-intentioned culture that has evolved there. Watching HoneyBook grow into the engineering organization it is today has been one of the most rewarding long-term engagements of my career.