>> Announcer: Live from the Computer History Museum in Mountain View, California. It's theCUBE, covering DevNet Create 2018. Brought to you by Cisco. >> Hey, welcome back, everyone. This is theCUBE, live here in Mountain View, California, heart of Silicon Valley for Cisco's DevNet Create. This is their Cloud developer event. It's not the main Cisco DevNet which is more of the Cisco developer, this is much more Cloud Native DevOps. I'm joined with my cohost, Lauren Cooney and our next guest is Christine Yen, who is co-founder and Chief Product Officer of Honeycomb.io. Welcome to theCUBE. >> Thank you. >> Great to have an entrepreneur and also Chief Product Officer because you blend in the entrepreneurial zeal, but also you got to build the product in the Cloud Native world. You guys done a few ventures before. First, take a minute and talk about what you guys do, what the company is built on, what's the mission? What's your vision? >> Absolutely, Honeycomb was built, we are an observability platform to help people find the unknown unknowns. Our whole thesis is that the world is getting more complicated. We have microservices and containers, and instead of having five application servers that we treated like pets in the past, we now have 500 containers running that are more like cattle and where any one of them might die at any given time. And we need our tools to be able to support us to figure out how and why. And when something happens, what happened and why, and how do we resolve it? We look around at the landscape and we feel like this dichotomy out there of, we have logging tools and we have metrics tools. And those really evolved from the fact that in 1995, we had to choose between grep or counters. And as technology evolved, those evolved to distribute grep or RDS. And then we have distribute grep with fancy UIs and well, fancy RDS with UIs. And Honeycomb, we were started a couple years ago. We really feel like what if you didn't have to choose? What if technology supported the power of having all the context there the way that you do with logs while still being able to provide instant analytics the way that you have with metrics? >> So the problem that you're solving is one, antiquated methodologies from old architectures and stacks if you will, to helping people save time, with the arcane tools. Is that the main premise? >> We want people to be able to debug their production systems. >> All right, so, beyond that now, the developer that you're targeting, can you take us through a day in the life of where you are helping them, vis a vis the old way? >> Absolutely, so I'll tell a story of when myself and my co-founder, Charity, were working together at PaaS. PaaS, for those who aren't familiar, used to be RD, a backend form of mobile apps. You can think of someone who just wants to build an iOS app, doesn't want to deal with data storage, user records, things like that. And PaaS started in 2011, got bought by Facebook in 2013, spun down very beginning of 2016. And in 2013, when the acquisition happened, we were supporting somewhere on the order of 60,000 different mobile apps. Each one of them could be totally different workload, totally different usage pattern, but any one of them might be experiencing problems. And again, in this old world, this pre-Honeycomb world, we had our top level metrics. We had latency, response, overall throughput, error rates, and we were very proud of them. We were very proud of these big dashboards on the wall that were green. And they were great, except when you had a customer write in being like, "Hey, PaaS is down." And we look at our dashboard we'd be like, "Nope, it's not down. "It must be network issues." >> John: That's on your end. >> Yeah, that's on your end. >> John: Not a good answer. >> Not a good answer, and especially not if that customer was Disney, right? When you're dealing with these high level metrics, and you're processing tens or hundreds of thousands of requests per second, when Disney comes in, they've got eight requests a second and they're seeing all of them fail. Even though those are really important, eight requests per second, you can't tease that out of your graphs. You can't figure out why they're failing, what's going on, how to fix it. You've got to dispatch an engineer to go add a bunch of if app ID equals Disney, track it down, figure out what's going on there. And it takes time. And when we got to Facebook, we were exposed to a type of tool that essentially inspired Honeycomb as it is today that let us capture all this data, capture a bunch of information about everything that was happening down to these eight requests per second. And when a customer complained, we could immediately isolate, oh, this one app, okay let's zoom in. For this one customer, this tiny customer, let's look at their throughput, error rates, latency. Oh, okay. Something looks funny there, let's break down by endpoint for this customer. And it's this iterative fast, highly granular investigation, that is where all of us are approaching today. With our systems getting more complicated you need to be able to isolate. Okay, I don't care about the 200s, I only care about the 500s, and within the 500s, then what's going on? What's going on with this server, with that set of containers? >> So this is basically an issue of data, unstructured data or have the ability to take this data in at the same time with your eye on the prize of instrumentation. And then having the ability to make that addressable and discoverable in real time, is that kind of? >> Yeah, we've been using the term observability to describe this feeling of, I need to be able to find unknown unknowns. And instrumentation is absolutely the tactic to observability of the strategy. It is how people will be able to get information out of their systems in a way that is relevant to their business. A common thing that we'll hear or people will ask, "Oh, can you ingest my nginx logs?" "Can you ingest my SQL logs?" Often, that's a great place to start, but really where are the problems in an application? Where are your problems in the system? Usually it's the places that are custom that the engineers wrote. And tools need to be able to support, providing information, providing graphs, providing analytics in a way that makes it easy for the folks who wrote the code to track down the problem and address them. >> It's a haystack of needles. >> Yeah, absolutely. >> They're all relevant but you don't know which needle you're going to need. >> Exactly. >> So, let me just get this. So I'm ducking out, just trying to understand 'cause this is super important because this is really the key to large scale Cloud ops, what we're talking about here. From a developer standpoint, and we just had a great guest on, talking about testing features and production which is really the important, people want to do that. And then, but for one person, but in production scale, huge problem, opportunity as well. So, if most people think of like, "Oh, I'll just ingest with Splunk," but that's a different, is that different? I mean, 'cause people think of Splunk and they think of Redshift and Kinesis on Amazon, they go, "Okay." Is that the solution? Are you guys different? Are you a tool? How do I understand you guys' context to those known solutions? >> First of all, explain the difference between ourselves and the Redshifts and big queries of the world, and then I'll talk about Splunk. We really view those tools as primarily things built for data scientists. They're in the big data realm, but they are very concerned with being 100% correct. They're concerned with fitting into big data tools and they often have an unfortunate delay in getting data in and making it acquirable. Honeycomb is 100% built for engineers. Engineers of people, the folks who are going to be on the hook for, "Hey, there's downtime, what's going on?" And in-- >> So once business benefits, more data warehouse like. >> Yeah. And what that means is that for Honeycomb, everything is real time. It's real time. We believe in recent data. If you're looking to get query data from a year ago we're not really the thing, but instead of waiting 20 minutes for a query over a huge volume of data, you wait 10 seconds, or it's 3:00 AM and you need to figure out what's happening right now, you can go from query to query, to query, to query, as you come up with hypotheses, validate them or invalidate them, and continue on your investigation path. So that's... >> That makes sense. >> Yeah. >> So data wrangling, doing queries, business intelligence, insights as a service, that's all that? >> Yeah. We almost, we played with and tossed the tagline BI for systems because we want that BI mentality of what's going on, let me investigate. But for the folks who need answers now, an approximate answer now is miles better than a perfect one-- >> And you can't keep large customers waiting, right? At the end of the day, you can't keep the large customers waiting. >> Well, it's also so complicated. The edge is very robust and diverse now. I mean, no-js is a lot of IO going on for instance. So let's just take an example. I had developer talking the other day with me about no-js. It's like, oh, someone's complaining but they're using Firefox. It's like, okay, different memory configuration. So the developer had to debug because the complaints were coming in. Everyone else was fine, but the one guy is complaining because he's on Firefox. Well, how many tabs does he have open? What's the memory look like? So like, this a weird thing, I mean, that's just a weird example, but that's just the kinds of diverse things that developers have to get on. And then where do they start? I mean. >> Absolutely. So, there's something we ran into or we saw our developers run into all the time at PaaS, right? These are mobile developers. They have to worry about not only which version of the app it is, they have to worry about which version of the app, using which version of RSDK on which version of the operating system, where any kind of strange combination of these could result in some terrible user experience. And these are things that don't really work well if you're relying on pre-aggregated 10 series system, like the evolution of the RDS, I mentioned. And for folks who are trying to address this, something like Splunk, these logging tools, frankly, a lot of these tools are built on storage engines that are intended for full text search. They're unstructured text, you're grepping over them, and then you're build indices and structure on top of that. >> There's some lag involved too in that. >> There's so much lag involved. And there's almost this negative feedback loop built in where if you want to add more data, if on each log line you want to start tracking browser user agent, you're going to incur not only extra storage costs, you're going to incur extra read time costs because you're reading that more data, even if you're don't even care about that on those queries. And you're probably incurring cost on the right time to maintain these indices. Honeycomb, we're a column store through and through. We do not care about your unstructured text logs, we really don't want them. We want you to structure your data-- >> John: Did you guys write your own column store or is that? >> We did write our own column store because ultimately there's nothing off the shelf that gave us the speed that we wanted. We wanted to be able to, Hey, sending us data blogs with 20, 50, 200 keys. But if you're running analysis and all you care about is a simple filter and account, you shouldn't have to pull in all this-- >> To become sort of like Ferrari, if you customize, it's really purpose built, is that what you guys did? >> That is. >> So talk about the dynamic, because now you're dealing with things like, I mean, I had a conversation with someone who's looking at say blockchain, where there's some costs involved, obviously writing to the blockchain. And this is not like a crypto thing it's more of a supply chain thing. They want visibility into latency and things of that nature. Does this sounds like you would fit there as a potential use case? Is that something that you guys thought of at all? >> It could absolutely be. I'm actually not super familiar with the blockchain or blockchain based applications but ultimately Honeycomb is intended for you to be able to answer questions about your system in a way that tends to stymie existing tools. So we see lots of people come to us from strange use cases who just want to be able to instrument, "Hey I have this custom logic. "I want to be able to look at what it's doing." And when a customer complains and my graphs are fine or when my graphs are complaining, being able to go in and figure out why. >> Take a minute to talk about the company you founded. How many employees funding, if you can talk about it. And use case customers you have now. And how do you guys engage? The service, is it, do I download code? Is it SaaS? I mean, you got all this great tech. What's the value proposition? >> I think I'll answer this-- >> John: Company first. >> All right. >> John: Status of the company. >> Sure. Honeycomb is about 25 people, 30 people. We raised a series A in January. We are about two and a half years old and we are very much SaaS of the future. We're very opinionated about a number of things and how we want customers to interact with us. So, we are SaaS only. We do offer a secure proxy option for folks who have PII concerns. We only take structured data. So, at our API, you can use whatever you want to slurp data from your system. But at our API, we want JSON. We do offer a wide variety of integrations, connectors, SDKs, to help you structure that data. But ultimately-- >> Do you provide SDKs to your customers? >> We do. So that if they want to instrument their application, we just have the niceties around like batching and doing things asynchronously so it doesn't block their application. But ultimately, so we try to meet folks where they're at, but it's 2016, it was 2017, 2018-- >> You have a hardened API, API pretty much defines your service from an inbound standpoint. Prices, cost, how does someone engage with you guys? When does someone know to engage? Where's the smoke signals? When is the house on fire? Is it like people are standing around? What's the problem? When does someone know to call you guys up at? >> People know to call us when they're having production problems that they can't solve. When it takes them way too long to go from there's an alert that went off or a customer complaint, to, "Oh, I found the problem, I can address it." We price based on storage. So we are a bunch of engineers, we try to keep the business side as simple as possible for better, for worse. And so, the more data you send us, the more it'll cost. If you want a lot of data, but stored for a short period of time, that will cost less than a lot of data stored for a long period of time. One of the things that we, another one of the approaches that is possibly more common in the big data world and less in the monitoring world is we talk a lot about sampling. Sampling as a way to control those costs. Say you are, Facebook, again, I'll return to that example. Facebook knew that in this world where lots and lots of things can go wrong at any point in time, you need to be able to store the actual context of a given event happening. Some unit of work, you want to keep track of all the pieces of metadata that make that piece of work unique. But at Facebook scale, you can't store every single one of them. So, all right, you start to develop these heuristics. What things are more interesting than others? Errors are probably more interesting than 200 okays. Okay. So we'll keep track of most errors, we'll store 1% of successful requests. Okay. Well, within that, what about errors? Okay. Well, things that time out are maybe more interesting than things that are permissioning errors. And you start to develop this sampling scheme that essentially maps to the interesting ness of the traffic that's flowing through your system. To throw out some numbers, I think-- >> Machine learning is perfect for that too. They can then use the sampling. >> Yeah. There's definitely some learning that can happen to determine what things should be dropped on the ground, what requests are perfectly representative of a large swath of things. And Instagram, used a tool like this inside Facebook. They stored something like 1/10 of a percent or a 1/100 of a percent of their requests. 'Cause simply, that was enough to give them a sketch of what representative traffic, what's going wrong, or what's weird that, and is worth digging into. >> Final question. What's your priorities for the product roadmap? What are you guys focused on now? Get some fresh funding, that's great. So expand the team, hiring probably. Like product, what's the focus on the product? >> Focus on the product is making this mindset of observability accessible to software engineers. Right, we're entering this world where more and more, it's the software engineers deploying their code, pushing things out in containers. And they're going to need to also develop this sense of, "Okay, well, how do I make sure "something's working in production? "How do I make sure something keeps working? "And how do I think about correctness "in this world where it's not just my component, "it's my component talking to these other folks' pieces?" We believe really strongly that the era of this single person in a room keeping everything up, is outdated. It's teams now, it's on call rotations. It's handing off the baton and sharing knowledge. One of the things that we're really trying to build into the product, that we're hoping that this is the year that we can really deliver on this, is this feeling of, I might not be the best debugger on the team or I might not be the best person, best constructor of graphs on the team, and John, you might be. But how can a tool help me as a new person on a team, learn from what you've done? How can a tool help me be like, Oh man, last week when John was on call, he ran into something around my SQL also. History doesn't repeat, but it rhymes. So how can I learn from the sequence of those things-- >> John: Something an expert system. >> Yeah. Like how can we help build experts? How can we raise entire teams to the level of the best debugger? >> And that's the beautiful thing with metadata, metadata is a wonderful thing. 'Cause Jeff Jonas said on the, he was a Cube alumni, entrepreneur, famous data entrepreneur, observation space is super critical for understanding how to make AI work. And that's to your point, having observation data, super important. And of course our observation space is all things. Here at DevNet Create, Christine, thanks for coming on theCUBE, spending the time. >> Thank you. >> Fascinating story, great new venture. Congratulations. >> Christine: Thank you. >> And tackling the world of making developers more productive in real time in production. Really making an impact to coders and sharing and learning. Here in theCUBE, we're doing our share, live coverage here in Mountain View, DevNet Create. We'll be back with more after this short break. (gentle music)

