In 2017, DataStax crossed over the $100M mark in ARR (annual recurring revenue). It was an emotional milestone to hit for the entire company and changed the tenor of everyday work. Founded just seven years earlier in 2010, the company appeared to be a classic Silicon Valley “rocketship” story — but that wasn’t the case. The DataStax journey was filled with twists and turns that required constant assessment and prioritization to confront the most important challenges at hand. Never was this more important than in its very first year.
In 2011, Billy Bosworth was approaching 20 years working with databases: everything from development to administration to working as an independent software vendor building advanced tooling. When he got the call to join DataStax as CEO, the company was just getting off the ground. In those early days, it was known as the company behind the open-source software (OSS) database Apache Cassandra, which represented a radical shift away from the database architectures of the last 30 years. Moreover, there were some 250 open-source databases flooding the market on almost a weekly basis. Market confusion was rampant, rapid change was constant, and there were innumerable choices in front of Bosworth.
With approximately 20 people in the company working from a small Series A fundraise, there was much work to be done. Bosworth needed to very quickly establish priorities in three areas:
1. Go-to-Market (GTM)
The market was moving extremely fast, and there were already two prominent OSS leaders in the general space: Cloudera (Hadoop) and 10Gen (MongoDB). As people were getting their first glimpse of what a post-relational database might look like, those were the two names they knew: Hadoop and MongoDB. Bosworth recalls:
It was a truly interesting confluence of events. First, there was definite momentum building behind these new technologies, but only in the very innovative and nerdy markets. Mainstream people were a long way from understanding what these technologies meant, and were also still a little leery of an OSS database — which made our audience the most technical of the technical. Second, the media latched onto Hadoop as “a thing” but had very little idea of what it really could do, or how it should be used. Everyone started to believe they should have a Hadoop strategy, but few could explain how they were actually using it to affect business. Third, MongoDB was gaining strong traction with the hacker crowd — scripting developers, mostly, who liked to iterate fast and furious without the constraints of a relational database. Into that world comes Apache Cassandra — a powerful but complicated OSS database that could scale and perform like no other. But it was built only for the best of the best engineers. From this swirling pool of market forces, we needed to start building a real company right away.
The list of commercially successful OSS companies consisted of a grand total of one: RedHat. No other had been able to crack the commercial code and, in 2011, many were still skeptical of OSS in general. Therefore, Bosworth had to get clarion clear on something: If Apache Cassandra was not successful, then DataStax had precisely zero chance of becoming successful.
We had to attack the market with that mindset, knowing full well that it would cause us some brand challenges down the road. The Apache Foundation does not allow commercial companies to use project names in their commercial products, or company names. Therefore, we had to invest heavily in the “Apache Cassandra” brand, first and foremost. Trying to educate the market on both Apache Cassandra and DataStax was not as easy as one might think because the OSS community is a fickle bunch. They want the project, not the company, to be successful. Moreover, when you’re coming from behind like we were, you have to prioritize the most important thing for your next 12 months. Without that, there is no year two or three to even worry about.
Bosworth’s assessment meant that DataStax needed to quickly gain credibility in the OSS world, while only thinking about its company brand secondarily. He knew this would be a problem later, but he first had to earn the right to even get that far. Some key requirements in this Go-to-Market phase were:
‣ Get associated with very cool brands who would talk about Cassandra.
‣ Start providing free, high-quality materials for the open-source community.
‣ Create target persona(s) who would absolutely need the power of Cassandra.
‣ Create venues for these newfound Cassandra zealots to tell their stories.
But there was another problem. Because DataStax was many years ahead of the mainstream market, the problems that Cassandra solved (distributed, infinitely scalable, always-on database) were only being experienced by a handful of companies in 2011. Many could not see why they would need a technology this powerful. That day would eventually come, but in the meantime, Bosworth would have to emphasize the the importance of showing Cassandra growth momentum above all else:
Whatever events we did, I wanted them to be PACKED. I wanted everyone to feel they were lucky to get a seat. If we thought that only 30 people would come to an event, I wanted a room that held 20 comfortably. If a third didn’t show, it would still feel packed. And if everyone showed, it would feel off-the-hook with electricity. It also needed to feel first-class. We were coming from behind Hadoop and MongoDB, so we couldn’t look like we were smaller or weaker or newer to the game. For our target audience, we needed cool surroundings, good pizza and drinks, and a fun environment where people would feel they were part of something special.
If DataStax could demonstrate that Cassandra was a fast-growing, very cool database used by some of the most disruptive brands in the world, then Bosworth knew they could earn the chance to move to the next phases of the company: DataStax brand awareness and, ultimately, a monetizing business model. But before that, he had a lot more work to do in two other key areas: Product and People.
There was no getting around it — Cassandra was difficult to use. Bosworth recounts an early conversation with one of the lead Cassandra engineers on his team:
Hadoop was complicated, but it’s value proposition was clear: cheap batch storage and batch analytics. We were real-time in nature, which meant we would get compared to Oracle or MongoDB. One day, I asked one of our engineers, “What would you say to a MongoDB user who is using Cassandra for the first time?” Her reply still echoes in my head all these years later: “I would say, ‘Put that down before you hurt yourself’ and go back to playing with toys.” I groaned. Not only did we have a complicated product, but we had a complicated product built by amazing engineers who took some amount of pride in the fact that it was complicated. To them, it was a sign of its sophistication and power.
Bosworth knew that wasn’t a way to win markets, especially when you’re already chasing other players. He had to ensure the engineers knew the importance of greater adoption by people who were far less talented. He recalls one of his speeches to the team:
I gathered the small company together and told them, “This is some of the most amazing technology I have ever seen. On its current path, it’s ultimate achievement will be an interesting asterisk in some Wikipedia article on NoSQL databases — right there next to 200 other entries.” I had to drive home the point that this was not a science project. If we were going to build a real company, that meant creating a product for real users who are in the middle of the bell curve, so to speak. With that corrected attitude, we took to assessing the product.
Bosworth sees this as one of the most fundamental lessons that a startup needs to learn: product-market fit is very stage dependent and can change throughout the life of a company. It was critical to first understand the GTM developed in step one to determine what kind of product was needed at this early stage. “Easy” is a meaningless term to an engineer without further context. Easy for whom? Easy for what function? Easy compared to what other database?
Some naturally wanted to have it all and pushed for the product to be as easy as the competition. However, Bosworth knew that they could not deviate too far from their roots and try to be something they were not. The danger was that the product become something in the deadly middle: not as easy as the competition and not powerful enough for the hardest use cases. The fact was, Cassandra was built to solve really hard problems that no other database could solve. Unfortunately, that came with a certain amount of complexity, no matter what. Therefore, in light of DataStax’s GTM strategy, the goal became to make the product easier relative to a given persona and use case:
‣ The user persona was a back-end engineer, not a scripting language hacker.
‣ The use case was multi-datacenter data distribution for real-time transactions.
‣ The skill set required was java and devops (not relational database skills).
With those key components in mind, the product prioritization and evaluation became much simpler, and DataStax could focus its resources accordingly.
Finally, Bosworth had to ensure that he was hiring the exact right people based on the stage of the company, its GTM ambition, and the product requirements. As a first-time CEO, this was all new to him. Here’s where he found himself:
I had been an individual contributor, and independent contractor, and a manager, then general manager in a 4,000-person company. Building teams from scratch was something I never had to do before, especially at the fast pace with which we were moving. I learned very quickly to do two things: (a) find good mentors; and (b) ask a lot of questions.
Bosworth quickly learned that there was first a philosophical choice to make. He could either build the team top-down, hiring great leaders who could build their teams; or he could start from the bottom up, hiring only people who were needed to get DataStax to the next round of funding. He chose the latter:
Hiring too far ahead of your need will absolutely crush you in the earliest stages of a company. This is where you earn your equity as an entrepreneur and early-stage CEO — you are going to wear a lot of hats. But it’s imperative that you stay close to the business. VERY close. That means only hiring a manager when you absolutely cannot handle the load yourself, either due to expertise or bandwidth. Even there, it’s tempting to over-hire. You do not need a true worldwide head of sales. You need a scrappy rep who can win your first few customers. And when you have too many of those to manage, you still don’t need a worldwide head of sales. You need a scrappy sales manager who can work as a player coach. Eventually, a tipping point will be reached and you will have to adjust to building a great team of executive leaders. But not right now.
Bosworth decided to work closely with one of his early investors to screen candidates that would get the job done for the next 12 months. After that, they would earn the right to figure out what the company would need next. This lens was incredibly clarifying.
I still remember struggling over a hire because I just did not know if he would scale with the business. That’s when I asked John, our founding investor, what he thought. His answer felt like a weight had been lifted: “Billy, I don’t know if he’s the right person for three years from now or not. Do you believe he’s the right person for the next four quarters?” I ended that conversation and immediately drafted the offer letter.
From there, everything got easier for hiring priorities. Bosworth was able to identify the key roles required for the next 12 months, determine if they were full-time or contracted positions, and then start hiring aggressively and with confidence.
By 2012, one year into the job, Bosworth had formed an open-source evangelist team that launched GTM initiatives at scale. The first-ever “Cassandra Summit” was held with over 300 people attending. Early deals were aggressively pursued by a few hungry sales reps and a sales director. The product reached a state where cool companies like Netflix and Apple were openly talking about its use in production. The open-source growth surge was underway, and Cassandra was demonstrating not only viability, but superiority in solving some of the hardest database problems in the world.