80 to 800+: The story of my four years on the Elastic rocket ship, Part 1

I’m about to hit my four year anniversary of working at Elastic. There were just under 80 employees when I first started and as of mid-March 2018, we’re close to 850 employees. I’m extremely proud of how I’ve grown professionally and of the contributions I’ve made as an early hire in the sales organization at the company. This is Part 1 of my story of my four years at Elastic.

Rewind to Spring 2014. A former co-worker of mine told me that Elasticsearch (as the company was known then) was looking for a sales engineer based in New York City who would be the company’s second sales engineer. At this point, I had never worked in sales. I started my career in QA, transitioned to a Java and Python developer building apps against Apache Lucene, then transitioned into more client-facing consulting roles at search engine companies like Endeca and MarkLogic. I wasn’t sure I wanted to go into sales but I did know Elasticsearch was going to be hot and I wanted to be involved in making Elasticsearch the next great software company.

Somehow I got through the interview process and received an offer despite my lack of sales engineering experience. While that probably sounds crazy for Elastic to hire someone without any sales experience, it’s important to understand the context.

At the time, the open source business model was not well-proven. Red Hat was really the only example of a successful open source software company. Elastic was smart to hire some seasoned veterans from other open source companies, but it was far from a sure thing that we’d also be able to figure out how to make money with free software.

In 2014, Elasticsearch did not sell any products besides a monitoring product called Marvel for which there were free, open-source alternatives. Our primary source of revenue was support for the open-source projects: Elasticsearch, Logstash, and Kibana. We didn’t even sell consulting like many other open-source companies did.

As you can imagine, the company probably had a hard time recruiting experienced sales people: we give our software away for free, we don’t really have any add-on products or services to sell, and all we offer is support. For sales reps and sales engineers used to doing multi-million dollar enterprise software deals, working at Elastic required a huge leap of faith.

So perhaps it was my naivety regarding sales that made me a perfect candidate. “We suckered in this guy with solid search engine experience to accept our job offer to sell free software!” :)

The beginning

When I started at Elastic, I was really green with the sales stuff. I was completely unfamiliar with basic sales terminology like accounts, opportunities, leads, pipeline, forecast, territory, etc. I had zero experience with the sales process. I didn’t understand there were strategies and methodologies to convert prospects into paying customers. Throughout most of my first year, I had to learn from scratch the entire sales side of the role in addition to gaining more in-depth technical expertise in Elasticsearch.

Figuring out how to estimate sizing

One of my first challenges was helping our sales reps figure out what to sell to customers. We priced our support subscriptions by the size of the deployment, in our case, the number of Elasticsearch nodes. With customers already running Elasticsearch, we simply asked them how many nodes they had. However, if they were just starting to consider Elasticsearch and perhaps evaluate it against competing options, they’d need some help understanding how many nodes they needed to run so they can plan and budget for the hardware expenditure and the costs of getting support from us. At the time, we had no sizing methodology. Without a sizing estimation methodology, our sales reps would have to wait for our prospective customers to finish their proof of concept, development, and load/performance testing so they can tell us how many nodes they’d need — this would extend our sales cycles and require a bigger investment of time by the sales engineer.

I sifted through details of implementations of existing customers to use as reference points, leveraged my knowledge of how Elasticsearch consumes resources as data and throughput scales, and came up with a concept of a “RAM to disk ratio” as a basis for my rough sizing estimation. I remember having conversations with engineers about my idea of correlating memory utilization and index size and them responding with hesitation — I agreed that it could be an oversimplification of Elasticsearch resource utilization but we needed something more specific than always saying “it depends” when a customer asks us how big their deployment is likely to be. We used to joke about “it depends” being the sales engineer’s response to any question, but in reality, it reflected an inability to be comfortable with making confident estimates that helped both the customer and Elastic. It was nice to see one of my colleagues eventually do some more rigorous benchmarking and validate some of the RAM to disk ratio estimates I used to size many prospective customer deployments and to help shorten our sales cycles. The concept of RAM to disk ratio was further validated by how we allow people to configure out Elastic Cloud product.

Help our customers but not too much

Selling support was an interesting thing. Today, Elastic is a comprehensive software and services company that offers a number of commercial product add-ons to the open source, consulting services, hosted and managed SaaS, orchestration/management software, and more. But back in 2014, all we sold was support. I had a lot of phone calls with prospective customers that ran into one issue or another with their Elasticsearch deployment and if they couldn’t get it resolved, there was a chance they’d migrate to a competing technology. There was this fine line between helping a prospect just enough to give them faith in our technology vs. helping them too much to the point where they don’t feel the need to buy our support. Asking the right questions and learning to see the signs for what direction they’d go in response to our assistance felt like more of an art than science, but it was this human behavior/psychology element of the process that made this job fun and more interesting than one that might be more straight-forward.

This points to another reason why hiring someone with a more conventional sales engineering background might have been difficult — our sales process didn’t lend itself to the traditional model of heavily leaning on proof of concepts and demos to make the sale. Since our product was open source, if we invested a significant amount of effort in a PoC, there was no guarantee the customer would buy support from us. Demos required a significant amount of effort to build and maintain for which we didn’t have the time or resources.

Taking on the sales persona

In my roles prior to becoming a sales engineer, I was a consulting engineer for product companies. I had the misfortune of being on some projects that were oversold — the sales rep or sales engineer had made promises about functionality or performance that simply were not true — and the onsite consultant, in this case, me, bore much of the consequence of that since we were responsible for delivering the final product.

Due to that experience, I wanted to make sure I didn’t do the same thing to my support engineers, now that I was on the sales side. Early on, I probably erred too much on the side of being “conservatively honest”. While I still believe those are good intentions to have, as a sales engineer, there is a bit of what I’ll call “assertive optimism” required in how we position our product’s capabilities. Let me be clear — I do not believe in intentionally lying to close a deal. Fortunately, I’ve never had to do that as a sales engineer at Elastic. However, there is a way to present your company’s offerings in a way that makes the customer feel confident a solution is within the realm of possibility. Without being “assertively optimistic” about your product, you will never have your product tested to its limits, you will never have new use cases adopted for the technology, and you won’t gain new customers who want to do anything besides what’s already been proven by others. That might be okay with a 20 year old software product from a mature company, but it’s not a path for growth for a fledgling open source startup.

In Part Two of this blog series, I’ll talk about how I learned to respond to competitive challenges to our product and helped ramp up new sales reps, sales engineers, and SDRs.