From Developer to Founder to CEO: Engineering to Enterprise with Elastic

Shai Bannon, who is the CEO of Elastic, Elasticsearch. And we're thrilled to be here today to have this conversation with you. So I'm going to kick it off, but throughout, please just feel free to ask questions in the chat and we'll get to them, or we'll sprinkle them throughout. So don't be shy. So let's, let's start. Shai, let's start at the beginning. Let's start about how you decided to build Elasticsearch and you were probably, yeah, did you have another job? Like, how did this come about?

Yeah, so hi guys.

Sitting at home, like what's the deal?

So first of all, welcome everybody. It's great to be here and thanks, Darren, for taking the time and chatting to me. I'll start with saying like a founder story is probably always trying to be okay with things that you're not used to. So I definitely still not used to seeing myself in videos, hearing myself speak, and my wife keeps making fun of me because I like, I do these things with my eyebrows when someone fills me and I can't get it off. So I stopped doing it. So yeah, so that's part of the founder story is just getting used to every day waking up in the morning and getting used to doing things that you're not used to or you've never done before. But yes, you know, my story and history with search goes about 15, 16 years ago. I moved to London with my wife. My wife went there to study to become a chef and I didn't have a job and I was trying to explore and learn new technologies and, you know, like anything that you try to do, you try to do it through building something, you know, that's the best way that I know how to learn anything in life. So I try to build something and that something was a recipe app and And when I tried to build that recipe app, I thought the best experience that you can have with that application is to be welcomed by a search box. Because regardless of any type of data that you have, including recipes or histories of locations and wineries and things of those lines that she was studying, the best way to explore any type of data anywhere is search. And I try to go and implement that elusive, difficult search box. And ever since then, I've been trying to put search boxes on every application that I get a chance to see. That's the history around how I got into search.

Do you always see search boxes in everything you do?

I see search experiences in everything that, like, you know, it's almost everywhere that I see, I see these search experiences. And to me, like, a search experience is about empowering users. It's about empathy. It's about putting yourself in someone's shoes and telling them, hey, like, you can be in control of the data, of the session that you're gonna, you know, you're gonna issue with any type of data that you have. Obviously, I'm definitely fond with search boxes and being able to go and use them and put them across, you know, anything that you do.

So let's talk about what Elastic does now. I think some people, just because the means of which you do everything is through search, it's important that people understand the depth and the breadth of what Elastic does. So tell us a little bit about that.

Yeah, it was very interesting, the arc of Elastic and the arc of my experience around search. So in the beginning, I felt like search was being put in too small of a box, if that makes sense. And, you know, search was about enterprise search and being able to go and take it and put it in organizations and try to find that Word document or something along those lines. It didn't feel that fresh, fast, go and put it on a website in milliseconds, have that data be provided in real time and accessible, being able to put it on any type of data. Why not take infrastructure information or monitoring and put it in search and make it useful? Why not take security data and make it searchable? So the goal in the beginning was just to take these search experiences and continuously try to expand people's idea and mind about what they can do with it. And that was amazing to see by Using open source, building Elasticsearch initially on my own in 2010 and open sourcing it, I put it at the hands of the community and the community just ran with it. I was trying to hang on and trying to develop all the features and all the capabilities that I could to power these search experiences. And they're so varied, right? It's like, except for the solutions that we focus on, Tesla will take the wind tunnel tests and put it into Elastic and make them searchable and analyze them. NASA will take data coming away, coming from that, you know, helicopter thingy that is running on Mars and put it in Elasticsearch and make it searchable. So that's about the power of search, but search is also about curated experiences and being able to go and help users put that search box on the website, on their cloud infrastructure to observe it, or on their company to protect it as quickly as possible.

And so you went from building a recipe, like your sense for your wife, to realizing you've built Elasticsearch, to open sourcing it. Why did you decide to open source it?

