In just five years, monday.com went from its first user to unicorn status. We grew from dozens of employees to over 1,000. This year, we went public and have continued to grow just as rapidly.
‍
I say this to explain that our culture is, by necessity, rooted in the need to move quickly. To do that and still build strong business applications products that support growth and experimentation has required a lot of experimentation of our own, which has led to a structure and hiring process that’s different from most.
‍
In this article, we (Oran Akron, Head of Business Operations, and Raz Ben Ron, Business Applications Team Lead) share how the team here has managed it all, with the caveat that what’s worked for us won't necessarily work for all. We recognize that monday.com’s situation is unusual. But perhaps there are some ideas you can borrow if your company is on a similar fast-track to growth.

Monday.com is “fast-paced” by design

For those who aren’t familiar, monday.com is a project management tool and we think of it as “the operating system” for business, hence our product’s name, Work OS. You might also call it the spinal cord of a business. Wherever there are blind spots or silos in the company, monday.com is that conduit that unites everyone to move work forward.
‍
From the company’s inception, we’ve been focused on leading with the product, though we wouldn’t say we subscribe to “product-led” growth. We’re also sales-led, marketing-led, practically “everything”-led. We don’t adhere to one philosophy. We’re about doing things that work and taking all directions at once, in many experiments.
‍
The monday.com product is also highly customizable. We see some companies use it as a CRM in addition to managing their sprints, their events, their marketing budgets, and so on.
‍
Because of our stance and how versatile the product can be, we’ve had to think hard about how to execute things rapidly. We’re always saying, “Do the right thing, but move fast.”
‍

Up until recently, we didn’t have a sales team. Now we do. We like to remain flexible

Monday.com started with what we'd call a fairly aggressive no-touch self-serve motion. Until about three and a half years ago, there was no sales organization. One-hundred percent of revenue was generated from people signing up and loving the product which virtually sold itself, which is of course remarkable. But then we reached a ceiling, in one regard.
‍
Larger companies began requesting larger deals with more attention and wanted a salesperson to help them. Because we aren’t tied to one philosophy, starting a sales team was a no-brainer. It was a solution to a problem. The business operations team made a case for it and now that channel accounts for half our revenue.
‍

We’ve built our BizOps team as one guild with members embedded in each line of business

When you combine our company’s need for speed and for constantly experimenting with our go-to-market, it’s only natural that we’ve built a unified business operations team that sits on the revenue team. We don’t have separate “sales operations,” “success operations,” and so on. We’re one team.

We think it’s also natural that we would only focus on those business systems that really matter. If we’re going to contribute to growth, we shouldn’t be tied up managing non-revenue- related systems like Zoom or Slack. We are only concerned with applications that generate data that we can analyze for improving revenue operations.
‍
We also think that one of the best ways to help everyone move quickly is to hire generalists. We want our developers to understand the business, and business people to understand the systems. That’s why we have our own developers. It’s one team with its own technical talent.
‍
We call this a “guild” approach to business systems teams:

#1. BizOps is one team, under revenue

#2. Though individuals are placed on line-of-business teams, we are united as one guild

#3. BizOps is only responsible for systems that generate data useful to revenue

#4. We hire generalists

For us, the guild approach:

• Minimizes clashes and territorialism
• Aligns people around the same goals
• Reduces back-and-forth
• Reduces technical debt
• Reduces redundant work
• Helps BizOps go from zero to one
  ‍

We hire generalists who have all three proficiencies: business, technical, and analytical (with one primary)

To dig into the point about generalists, we really mean that. We look for people who meet our three primary proficiencies: business acumen, technical acumen, and analytical acumen. Then, we place them in a role where they develop their primary proficiency further.
‍
This means our technical people understand the business, our business people understand the systems, our analysts are somewhat technical, and everyone can somewhat cover for each other.
‍
Then, on top of their generalist foundation, we encourage each person to specialize in one of those areas. On the tech side, we emphasize technical skills, but we never stop testing for their orientation to the business and ability to analyze. We want them to stop and think, “OK, how is this thing I’m building going to affect the analysts? What will sales think?”
‍
We believe that when everyone has this generalist overlap, everyone works better together. They ask better questions. You also don’t wind up with people narrowly working on issues that may not be important to the whole. We don’t want extreme specialists off tinkering with pet projects, or simply executing to spec. We want them identifying opportunities to help the whole revenue team and aggressively triaging their time.
‍
We might even go as far as to say, we wouldn’t hire a developer that didn't understand the business. We’ll of course hire people knowing they have to grow in some areas, but we need them to have good instincts and a baseline understanding. In the long-term, somebody who sees the entire picture will give us much better value than someone who simply likes to take a list of specs and execute.

Without generalist overlap, work stops and customers churn

Companies have a natural tendency to develop silos, and for teams to over-specialize. We’ve both seen this at past companies, and once sales operations no longer understands what customer operations is up to, they can build any process they want, but it won’t be efficient. There will be drop-offs and disconnects. You will have one team helping sales development reps (SDRs) hit their targets that hurts the customer success managers (CSMs), and things will drift out of alignment.
‍
If you allow that to happen, you will see customers churning. Perhaps this is a natural thought process given that we have an essentially B2C2B motion and began with a fully self-serve product, but you have to safeguard that experience. Operations is what’s keeping each business unit from over-optimizing for their particular needs to the detriment of the entire machine.
‍

It worked for us, but it may not work for you

We think it’s very important to emphasize that we do not believe our way is the only way, or even a good way for most. Your business operations team should draw its organizational inspiration from the company culture, and how it already operates, as we like to believe we have.
‍
But at a company with a B2C2B / B2B product that prizes moving fast and experimenting relentlessly, it’s worked for us. Up until now, anyway. But who knows? If there’s one thing we know about monday.com is that we aren’t wed to one philosophy and are forever open to what’s next.
‍
(Also, if that sounds like a fun place to work, we’re hiring.)