/ Josh Dover / blog

What Working At Elastic Has Been Like

March 30, 2019 • 9 minute read

I really enjoyed Patrick McKenzie’s post on working at Stripe and wanted to share my experience at Elastic in a similar fashion.

I joined Elastic last summer to make understanding large data sets for non-devs easier, mostly by making developing on Kibana simpler. I made the move to Elastic after a 3 year stint at a small eCommerce startup in Austin, called Cratejoy. There I had been managing a medium-sized engineering team. When I had joined, Cratejoy had strong fundamentals that gradually slipped away under culture issues, splintered focus, and a shifting market.

I was looking for a bit more stability and a role that came closer to fulfilling me rather than draining me. Here’s what I’ve learned since starting at Elastic.

Working remotely allows for more deep work

Elastic started out as distributed company and has remained that way. R&D teams are broadly distributed, mainly across the US, Europe, and China.

This being my first remote job, I expected there to be a lot more meetings. I assumed that without the casual drop-by chats with my colleagues there would need to be a lot more deliberate face time. I was wrong.

We only have a single weekly team meeting with a couple larger R&D meetings thrown in every few weeks. In total, I have generally 3-4 hours a week of scheduled meeting time. This was vastly different than my last job where something like 40-60% of my time in a given week was spent in conference rooms.

Now to be fair, there is more than reason for this difference. For one, Elastic is a more established company with a stable business model. There aren’t large strategic changes happening on a weekly basis (and to my surprise, this wasn’t because Elastic isn’t nimble, it’s truly because the product team knows the market and the customers well, more on this later).

However, the main reason for this is the inherent culture of trust that Elastic has built. I was treated with a trust-by-default attitude from everyone I talked to, from day one. Not once has my work ethic, competency, or dedication to the project been questioned. While I think this is by design, I’m also convinced it’s the most effective way a remote team can get work done. There simply isn’t enough time to micromanage people halfway around the world. We have products to ship.

In addition to few standing meetings, asynchronous communication is greatly emphasized. In my first 1-1 with my manager, I was told to turn off Slack often. Email is a common medium of managing the thousands of conversations happening across GitHub, Google Groups, and community forums at Elastic. The company has re-configured Gmail filters to get you started and tool nerds across the company who enjoy sharing their email management hacks and tricks. This reduces interruptions and produces more thoughtful discussions.

All this to say, I’m able to get a lot more work done than I have at previous jobs. Interruptions tend to be at a minimum, without compromising immediate help when needed (good documentation goes a long way). At my last job, I was lucky to get 2 long stretches of focused time in a week. Now I’m getting on average anywhere from 6-8, focused multi-hour periods of serious flow every week. This has done tremendous things for not only my productivity but my satisfaction with my work. Gone are the days of “I wish I had gotten more done today,” and I haven’t had to give up my nights and weekends.

Less face time creates different relationships

When you’re working right next to a colleague, it’s very easy to get into a habit of venting your frustrations with other co-workers. In my experience, this rarely helps the situation get better and instead creates an “us vs. them” mentality and fractures the team.

When you don’t sit next to anyone you work with, you’re forced to deal with these frustrations much more slowly. I now find myself often reflecting on the frustration before ever saying something. This often leads to a much more constructive response to the situation, rather than jumping to conclusions.

In a recent example, I found that a major new feature had gotten merged into Kibana with only a single, trivial, automated test. My gut reaction was frustration. Still being new to the company, I got nervous this was the norm. If I had been sitting next to someone, I may have said something that would amount to borderline gossip, tarnishing the reputation of the offending team and putting a stake in the ground on a hardline position.

But without that person to immediately turn to, this time was different. Instead, I thought about times I had done something similar to this and why that had happened. Without any of the context, I had jumped to the conclusion that this person was incompetent, when my past self was no less guilty of the same thing. While my past experience had told me this was a mistake (a position I’m still sure of), I had the time to reassess before reacting.

I gave this team the benefit of the doubt. I talked with my lead and the situation was handled appropriately: miscommunications were identified, expectations with the offending team were made clear, and the team made a renewed commitment to code quality. Instead of sowing doubt and mistrust, expectations and standards were reaffirmed. A wildly different outcome that only made the company better, not worse.