It's a great question. First of all, I kind of like fell into open source about 5 years before Elasticsearch. And I had a chance to open source a previous library that I used in the context of search. I just found it to be very liberating and the ability to go and build products and put them out there for the community to use helps, you know, remove almost any barriers for hopefully something that is valuable and resonates with the user base and just spread it and let anybody go and use it. And the goal that I had was to bring this search experience and enable with hopefully no barriers any user to be able to go and use it. I also really enjoy the effort and the process of building a community. I think it's a wonderful experience to have, especially as you get a chance to shape it in a two-way, in a bidirectional way. And the fact that users get a chance to interact with the developers of the software through open source was something that I care deeply about. I think the best companies in the world are ones that manage to maintain that close connection between whoever builds the product and whoever ends up consuming it to make sure that you have no broken information in the middle. And open source and open development processes help enable that and help keep your products honest, not only about what they delivered yesterday or today, but also about what they should deliver tomorrow.

Elastic has scaled so much since that time you were building this as a recipe app. So when I look and it's just— it's grown so tremendously. Are there things that, as the audience looks and listens and learns, are there things from an open source project to a company that you could share with people about some of that journey that you found that was either surprising or you wish you knew or any of that?

Yeah. First of all, I open-sourced Elasticsearch in 2010 and then quit my job and did this open-source thing for a full, you know, full-time for 2 years and then ended up being fortunate enough to found a company around it in 2012. And when we released Elasticsearch, it seemed to have hit a nerve with our We're the community that felt that data was growing everywhere and it wasn't really about how do you store the data or something along those lines. It was about how do you make use of it. And if you think about it, search is the most natural, like, human way that you would want to go and access data. And we were trying to empower all of these search experiences. So really spend a lot of time trying to build that open source project. As we grew, we started to see quite a few projects getting built around Elasticsearch. For example, there was a project called Kibana that was around visualizing data in Elasticsearch, and a project called Logstash about streaming data to Elasticsearch, and a project called Beats, for example, to also stream data into Elasticsearch. And, you know, being a, a person that spent so many hours, weekends, nights, and working on open source, I also I care a lot about being able to go and empower other open source projects. So we nicely ask those teams to join us and try to provide a lot of value to our users that bet on our technology. I feel a lot of responsibility to our community of users and making sure that we live up to their expectations. And that's how we started to grow into multiple experiences, all of them still like at the core, they're search experiences, if that makes sense. So, how do you onboard data to make it searchable? How do you visualize data to make it searchable? All of these, to me, tie into these search experiences that we try to provide. Now, over the years, we started to see specific use cases that became extremely common. And that's something that I would maybe touch a bit about forming a company and thinking about it. I think the best enterprise companies in the world The ones that have this very interesting duality of trying to build something that transcends use cases. For us, it's search and search platform in a single place to be able to search any type of data anywhere that you want, anytime. And, but on top of it, users tend to gravitate towards specific use cases. In our case was enterprise search. How do I take a search box and put it on our website? On my workplace? How do I take a search box and put it on my infrastructure or cloud infrastructure and applications and observe it and make sure that it's up? How do I take a search box and put it on my company to protect it? Because that threat is elusive and it's very hard to find it. And we started to build this capability at Elastic in being able to develop this platform that supports many types of use cases, ones that we never imagined. Fraud and analysis and analytics and visualizations and things along those lines, but also the security experiences. Because when someone started to use us for logs, it was not a great experience because we never built Elastic to do logs. But then we— I felt the responsibility to go and build those extra capabilities and functionality into the same platform that allows for them to have the best experience in logs and then grow to observability. Same thing with enterprise search and same thing with security. So, that's something I think I always think about. It's like, how do I— how do we, as a company, don't put too small boxes around us? I don't know. My life is filled with boxes, I guess. And I think that that's something that I care a lot about. And how do you manage that and make sure that you don't stretch too thin, but still be able to do it?

And I feel like you were doing observability before observability was a thing. So you went from having to explain why people should be able to find and log and observe. Like, how does that sort of change over time from when you're like literally starting something and then it becomes a thing? And so, you know, I hear you say often, if you're going to observe, you might as well protect. And so how do you ride these waves? I feel like you were very early to observability and explaining to people the benefits of it. How do you think about that now that it's, I think, more people understand, like, yes, observability is a thing?

