Leadership @ Elastic | Kevin Kluge: Distributed for the better

I joined Elastic six years ago. How I came to Elastic is an interesting story, and one I’d like to share, because I think it’s revealing in terms of our engineering culture and what it means to be a company that is distributed.

Six years ago I was working at a company called Citrix, which had acquired a company that I worked for called Cloud.com. At the time I was happy at my job. I’d managed about 100 people a few times, and I felt capable of that. As the next step in my career seemed imminent, I was eager to work somewhere that I could build something bigger, somewhere that lasted more than a few years before being acquired, which had been the history of my career so far.

This is where Elastic came in. I knew Peter Fenton and Mike Volpi, who had invested early on in Elastic. They told me to take a look at Elastic, and since I respected their opinion, I downloaded Elasticsearch. I had heard of the product, but had never used it, and I really didn’t know much about what it was capable of. Within 15 minutes I had a cluster up and running and had ingested some data. It was clear to me from the start that this was an incredibly powerful tool.

While interviewing I was impressed with the team and Shay’s approach to management. When Elastic made an offer, I was excited about the opportunity, but I was still apprehensive. I worked a lot of long hours at Cloud.com, and subsequently at Citrix. Sometimes I worked until dinner, and sometimes through it. Sometimes I went home for dinner and then went back to work until 11 p.m. My wife and I had recently had our third child and there was no way I was going to miss out on raising her. Working long hours, typical of so many tech companies, would mean picking work over my family — again.

So I went to Shay and Steven Schuurman (who was CEO at the time) and raised my concern. I remember Shay saying to me, to my surprise: Why don’t you leave at 4 p.m.? That simple allowance — being able to go home at 4 p.m. — seemed incomprehensible to me. It felt so against the grain of the typical Silicon Valley mentality, and of my own experience, that I immediately took the job.

When I joined Elastic there were only 14 engineers. We knew that we needed to scale to create something that excelled in the long term. The challenge was — how could we do that while retaining the values that made me join?

Hiring a self-motivated team

The first step was building a good team of engineers. The first 14 engineers at Elastic when I joined were geographically dispersed, meaning we were distributed from the start. I’ve reflected on what this humble beginning as a small, distributed team meant for our engineering culture in those early days and how it’s shaped who we are today, and I believe this distributed nature attracted engineers who knew that they needed to be self-motivated to be successful. This is something that’s still important to Elastic today. If you're 500 miles and multiple time zones away from the nearest coworker, you have to come up with a lot of your own direction.

This is what drove us to hire more senior engineers in those earlier days and what inspires us to hire self-motivated engineers — no matter their experience — today. In the beginning, we didn’t have the infrastructure to be like Google or Facebook who could take on thousands of people straight out of school and make them successful. But now that we have bigger teams and better organization, we've been able to hire motivated people just out of school and ensure that they, too, are successful.

Giving engineers the focus they need to dive deep

In the early days, if somebody was going to join Elastic, they had to be willing, as an engineer, to do all kinds of things that weren't in the job description. This is completely natural in a company that’s just starting out. Some people really enjoyed having a lot of different responsibilities. (I did.) But as we grew, we ended up specializing and building specific teams to take over some of the roles that the engineers were performing in the beginning. Now we’re proud to have sales engineers, trainers, support engineers, and more making sure our Elasticians are able to do the job they were hired to do — and to excel in those areas.

Hiring distributed was incredibly important when building those small teams. We were trying to run 24/7 support, and being able to hire across the world allowed us to make coverage in different time zones without asking our Elasticians to change their sleeping patterns (too much). Finding balance in life, even in the early days, was of the utmost importance to the Elastic team.

Beyond focused roles, we wanted our engineers to feel free to create in the manner they work best. To feel empowered. Having distributed engineers made this an easy one to solve. Managing distributed Elasticians makes it impossible to micromanage people, even if you wanted to. So we embrace that. I don't want to know where somebody is on a Tuesday at 2 p.m. Instead, regardless of what we’re producing as a team — a blog post, lines of code, closing a support case — we need to be able to look back at what we achieved at the end of the week and be proud of it. If you can't look back at a week's worth of work and be proud of what you did, something has gone wrong, and you need to self-reflect on what might have happened. The work should speak for itself.

Organizing our teams

Org structure has also been an important component for making a strong, distributed team. When organizing, we wanted to ensure there were no advantages or disadvantages to being in a certain region, that everyone was able to respect each other’s cultures and time zones, and that we were creating an environment where our engineers could be successful.

To make this work, we organized our teams around individual products (for example, Elasticsearch) and their source code, regardless of the geographical location of each team member. This meant we ended up with a mixture of people from all over the world working on a given product, encouraging open and thoughtful communication across time zones.

Communicating effectively

This presents another challenge: How do we handle communication in teams that don’t share a physical location? With our communications charter we’ve been able to create rules and common practices around using various communication platforms. A big one is that we try to make decisions in GitHub, or an email — rarely in more synchronous channels like Slack. This ensures everyone feels as though they’re a part of the conversation, and they never feel excluded because of offline times and time zones.

Keeping things Elastic and continuing our growth

Though our teams are bigger, not much has changed since the early days except our capacity to keep maturing. With Elastic, our distributed nature offers so much flexibility and freedom — both in how we develop as a company and how our Elasticians grow as individuals. We're set up in a way that supports parents, families, lifelong students — as you are. We continue to offer pathways for our engineers to grow their careers, and since everyone is distributed, there’s no advantage going into an office every day over those folks who work from home. We ask people to communicate via GitHub, email, or Slack, even if they sit next to each other. This gives everyone the same information, no matter where they’re located. We offer job tracks for both technical and managerial roles, and those work regardless of where you are and who you are.

Looking towards the future, Elastic has reached a different level of scale, which has pushed me to develop new skills for the scaling of our engineering teams. I’ve managed teams in the past that were a few management layers deep, but they were small enough groups that if I need to effect some change, I could talk with each manager individually. Evolving to larger teams means I’ve had to work to teach other managers how to teach their managers — and to develop my written communication skills to be as clear as possible across cultures and perspectives. I’ve also had to resort to a broadcast communications approach with dozens of engineering managers since I can’t work enough hours for 1:1 communication to be effective, even though I enjoy that style the most.

We’ve almost finished a handbook that we will use as an onboarding tool for new managers, which has had the side benefit of pushing those of us that have been around a bit longer to codify all the values we want our new leaders to know, including the empowerment to teach people that join later. And fundamentally, those values that we're handing over to these new managers in our handbook have been here from the beginning, and I love that it’s continuing to be nurtured.

That’s why I stay.

Want to work with the engineering team at Elastic? Check out our up-to-date job postings.