Remote work is fantastic for introverts

The term “introvert” is certainly a loaded one in modern culture. For me, this means I’m social, but that socializing drains me. Getting rid of the constant stimulus of talking to others has done wonders for my overall energy level. Yes, as I mentioned before, there are fewer interruptions, but what I’m really talking about here is fewer energy-draining interactions.

At Elastic, we use Zoom for video conferencing quite liberally. It’s a fantastic way to not only talk through hard technical problems, but build relationships. But even so, the number of interactions I have over Zoom are quite few, but they tend to be more efficient. When half the attendees are nearing 9pm in their local time, you become cognizant of how much of their evening you’re taking up.

For an introvert like me, this is a godsend. Not only am I getting more done during my work hours, I have more energy afterwards. This gives me more time to spend with my fiancé, cook delicious dinners, or read a challenging book. My life feels fuller and less stressful, all while producing and learning more at work.

Getting context takes more deliberate action

One of my passions at any job I’ve held is spending time outside my project work to make the development experience better. The main challenge doing this at Elastic is that there’s simply not the “knowledge transfer by osmosis” effect you’d see in a traditional office setting.

This made identifying the pain-points in the development experience more difficult. Instead of listening to my colleagues complain about this tool or that, I have to seek out this information more deliberately. Sure, there’s things I notice but I can’t quite capture everything on my own.

This example leads me to a broader point: to get ahead at a distributed company, I’ve found you have to be much more deliberate about learning through asking questions. You’re just not going to learn about prior decisions by just being at work, you have to be curious, bother people, and ask.

Before I had realized that this was happening, I was quite demotivated. I found it hard to be creative and take initiative, simply because I didn’t have the context about which problems needed solving.

Being deliberate about information gathering is something I’m still figuring out. Writing down questions for later and building in “curiosity time” into my schedule has gone a long way, but I need to explore more techniques.

There actually are teams without arrogant engineers

A common trope in engineering management literature is the “asshole engineer.” This is the person who always knows the right answer, belittiles others for not knowing, and generally brings the team down. In simple terms, they’re a bully.

One of the first (and strangest) things I noticed about working at Elastic was that I hadn’t met such a person. Even the most technically intimidating people (that I was also wary of being bullies) had turned out to be incredibly kind. People here actually do want to lift one another up, spread knowledge, and make the team better.

A related attribute about Elastic culture is a stark lack of sarcasm. My humor is defined by sarcasm. This was a shock at first, but here it makes sense. We have a large number of employees where English is a second (or third) language. Speaking with sarcasm, subtle references, and idioms doesn’t translate well and leads to confusion. At Elastic, these ways of speaking are actively discouraged and I believe that’s a large contributor to our positive, more supportive culture. Sarcasm can easily degrade into mean or negative remarks. Without it, discussions are lighter, more direct, and kinder.

In this culture, any “asshole engineer” sticks out like a sore thumb.

Customer-focused product managers are more effective

At my previous job, I worked with a small team of product managers who were simply asked to do too much. They were product designers, customer researchers, project managers, roadmap planners, bug triagers, and QA all rolled into one. One person attempting to do all of these things isn’t going to be very good at any one of them, no matter how great they are.

At Elastic, our product team is almost entirely focused on customer research and market analysis. They know the ins-and-outs of the competitive landscape and have a deep understanding of what problems our customers need to solve. Yes, they still help craft the final solution. They’re just much less focused on the minute details of delivery, leaving that to designers and engineers to get right.

Every time a competitor announces a new product, I can expect a detailed analysis in my inbox from a PM explaining how it fits into the landscape of the market. These give me a good understanding of why a customer might or might not choose this new competitor. As an engineer, this helps turn the creative gears on how can we use technology to solve this even better.

From my perspective, this is a much healthier relationship with product managers. I’m able to focus on what I know best: delivering technology to customers. Product managers can focus on what they know best: making sure the technology we build solves customers’ problems. Our strategy is sounder and our products are better because our product team knows these customers better than anyone. I couldn’t ask for more than that.

Thanks for reading

There it is, my brain dump on working at Elastic. Glad you made it this far, but if you’d like to ask more feel free to send me an email.

If working in this environment sounds interesting to you, Elastic is hiring.