First of all, I start with this is one of the powerful aspects of a free and open distribution model and a community that gets formed around your product. When I created Elasticsearch, I didn't necessarily think about logging, which is a form of observability. It's one of the data types that you would have that you want to go and search. Logs are being generated by applications and you can use it to help observe, monitor, and react to applications being up or down or infrastructure. But then someone in the community decided to build a product that shipped data to Elasticsearch and uses it to store logs because, hey, guess what? It's pretty useful to search logs, especially with unstructured and messy data and structured and things like that. That's the first thing that you would want to do. And use it for. And once I learned it, I'm not an operations person, and, you know, I did my time every once in a while in trying to maintain servers, but not like, it's not my job. I was a backend developer, but I spent a lot of time talking to all of the users of Elasticsearch, trying to put myself in their shoes and trying to understand what would make for the best logging experience. Then I vividly remember spending a lot of time taking those interactions and learnings that I had and bringing it back into Elasticsearch and still building search experiences, but ones that are relevant to the logging users. And then over the years, users started to put some APM data into Elasticsearch and monitoring data into Elasticsearch because they were like, well, I already have Elasticsearch, why not do it? APM is the ability to instrument an application from within, and monitoring, infrastructure monitoring, is like the metrics that you would gather around it. Then we started this dance that we always have with our community and the innovation that happens around, okay, let's start to develop the capabilities, store that data better in Elasticsearch, build better visualizations, build better integration. I think a lot of it comes with how comfortable we are that We just want to provide search across any type of data. So the barriers that we put around ourselves, APM versus logs versus traces, they don't really exist to us because to us they're just more pieces of data that we want to make searchable and enable users to try to solve their needs. In this case, making sure that their infrastructure and applications are up and running.

And I think so many founders and CEOs start with, one thing and know that they're going to expand over time. But is there advice? Because you have the everything you do is with search in mind, and then you have these three solutions, enterprise search, observability, and security. Do you have any advice for founders as they look from going to that one thing to expanding out?

Yeah, I think that there's a delicate balance that you want to have. You don't want to— You know, if I go to a logging— if I went to a logging user and told them, hey, I have a search platform, they won't necessarily say, okay, that's great, but I still want to do something with my logs. So I think that there is a dance between presenting yourself to users, especially practitioners, in their context. Empathy is super important when you're trying to build great products. So you want to talk to them in the context of the problems and challenges that they have and help help them achieve the outcomes that they deserve. And at the same time, almost like behind the scenes, try to build something that in your gut, and I can say like as a founder, I felt in my gut that search is fundamental and applies to many use cases. Try to continuously build that foundation, right? And make sure that you continuously explore that. And then almost like do test runs of some aspects that you have as you work with that customer, as they use it, and then try to be very attentive to things that they say. They won't say security, for example. They won't say APM, but they'll start to, you know, talk a little bit around this space or try to experiment with those areas. Then once you see them, latch onto them and try to see if you can bring them into Elastic. And some of it requires some, you know, some leap that might even not be natural. When we got into the security space, for example, We started to get used to the obvious thing, takes tons of security data, put it in a single place and make it searchable. That's like at a very high level, that's what is called SIEM, S-I-E-M. But then we said, wait, we can do more, right? It's like once we get deployed across servers and laptops and endpoints across the world, and if we ship that data to a centralized place and make it searchable to be able to find that threat, We might as well go and help them protect it at the endpoint. So we joined forces with an endpoint security company because we felt very natural for us. If you're searching the data center in the cloud, why not search on the endpoint and find those threats there at their origin points? And those things are things that, you know, they're back and forth. Nobody would go and tell you, here's the list, hey, Shai or Elastic, you now need to get into endpoint security. But we listened very hard and we had a community of users that were thought leaders and experiments and hush puppies adopters, if you will. And then we just ran with it.