>>Hey everyone. Welcome to the AWS partner showcase season one, episode three women in tech. I'm your host. Lisa Martin. I've got two female rock stars joining me. Next Vera Reynolds is here engineering manager, telemetry at honeycomb, and one of our Cub alumni, Danielle GShock ISV PSA director a at AWS joins us as well. Ladies. It's great to have you talking about a very important topic today. >>Thanks for having us. Yeah, thanks for having me. Appreciate it. >>Of course, Vera, let's go ahead and start with you. Tell me about your background and tech. You're coming up on your 10th anniversary. Happy anniversary. >>Thank you. That's right. I can't believe it's been 10 years, but yeah, I started in tech in 2012. I was an engineer for most of that time. And just recently, as of March switched to engineering management here at honeycomb and, you know, throughout my career, I was very much interested in all the things, right. And it was a big FOMO as far as trying a few different companies and products. And I've done things from web development to mobile, to platforms. It would be apt to call me a generalist. And in the more recent years, I was sort of gravitating more towards developer tool space. And for me, that came in the form of cloud Foundry circle CI, and now honeycomb. I actually had my eye on honeycomb for a while before joining, I came across a blog post by charity majors. Who's one of our founders and she was actually talking about management and how to pursue that and whether or not it's right for your career. >>And so I was like, who is this person? I really like her found the company. They were pretty small at the time. So I was sort of keeping my eye on them. And then when the time came around for me to look again, I did a little bit more digging, found a lot of talks about the product. And on the one hand, they really spoke to me as the solution. They talked about developers owning their coding in production and answering questions about what is happening, what are your users seeing? And I felt that pain, I got what they were trying to do. And also on the other hand, every talk I saw at the time was from an amazing woman, which I haven't seen before. So I came across charity majors again, Christine yen, who our other founder, and then Liz Frank Jones, who our principal developer advocate. And that really sealed the deal for me as far as wanting to work here. >>Yeah. Honeycomb is interesting. This is a female founded company. You're two leaders. You mentioned that you like the technology, but you were also attracted because you saw females in the leadership position. Talk to me a little bit about what that's like working for a female led organization at honeycomb. >>Yeah. You know, historically we have tried not to over index on that because there was this maybe fear or rareness of it taking away from our legitimacy as an engineering organization, from our success as a company. But I'm seeing that rhetoric shift recently because we believe that with great responsibility with great power comes great responsibility. And we're trying to be more intentional as far as using that attribute of our company. So I would say that for me, it was a choice between a few offers, right. And that was a selling point, for sure, because again, I've never experienced it and I've really seen how much they walk that walk. Even me being here and me moving into management, I think were both ways in which they really put a lot of trust and support in me. And so I it's been a great ride. >>Excellent. Sounds like it. Before we bring Danielle in to talk about the partnership. I do wanna have you here, talk to the audience a little bit about honeycomb, what technology it's delivering and what are its differentiators. >>Yeah, absolutely. So honeycomb is an observability tool that enables engineers to answer questions about the code that runs in production. And we work with a number of various customers. Some of them are Vanguard, slack. Hello, fresh. Just to name a couple. If you're not familiar with observability tooling, it's akin to traditional application performance monitoring, but we believe that observability is succeeding APM because APM tools were built at the time of monoliths and they just weren't designed to help us answer questions about complex distributed systems that we work with today, where things can go wrong anywhere in that chain. And you can't predict what you're gonna need to ask ahead of time. So some of the ways that we are different is our ability to store and query really rich data, which we believe is the key to understanding those complex systems. What I mean by rich data is something that has a lot of attributes. >>So for example, when an error happens, knowing who it happened to, which user ID, which I don't know region, they were in, what, what, what they were doing at the time and what was happening at the rest of your system. And our ingest engine is really fast. You can do it in as little as three seconds and we call data like this. I said, kind of rich data, contextual data. We refer it as having high ity and high dimensionality, which are big words. But at the end of the day, what that means is we can store and we can query this data and we can do it really fast. And to give you an example of how that looks for our customers, let's say you have a developer team who are using comb to understand and observe their system. And they get a report that a user is experiencing a slowdown or something's wrong. >>They can go into honeycomb and figure out that this only happens to users who are using a particular language pack with their app. And they operated their app last week, that it only happens when they are trying to upload a file. And so it's this level of granularity and being able to zoom in and out under data that allows you to understand what's happening, especially when you have an incident going on, right. Or your really important high profile customer is telling you that something's wrong. And we can do that. Even if everything else in your other tools looks fine, right? All of your dashboards are okay. You're not actually getting paged on it, but your customers are telling you that something's wrong. And we believe that's where we shine in helping you there. >>Excellent. It sounds like that's where you really shine that real time visibility is so critical these days. Danielle, Danielle, wanna bring you into the conversation. Talk to us a little bit about the honeycomb partnership from the AWS lens. >>Yeah. So excuse me, observability is obviously a very important segment in the cloud space, very important to AWS, because a lot of all of our customers, as they build their systems distributed, they need to be able to see where, where things are happening in the complex systems that they're building. And so honeycomb is a, is an advanced technology partner. They've been working with us for quite some time and they have a, their solution is listed on the marketplace. Definitely something that we see a lot of demand with our customers, and they have many integrations, which, you know, we've seen is key to success. Being able to work seamlessly with the rest of the services inside of the AWS platform. And I know that they've done some, some great things with people who are trying to develop games on top of AWS things in that area as well. And so very important partner in the observa observability market that we have. >>Vera a back to you, let's kind of unpack the partnership, the significance that honeycomb ha is getting from being partners with an organization as potent and pivotal as AWS. >>Yeah, absolutely. I Don know that this Predates me to some extent, but I Don know for a long time, AWS and honeycomb has really pushed the envelope together. And I think it's a beneficial relationship for both ends. There's kind of two ways of looking at it. On the one side, there is our own infrastructure. So honeycomb runs on AWS and actually one of our critical workloads that supports that fast query engine that I mentioned uses Lambda. And it does also in a pretty unorthodox way. So we've had a long standing conversation with the AWS team as far as drawing outside those lines and kind of figuring out how to use the technology in a way that works for us and hopefully will work for other customers of theirs as well. That also allows us to ask for early access for certain features when they become available. >>And then that way we can be sort of the Guinea pigs and try things out in a way that migrates our system and optimizes our own performance, but also allows again, other customers of AWS to follow in that path. And then the other side of that partnership is really supporting our customers who are both honeycomb users and AWS users, because it's, as you imagine, quite a big overlap, and there are certain ways in which we can allow our customers to more easily get their data from AWS to honeycomb. So for example, last year, we built a tool based on the new Lambda extension capability that allowed our users who run their applications in Lambdas to get that tele telemetry data out of their applications and into honeycomb and demand was win-win >>Excellent. So I'm hearing a lot of synergies from a technology perspective, you're sticking with you, and then Danielle will bring you in. Let's talk about how honeycomb supports D E and I across its organization. And how is that synergistic with AWS's approach Vera? >>Yeah, absolutely. So I sort of alluded to that hesitancy to over index on the women led aspect of ourselves. But again, a lot of things are shifting, we're growing a lot. And so we are recognizing that we need to be more intentional with our DEI initiatives, and we also notice that we can do better and we should do better. And to that end, we're doing a few things differently that are pretty recent initiatives. We are partnering with organizations that help us target specific communities that are underrepresented in tech. Some examples would be Africa, tech hu Latinas in tech among a number of others. And another initiative is DEI head start. That's something that is an internal practice that we started that includes reaching out to underrepresented applicants before any new job for honeycomb becomes live. So before we posted to LinkedIn, before it's even live on our job speech, and the idea there is to kind of balance our pipeline of applicants, which the hope is will lead to more diverse hires in the long term. >>That's a great focus there. Danielle, I know we've talked about this before, but for the audience, in terms of the context of the honeycomb partnership, the focus at AWS for D E and I is really significant, unpack that a little bit for us. >>Well, let me just bring it back to just how we think about it with the companies that we work with, but also in, in terms of, you know, what we want to be able to do, excuse me, it's very important for us to, you know, build products that reflect the customers that we have. And I think, you know, working with a company like honeycomb that is looking to differentiate in a space by, by bringing in, you know, the experiences of many different types of people I genuinely believe. And I'm sure Vera also believes that by having those diverse perspectives, that we're able to then build better products for our customers. And, you know, it's one of, one of our leadership principles is, is rooted in this. I write a lot, it asks for us to seek out diverse perspectives and you can't really do that if everybody kind of looks the same and thinks the same and has the same background. So I think that is where our de and I, you know, I thought process is rooted and, you know, companies like honeycomb that give customers choice and differentiate and help them to do what they need to do in their unique environments is super important. So >>The, the importance of thought diversity cannot be underscored enough. It's something that is, can be pivotal to organizations. And it's very nice to hear that that's so fundamental to both companies, Barry, I wanna go back to you for a second. You, I think you mentioned this, the DEI head start program, that's an internal program at honeycomb. Can you shed a little bit of light on that? >>Yeah, that's right. And I actually am in the process of hiring a first engineer for my team. So I'm learning a lot of these things firsthand and how it works is we try to make sure to pre-load our pipeline of applicants for any new job opening we have with diverse candidates to the best of our abilities. And that can involve partnering with the organizations that I mentioned or reaching out to our internal network and make sure that we give those applicants a head start, so to speak. >>Excellent. I like that. Danielle, before we close, I wanna get a little bit of, of your background. We've got various background in tech, she's celebrating her 10th anniversary. Give me a, a short kind of description of the journey that you've navigated through being a female in technology. >>Yeah, thanks so much. I really appreciate being able to share this. So I started as a software engineer back actually in the late nineties during the, the first.com bubble and have, have spent quite a long time actually as an individual contributor, probably working in software engineering teams up through 2014 at a minimum until I joined AWS as a customer facing solutions architect. I do think spending a lot of time, hands on, definitely helped me with some of the imposter syndrome issues that folks suffer from not to say I don't at all, but it, it certainly helped with that. And I've been leading teen at AWS since 2015. So it's really been a great ride. And like I said, I'm very happy to see all of our engineering teams change as far as their composition. And I'm, I'm grateful to be part of it. >>It's pretty great to be able to witness that composition change for the better last question for each of you. And we're almost out of time and Danielle, I'm gonna stick with you. What's your advice, your recommendations for women who either are thinking about getting into tech or those who may be in tech, maybe they're in individual contributor positions, and they're not sure if they should apply for that senior leadership position. What do you advise them to do? >>I mean, definitely for the individual contributors, tech tech is a great career direction and you will always be able to find women like you, you have to maybe just work a little bit harder to join, have community in that. But then as a leader, representation is very important and we can bring more women into tech by having more leaders. So that's my, you just have to take the lead, >>Take the lead. Love that various same question for you. What's your advice and recommendations for those maybe future female leaders in tech? >>Yeah, absolutely. Danielle mentioned imposter syndrome and I think we all struggle with it from time to time, no matter how many years it's been. And I think for me, for me, the advice would be if you're starting out, don't be afraid to ask questions and don't be afraid to kind of show a bit, a little bit of ignorance because we've all been there. And I think it's on all of us to remember what it's like to not know how things work. And on the flip side of that, if you are a more senior IC or in a leadership role, also being able to model just saying, I don't know how this works and going and figuring out answers together because that was a really powerful shift for me early in my career is just to feel like I can say that I don't know something. >>I totally agree. I've been in that same situation where just ask the question because you I'm guaranteed. There's a million outta people in the room that probably has the, have the same question and because an imposter syndrome don't wanna admit, I don't understand that. Can we back up, but I agree with you. I think that is one of the best things. Raise your hand and ask a question, ladies. Thank you so much for joining me talking about honeycomb and AWS, what you're doing together from a technology perspective and the focus efforts that each company has on D E and I, we appreciate your insights. >>Thank you so much for having us talking to >>My pleasure. Likewise, for my guests, I'm Lisa Martin. You're watching the AWS partner showcase women in.