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 start shy. Let's start at the beginning. Let's start about how you decided to build elasticsearch and you probably. Yeah. Did you have another job? Like, how did this come about 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. As I was saying, like, a founder story is probably always be, always trying to be okay with things that you're not used to. So I definitely still not used to see 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 feels 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, 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 on 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 boxes.

Do you always see search boxes and everything you do?

I see search experiences in everything that, like, you know, it's almost everywhere that I see, I see the 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, of the session that you're going to, you know, you're going to issue with any type of data that you have. Obviously I'm definitely found with search boxes and being able to go and use them and put them across 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.

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 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 fresh fast. Go and put it on a website in millisecond, 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 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. And 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 test and put it into Elastic and make them searchable and analyze them. NASA will take data coming away, coming from that 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, 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 five years before, before elasticsearch and I had a chance to open source of previous library that I use in context of search and 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 or hopefully something that is valuable and resonate with the, 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 bidirectional way. And the fact that users get a chance to interact with developers of the software through open source was something that I care deeply about. You know, it's like I think the best companies in the world are one that 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.

That's. And you have. Elastic has scaled so much since that time you were building this as a recipe app. So when I look and it's grown so tremendously, are there things that as the audience looks and listens and learns, are there things from like 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 time for two years and then ended up being fortunate enough to found a company around it in 2012. And when we released Elastic Church, it seemed to have hit a nerve with 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 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 person that spends so many hours, weekends, nights and working on open source, also, you know, I care a lot about being able to go and empower other open source projects. So we, we nicely asked those teams to join us and you know, 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, their 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. 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 still started to build this capability at Elastic in being able to develop this platform that supports many type of use cases, ones that we never imagined, fraud and analysis and analytics and visualizations and things along those lines. But also this curated 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 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 we as a company, don't put too small boxes around us. 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.

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. How does that sort of change over time from when you're like literally starting something and then it becomes a thing? And so 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 like a free and open distribution model and a community that gets formed around your product. When I created the last search, 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 and 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 use 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. And 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. Bam. 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 suddenly APM data into elasticsearch and monitoring data into elasticsearch, because they were like, well, I already have elasticsearch, why not do it? And APM is the ability to instrument an application from within and monitoring infrastructure. Monitoring is like the metrics that you would gather around it. And 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, better integration. And I think a lot of it comes with how comfortable we are that we just want to provide search across any type of data. 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.

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 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's 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 is might even not be natural. When we got into the security space, for example, we started to get used for the obvious thing, takes tons of security data, put it in a single place and make it searchable. That's at a very high level. That's what is called siem. Siem. But then we said, wait, we can do more. 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 it felt very natural for us. If you search in the data center, in the cloud, why not search on the endpoint and find those threats? There are their origin points and those things are things that they're back and forth. Nobody would go and tell you, here's the list. Hey, shy 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 looking at this, if it's remote or hybrid or whatever you could call it, what can you tell people about how you think about this and why you were distributed long before that was a thing.

So I, first of all, I 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 three 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 going to have a big office and we're going to have people coming to Amsterdam, which is a pretty lovely city.

I was interested. Lovely.

That might Be a feature and just build an office. But then we ended up having such an amazing community of users and developers that ended up engaging with elasticsearch. 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, 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, where they are. This is about the empathy about them. They have lives, families, you know, everything that they build. I. 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 2200 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. And I just. 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 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 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 want to 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 because 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 want to have in the context of work. Not only that, sometimes you want to go to the office. You live with three roommates. You just want to go to the office because there's no place to work. You have a family and kids and noise. Maybe in a smaller house, you want to go to the office. You want to create sometimes that disconnect between 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. Adelastic. It was funny in the beginning, when you come to the office, you still work as if people are distributed, so there's no tapping someone on the shoulder. I remember in the first day, Uri, one of the founders of Elastic, turned the chair and tried to speak to me. And I said, hey, 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 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 everyone, no matter where they were. And you cut down on the chit chat that the people who weren't in the office were 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. Okay, 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? Why do you feel it's so important?

First of all, I, 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 you put it at the hands of the person that uses it with almost nothing in between. Just go, take the product, start to use it. If it's good, you're going to continue to use it. And if it's not good, then you'll stop. And I think that 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 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 products and search experiences and things along those lines. Because it means that you don't have to have anybody in the middle. I remember working with closed source or closed companies that were 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 sales engineer and then the product manager and then all of these people serve a function also at an astic, 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. 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 like 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 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. Those things are building other products that are built on top of Elastic. Before we got into security, there was HELC 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 that's an ecosystem that I find extremely valuable. And if you manage to have it, then it's precious to have.

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, 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 means? 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. 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 consumers or something along those lines. And when you build that motion, hopefully also with very little barriers in terms of using your product, you want them to feel like they can go and within seconds, 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 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 brush fires are happening across the org, right? It's like there's. If you think about large orgs and they 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 you want they would cherish your support to be able to go and explain to their manager and their manager, manager and 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, 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 managed to use Elastic to find the most sophisticated threats because no other tool can use it because Elastic return 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 to 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? Right. It's like their developers, their practitioners took a bet on technology, they implemented it, they think it's good. And then this, the C level of executive, if it works well, comes and empower 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, the users take you there in a lot of ways.

Yeah. And we also like to say at Elastic that there's like a CISO community and 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 and 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 keep going. So this is a broad one Shy. 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'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 it's. You end up being in your own box if you end up looking at the world from your perspective. You want to, you want to 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 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 a degree about where you want to go as a company and you want to 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, a 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 delirious. It's like 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 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 self correcting all the time to try to continuously 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 I'M going to 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 and millions or billions of downloads of our software and we end up touching so many people's lives, then 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 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. 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. We're like 10 people. I felt constrained and we're 2100 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 actually.

And speaking of that, 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 in terms of 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, 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 manage 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 manage to build some framework or some systems that happen, right? Like this is the right time to bring some someone that help 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 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, jumble it together and try to make sense of it in the context of elasticate. 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 six months late. That's also my experience. Whenever we hired someone, I was oh, we could have used that person six months ago or nine 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.

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've got this great thing and it's starting to take off. What would you tell yourself if you could?

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

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. Yeah, helping by indirection, basically. 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 he said in English, like cries over spilled milk or something along those lines. I think that that's very exhausting.

I'm gonna 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 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 they're mistakes or something like 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. So to be honest, I don't go back and say, oh, that was a mistake or something like that. There were like 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 like 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 regarding the open source community with this sort of AWS cause 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. 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 an 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 the 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 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 it's almost like it verifies and validates my belief 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 Jour, 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.