Okay, that is— and I see, and knowing you, people may notice that this slide says you're 27 offices in 40 countries. And this is not a new thing. Elastic has been distributed from the ground up. So this is not something that happened because of the pandemic. This is something that you have been doing from day one, where you've had all of these offices in all of these cities. And now that everyone is sort of looking at this, if it's remote or hybrid or whatever you could call it, how— what can you tell people about how you think about this and why you were distributed long before that was a thing?

So I, you know, first of all, I'll start with saying that I didn't think that we would be distributed from the start. So when I moved to Amsterdam to start the company with our 3 other founders, I looked around the corner and I saw Booking.com with all of their offices in Amsterdam, and I thought, that's it, like we're gonna have a big office and we're gonna have people coming to Amsterdam, which is, you know, a pretty lovely city. I was gonna say, yes, lovely. That might be a feature. And just build an office. But then, you know, we ended up having such an amazing community of users and developers that ended up engaging with Elasticsearch. And, you know, I just went through IRC, which is like, I don't know, old people's Slack, and went through that list of people and I started to ping them and I said, hey, like, Would you like to join Elastic? You've been pretty awesome. I enjoy working with you. I've been working with you remotely all the time. I don't even know how tall you are, but like you're pretty awesome to go and work with remotely. Do you want to join Elastic? And many of them said yes. And then I felt a sense of responsibility of asking them to displace and move to Amsterdam, for example, from where they are. Again, this is about the empathy about them. They have lives, families, you know, everything that they build. I felt the weight of asking them to move to Amsterdam. So we just started to build a system around the fact that we would want to hire people everywhere in our community and we just continued as we go. And then we started to learn about what does it mean to become a distributed company. You know, we're 21, almost 2,200 people now and, you know, probably one of the largest distributed companies in the world. And we've learned a lot of interesting things that I think also can help people as they come out of the pandemic to try to find the balance between a distributed— in being a distributed company.

And can you tell me a little bit about those? Because I mean, you do have offices, you have a bunch of offices, right? Does distributed mean that we're all in our homes? Like, how do you think about it?

No, we actually— I think it says 27. I think the last time I We have 34 offices actually, so it's one of those. We're probably also one of the companies that have the highest ratio of offices to people, to employees in the world as well. And it's kind of like—

It might be counterintuitive, like that was counterintuitive to me.

Exactly, and by the way, as a side note, I love those contradictions, you know, like things that sometimes people go and say, hey, like distributed company means there's no office. And actually at Elastic, we learned that we actually wanna have more offices. And the thing about Elastic is that an office serves a different purpose. You know, when I was younger, I used to go to work, I went to the office to work. I still remember being much younger that I used to try to wait until my boss left to show that I was working hard, 'cause the office was the physical presence and effect of work. And at Elastic, you don't have to be at the office to show that you work. You can be anywhere you want. That's not a problem. We embrace the distributed nature of development, of building teams, of building systems, of building products. But we also cherish the fact that personal interaction is important. And it's great to come to the office and have some social interactions that you will want to have in the context of work. Not only that, sometimes you want to go to the office, you live with 3 roommates, you just want to go to the office because there's no place to work, you have a family and, you know, kids and noise maybe in a smaller house, you want to go to the office, you want to create sometimes that disconnect between, you know, where you live and where you work, but at the same time, you also want to have the flexibility to stay home and this is what We're really embracing at Elastic. It was funny in the beginning, you know, when you come to the office, you still work as if people are distributed. So, there's no like tapping someone on the shoulder. I remember in the first day, Uri, one of the founders of Elastic, like turned the chair and tried to speak to me. And I said, "Hey, like when you speak to me like this, nobody at the company hears you." And we were like 10 people. And it's like we started to, you know, write things down and go on a video call or something along those lines. And that's part about embracing the office. You want to have more offices, but they serve a different purpose, and they're probably also smaller as a result of it in each location.

