The People Behind the Projects: More than a Bug
The People behind the Projects is a new series of first-person blog posts from the individuals who contribute to the fantastic, elastic world of Elasticsearch. We're a close-knit family at Elasticsearch. The goal of this series is to erode the boundaries between the so-called personal and the professional. We want to share our stories with you. So in this series, Elasticsearchers talk about where they're from, how they first started engaging with Elasticsearch, and what motivates them.
Marty Messer is the Vice President of Customer Care at Elasticsearch.
When I join a company, it's typically at the stage of growth where the vision is so focused, the work pressure is so intense, and the product release schedule is so tight that the welcome note from the dev team has always been one of relief: “Thank god, you're here!" Developers typically don't like dealing with support or the operational issues of integration. They like product development.
However, at Elasticsearch, the situation was different. The developers loved customer interaction, and enjoyed dealing with support, and I had to gently hug it away from them.
Enterprise software is a complicated and multidisciplinary field. In the Customer Care department at Elasticsearch, we have teams of support-focused engineers working alongside the developers of the product, and, boy, will our developers do anything for a customer. The precedents for this value system have been role-modeled and emulated since the founding of this company. Being involved in Customer Care also makes developers more aware of the operational aspects of building the platform. This customer-centricity brings us closer, and this fact is apparent in our customer surveys. Our customer survey response rates are 30 percent, three times the industry standards. People want to tell us how they are feeling. And this is a testament not only to the effectiveness of our Customer Care process, but also to the excellence of our recruiting. It's about the people we are bringing in who make all the difference.
Earlier this year, we started working with an EdTech company with a 100 million users. They use Elasticsearch to let their users search across more than 2 billion terms to find the most relevant learning material. They were having some operational performance issues, and so we started having a conversation with them. As we started peeling off the layers, we realized they were using an operating system that no other customer was using, and this selection was causing the operational performance issues (and this is with Elasticsearch, which has been downloaded over 10 million times!). When you start calling people's choice of operating systems into question, they can get prickly. Selecting an operating system is like a religious choice. It's like saying, “Your baby's ugly." But we knew we needed to have a conversation, and so we laid out a list of scientific reasons for why the operating system was a reason for concern. But instead of a formal presentation that could have come across as condescending, we ended up having a simple conversation. And the tech lead at the company told me, “You know, we have never really liked this system, and we have sort of been looking for a reason to migrate. This is going to be it." So then we were able to offer a more optimal set of operating systems as options, and have a more consultative conversation about the next steps regarding the choice of architecture and analytics.
At the end of that conversation, I felt good that I had succeeded in setting his expectations higher than what he had himself thought possible. We talked about building standalone clusters. We then went on to build a parallel infrastructure to AB test and to demonstrate the effectiveness of our recommended operating system. The conversation went beyond what our client team expected of us. For me to confidently set expectations higher than what the customer anticipated is so rare in the world of support. It's way more than just dealing with a bug here.
The act of seeking support poses a burden to one's self-image. Complicated technical issues aren't always fun. People come to us because something isn't working. But our team practices a form of intellectual honesty, of being aware that we may know Elasticsearch best, but the customer team knows their business and their technical domain inside out. At the end, we share the same goal, and the goal is to have the best, the most stable Elasticsearch installation possible in every use case.
Psychologist Daniel Kahneman argues in Thinking, Fast and Slow that people remember the end of the experience, not the experience itself. I think that's very relevant in the context of support. It really matters how we leave a customer feeling when we are done.