Yeah, I was really struck by that, by just the office also setup was entirely different because you all did honor the everyone no matter where they were, and you cut down on the chit-chat that the people who weren't in the office we're going to miss. So you really were thoughtful there. And I'm going to keep going. I have so many questions. Anyone watching, questions about this or anything, throw it in the chat. But I'm going to keep going, and we'll come back to some of this too. So one of the other things besides like distributed— OK, observability before it was a thing, distributed before it was a thing. You've also really always focused on community. I mean, from the beginning. And I think it's probably always been a thing, but it's definitely something that has been core to Elastic and yourself. And I'm like, why? Why do you feel it's so important?

So, first of all, I love the process of bottom-up adoption and practitioner-led adoption. Being able to put your products at the hands of someone that uses it on a day-to-day basis is extremely powerful. It's even more powerful if you put it at the hands of the person that uses it with almost nothing in between. Like, just go take the product, start to use it. If it's good, you're gonna continue to use it, and if it's not good, then you'll stop. And I think that forces a company to crystallize the product development, really crystallize what values do they provide to to the community, to the companies, to the users that use it. And that together with open source that almost by definition you're gonna have a community. What are the first things that you do when you start an open source project? You're gonna have a mailing list, you're gonna have a chat system, you're gonna have all of these things and then you're gonna have people join it and people from different countries and people with different personalities. How do you go and manage that, those hopefully tens of thousands, hundreds of thousands, millions of users in a way that is respectful, open, honest. Those are things that I personally find fascinating, and I think the diversity that a broad community brings to the equation makes products stronger and better. And, you know, I spoke before and even in the video I'm a huge believer in the ability to put a community of users directly with the people that produce whatever they end up consuming. In our case, our products and search experiences and things along those lines, because it means that you don't have to have like anybody in the middle. I remember working with closed source or closed companies that were like top-down, and I was using a product and I was trying to make it better, and I would go through one support line and another support line, and then the And the sales engineer and then the product manager and then all of these people serve a function also at Elastic, by the way. But when you want to have it get directly that input, that bug, that feature request, that like, hey, I can store APM together with logs, aha moment that someone in the community has and we would go and cherish it. Those are just, you want them to be directly sent to the developers of the product.

Yeah, and you talk very much about how you want to have the producer connection and how that the magic happens. And I think some people say, but it's very time-consuming, or— but you've also talked about how there's such a learning from how people are using it and that the, the— if you listen hard enough. So I think that sounds like it's a real part of it as well. Just the listening and learning and the give and take.

Completely. And by the way, maybe a bit about communities. Some people think that a community in open source is either people that contribute code. And actually, there's very little code contributions happening in Elastic from the broad community. We feel responsibility to hire developers, full-time developers. We have hundreds of engineers working on all of our products. But to me, like, the community are all the people around it. Those are the people that open bugs, suggest feature requests or enhancements, help other people in the community with answering questions, asking questions, writing documentation, talking about it in conferences. Like, those things are— I mean, building other products that are built on top of Elastic. Like, before we got into security, there was HELK and and tons of other projects that were built with Elasticsearch in it to power their security experiences. So that's amazing to see, and, and that's an ecosystem that I find extremely valuable. And if you manage to have it, then it's, it's, it's precious to have.

That's— so you had mentioned go-to-market, and I want to talk about go-to-market for a second. I think a lot of people are interested in a bottom-up go-to-market, and Elastic has always been bottom-up. And so I'd love to understand how you think about your go-to-market, how you think about bottom-up, and then also how you think about like at what point and when do you do top-down? And as you said, there's an— I've heard you say there's an up and bottom-up. So that was a bunch of questions in there. So let's just— I think a lot of people who are watching probably are considering a bottom-up strategy. So let's start there.

Sure. So first of all, I'll start with saying, what does like bottom up really mean? To me at least, it means that you're developing product and engaging, like your first user engagement is a practitioner, right? A developer, a threat hunter, a SOC analyst, an SRE, like those are the personas that you end up engaging. Those are the people that wake up in the morning and use your product hopefully on a daily basis. And they might implement against it, they might use it as, you know, consumers or something along those lines. And when you build that motion, hopefully also with very little barriers in terms of using your product, right? Like you want them to feel like they can go and within seconds, you know, way, way back, just download that product into their laptop and start it in milliseconds and start to use it or deploy it on the cloud and start to use it. And have fun with it. Now, as they become successful and use it, and I remember like I was them in many jobs that I had in big banks and in other places around the world, then you start to try to say, hey, like I want to use this tool, I want to expand it, I want to start to make more and more use of it, and then it starts to get noticed and there starts to be like knowledge about it up in the organization. Now, I think the best ones that if you manage to build it, those brushfires are happening across the org, right? It's like there's— if you think about large orgs, then they're happening in many different places. I don't know, in one of the major banks in the world, in the early days of Elastic, I remember teams fighting that they discovered Elastic first between London and New York. And I was like, you both did. It doesn't matter to me as long as you're using it. And that's great and it starts to go up. Now, an organization has, you know, first of all, an organization has a lot of developers, a lot of projects, and I think as it goes up, you need to be able to support these people that took a bet on your company. That's why it's important to be able to support them as you go up. They took a bet on your product and they would cherish your support to be able to go and explain to their manager and their manager manager and their— then the CIO and the CISO and so on, why is it worth it for the company to take a bet on Elastic or any other company. Now, it's something that is very obvious to the practitioner because, you know, it's the fastest way that I could do threat hunting. There's no doubt about it. But like, as you go up, there's just different ways and different things that that people think about and care about, and all of them are true, by the way, and you want to be able to provide that level of support. To a degree, your practitioners that took a bet on you to begin with deserve it, you know, like you need to have their back. To add to it, that app decision, that CISO, there's like a— and we see it all the time, by the way, like there's a small threat hunting team, they manage to use Elastic to find the most sophisticated threats because no other tool can use it because Elastic returns results in milliseconds. And then it starts to go up. But if you want to now take Elastic, for example, and deploy it across the SOC, the CISO needs to approve it. So you also need to go up to get the breadth of adoption across the whole organization because it's very hard to do bottom up and suddenly the whole organization ends up using it. You need the support and the blessing and the backing of a CISO or CIO or something like that to be able to go and deploy your product. Across the organization. The great thing, I think, to me, is that this is something that if the CISO or the CIO do, they empower their developers. It's like their developers, their practitioners took a bet on technology. They implemented it. They think it's good. And then the C-level executive, if it works well, comes and empowers them with the technology choices that they made. And it's not like a top-down, now you must use, I don't know, IBM or another tool or something like that because of X, Y, and Z, and it's unrelated necessarily to what, you know, what your developers really want to use.

Right, right. So I think that that's really— because I think people struggle with, if I start bottom-up, how do I know when I should go top-down? And it seems like, you know, also the users take you there in a lot of ways.

Yeah, and, you know, we also like to say at Elastic that there's like a CISO community, there's a CIO community, and, you know, it's like there's community at every tiers, at every level, and they're important, and you want to go and support them across the whole org. Your goal is to make an organization successful, not just one part of the organization successful as a company, but it depends the stages and the phases that you go that you go through to try to make it happen.

So I think we're officially at the time where I'm supposed to officially be in Q&A mode. So if people want to officially ask questions, and I have a bunch that we've gotten earlier, so I'm going to keep going, but throw any in the chat if there are other questions, and I'm going to, I'm going to keep going. So this is a broad one, Shai. We're talking about advice for founders. Starting a new company, you're going to get a lot of inputs from a lot of people. You've been on this journey. What is some high-level advice that you have for folks?

You know, it's one of those that— Super broad. It's very difficult to— Yeah, exactly. So, you know, like most of the times these questions are being answered with bias and things that are top of mind and things on those lines. You know, I spoke a lot about empathy and, you know, I think that one of the hopefully unique skills that you can have as a founder and then build through the company is being able to put yourself in other people's shoes and think like they do because it's like, you end up being in your own box if you end up looking at the world from your perspective. You wanna look and hear and listen and make sure that you lead with empathy and make sure that you put yourself in other people's shoes. And more important than that, make them feel like you do that. You know, it's like be there for them and make sure that you listen and make sure that you hear them because people want to be heard. And make sure that you tell them that you understand like what they're saying, like why they want to do something, whether it's, by the way, your employees or whether it's your customers or your users. I think at the same time, you need to have a strong conviction to to a degree about where you wanna go as a company and you wanna lead with that and use it as input. So, you know, building a company that can scale, it's all about finding a balance, right? Finding a balance between building a search platform and curated user experiences, the search box on a website, observability. It's about finding the balance between really taking all of the input that you can, all the information by looking at it from outside in but also to a degree sometimes have the audacity of inside out and finding the balance between the two. Because if you have too much audacity from inside out, you're just, you know, delirious. It's like, you know, you don't pay attention to anything. If you listen too much to everything that people say, then you're building enterprise search boxes to try to find Microsoft Word documents, right? Because that's what people wanted to use Elastic to begin with. So you want to find that balance and I think that's something that I highly recommend and it's something that as long as you have it top of mind that there's a balancing act here, I think that that's already sets you on the right path and then it's about, you know, self-correcting all the time to try to continuously, you know, grow your company.

So I know as working with founders, that you get a lot of outside advice, speaking of outside in, and it can make you crazy. And people will be like, well, obviously you should do this or that or the other thing. Like, everybody has that. How do you as a founder— one, um, I'm gonna ask this one, like, let's say you all agree on the right place to go, how do you think about sequencing it? Because I think it's sometimes it's obvious in terms of like, yes, we should do all these things, but the role of being in charge is also figuring out which one to do first. And I'm wondering how you approach that.

It's a great question. And again, like, this is a bit of a form of art, if you will, in the context of what you end up doing. I like to think about things as you want to optimize for the most amount of impact that you can make. And maybe it comes with The open source aspect of what we have, the fact that we've had hundreds of millions or billions of downloads of our software and we end up touching so many people's lives, then, you know, almost anything that we do ends up impacting so many people. And that's not like suddenly we wake up in the morning and there's a lot of users, there's a lot of, you know, environments that we end up impacting. It's a dance that you have with your community. And the decisions that you would want to make, you want to make them as small as possible and as impactful as possible, if that makes sense, because you don't have a lot of resources as a company to begin with. So it's like you're really constrained. I, by the way, as a founder, I always feel constrained all the time. I don't think that it will ever let, you know, it will ever go away. You know, we're like 10 people, I felt constrained, and we're 20, 100 people now, and I feel constrained. I view it as a feature. But yeah, you want to optimize towards the most impactful things that you end up actioning.

And speaking of that, like when— how did you know, or were there certain telltale signs as you're growing that you're like, okay, I need to bring in leadership now, or I need to think about how the teams are how the teams look and act and in terms of like what levels do I need and when? Were there any aha moments there or things that you could tell people about that might be helpful?

Yeah, I mean, here I would actually go and really cherish the relationship that we had with our investors in, you know, Peter Fenton in Benchmark and Mike in Index and Chetan, who is now in Benchmark, and yourself. And in the board because as a founder, you're almost like by definition, if you're a first-time founder doing everything for the first time. So, you know, never managed a company this big every day, by definition, your role increases because you hire more people, so you manage more people and you have more products, you have more products, you go to a new market, now you go to a new— like, it's always like increases. And you want to go and have a chance to talk to as many people that has gone through it before, either as founders before, but they tend to have, if they're like one-time founders like myself, then they would give you the prism of their own company. But then there's people that have seen several companies go through this process and they managed to build like some framework or some systems that happen, right? Like this is the right time to bring someone that helps you lead product. This is the right time to help you bring someone to lead sales and hey, by the way, it's important that they'll sit here versus there and that should be their profile. And that's like, that experience is cherished, right? And then what you want to do, like you do with the community when you try to build products, at least what I try to do is to open up myself to as much information as possible and classified between like systems and founders that went through that experience because they come from different perspective. Try to take all of that, you know, jumble it together and try to make sense of it in the context of Elastate. Those experiences are cherished and if I can say one more thing, you probably, if you think that you need to hire someone or bring a new function or something like that, If you're in a fast-growing company, you're probably 6 months late. That's also my experience. Like whenever we hired someone, I was, oh, we could have used that person 6 months ago or 9 months ago. So it's like, it's a great feeling to have because you're growing so fast and it's a reminder that you need to continuously think about your team to make sure that you have the right team around you to help you scale.

So, um, I'm going to— this is just one, and I— forgive me for this one. What do you wish— what would you go and tell your younger self now? You're just starting out and you're talking to yourself, and you, you're— you've got this great thing and it's starting to take off. Like, what would you tell yourself if you could?

I think the first one is stop beating yourself up for not finishing writing that recipe app for your wife, because I still feel bad about it.

Does she feel bad about that?

Does she die? I think the good news is that Elastic powers the search in all of the online recipe apps that I know. So I ended up helping by indirection, basically. So that's good. You know, I think it's an interesting process because I'm not the type of person that goes back and like, I don't know how you say it in English, like cries over spilled milk or something along those lines. I think that that's very exhausting.

I'm going to do all kinds of analogies for you just to mess you up later.

And so like that question is kind of like interesting to me because You know, you want to learn from the history and from things that you've done, but like you need to— you're going to make tons of mistakes, but I don't even necessarily view them as mistakes except for them being just learning moments that you have, right? It's like if they become heavy and their mistakes or something that can drag you down as a, you know, someone that feels the responsibility and the weight of a company and a founder, and I feel responsibility for everything that we do. But those are learning moments and you want to embrace them and learn from them. So it's not like there was like a thing that I look back and I say, oh, I wish that I knew that because if I knew that, you know, things would happen better or something along those lines because I would have missed that learning moment. And then I don't know, maybe that learning moment was much more important than the mistake that I made, if that makes sense, because it helped me be better in analyzing other situations. To be honest, I don't go back and say, "Oh, that was a mistake," or something like that. There were tons of mistakes along the way together with success, but I think success that happened a year after that mistake came from learning from the first mistake that you make. And maybe that's all a big part of where Elastic is today and where it's going to be in the future.

Yep. And this is going to be— we have a question regarding Regarding a license, and I want to get to it, but I also know we're out of time, so I'm going to go for it. It's Jacob writes, yeah, regarding the open source community, would this sort of AWS cost changes in how open core companies license their software going from Apache to alternatives? How do you see this evolving for companies like Elastic, and will you be able to build and foster vibrant developer communities around projects that are not officially open source in the tradition, but source available?

Yeah, I think it's a great question. I'm very romantic about communities, and you heard me saying things like open and transparent and honest and free. You know, I think free plays a big part of it. I think open source encapsulates some of it, but open source, it's almost like the legalities of the formalization of this like more core values that I think I always cherished. Like it was never to me about open source, even though it was an easy short term to go and represent all of that. But it was all about being able to build great products, provide them for free to users on, you know, that they're running it in an open and transparent way, build an engaged and open community through trust And I think as long as you do that and provide that, the license, like the specific characteristics of a license and the small details of them matter less. And I think, and I see our community sees it, right? So even though, for example, our recent license that we moved to is not open source by definition because it wasn't approved. It is enough, like, in the spirit of free and open and everything that I just described, that our community was like, it's a non-event. We continue to engage with you, we continue to run, we continue to use your software, we continue to engage with you in all the channels that we monitor, like GitHub and our forums. And that makes me happy because I, I, I, it's almost like it, it, it verifies and validates my belief that, like, that bottom-up community and the free and open movement that we had at Elastic is more fundamental and will transcend things like the one open source license, the JUR, or something along those lines.

Thank you. And I know that we're now over time. So I wanted to thank everybody for coming. And thank you all for watching and listening. And we hope you have a great rest of your conference.

Thank you, everybody. Bye-bye.