 from our studios in the heart of Silicon Valley, Palo Alto, California. This is a CUBE Conversation. Hello everyone, welcome to a special CUBE Conversation here in Palo Alto, the CUBE Studios. I'm John for your host. We're here with a special panel, talking about the new brand of tech leaders in this era of cloud computing, data, AI, and engineering excellence. With us, we have Christine Heckart, the CEO of Scalar, JP Cristina of MarthMorthy, SVP of Engineering at Copa Software, and Pavna, saying VP of Engineering at Glassdoor. Guys, welcome to come to the CUBE Conversation. Welcome. Thank you. Thank you. Engineering, you guys are all running engineering organizations. You've been a former engineer, now running a big company as the CEO, engineering lead company. This is a big trend that's clearly defined. No one needs any validation. Cloud computing has certainly changed the game. AI is certainly the hottest trend with respect to data, machine learning, and the benefits there. Changing the cultures of companies, changing how things are built, how people are hired, you're starting to see a complete shift towards old way and new ways. I want to get your thoughts about the engineering opportunities. What does engineering excellence today mean in this modern era? Well, for us, we talk a lot about mastery and setting up an environment where engineers have a chance to build their own mastery, but they can also have the necessary tools and technologies to be master of their domain. And these domains, especially if it's cloud-based, they're very distributed. They're very, very fast-moving. There's a lot of continual risk. So you have to set them up in the right way so they can be successful. Papna, what's your thoughts? I mean, you guys are cutting edge startup. Yes. For us, it's very important that the environment, the working environment for engineers is organically inspiring. And what I mean by that is when every engineer knows why are there, what are they doing and how their work is impacting the company and the business niche it is, at the same time, we are making sure that their interests are aligned with our projects and work in a way that we are also, in a healthy way, extending and stretching their skills. When their work has a purpose, and that's what our mission is, which is we want to make sure that everybody finds an opportunity where they feel there's a purpose, it's purpose-driven, that's when we feel like it. That's a great environment where they will be inspired to come every day and deliver their 110%. JP, excellence in engineering. I mean, this is what people strive for. So, excellent points from both of them. And I think I have a slightly different take on it as well. Today's businesses, we are asked to respond really, really fast. We hear the term agile everywhere, John, right? So it's about how do we respond to the needs of the business as quickly as you can? And it becomes the mantra for the organization. Having said that, there is another side to it. The dark side is technical debt. That's something we all have to grapple with because you're moving fast, you're making decisions, you're hoping things are right, you want to prove your thesis out there, but at the same time, you don't want to put yourself behind so that it might come and bite you later. So it's finding that balance is really, really important and that becomes the focal point of the organization. How do you move fast? But at the same time, how do you not slow yourself down in the future? That's a great point. I want to get probably your thoughts on this because open source has been really a different game changer from the old way to the new way because you can work with people from different companies. You can work on projects that are going to be betterment for other people as well. So it's got a communal aspect to it, but also there is an element of speed. At the same time, agile forces this kind of concept. So technical debt, you want to move fast, but you got to recover. You got to kind of know how to get there. How has open source changed that in your opinion? Well, number one thing that open source allows all smaller companies, especially bit more companies is that now you can take on an open source project and start rather than starting from ground zero, you can start somewhere where it's already helped and you have a framework ready to start working on. So you're not, every single time you're building or thinking of a new idea, you're not starting, okay, now let me just go start from ground up, right? So you already are at a certain level. The second area where, like you said, we are agile, we have open source, but we also have certain level of customizations that the customer is needed or application needs. And that's what inspires engineers as well, which is taking the challenge of, okay, we have a code base now, let me build something more interesting, more innovative. And then what they also love is giving back to the community. We are not, the companies are not just tech community and engineering team. We all have a bigger engineering community now, the whole tech world. And that's what makes a big difference for us working in Silicon Valley to even be part of that and contributing back to the community. JP, talk about technical debt when it comes back to the modern era because you can go back, it's been around for a while, technical debt concept is not new, but it's always been kind of the water cooler conversation with the core lead engineer and the team. The OSCs have a term called feature creeping. They know the old days, don't get at the feature creep. Agile kind of takes that away because if you're applying technical debt properly, you're managing the velocity of the project. So the question is, how has technical debt evolved to the management levels of senior engineering managers? Because that seems to be a key variable in managing the speed and quality of the teams with managing the technical debt. And it's now a management issue. What are some of the conversations? So again, it depends on the stage of the company and the stage of the projects you're in. If you're in a really mature software environment where you're not making a lot of change, it's okay. It's not the primary conversation of the topic. But if you're trying to capture a market or to prove out an idea, it becomes the fundamental thesis for getting things out there quickly. Now getting things out there quickly doesn't mean you get to let users suffer. You have to build it in the right way, needs to work, but at the same time, it needs to be just enough so that we can get the feedback from the users. And at the same time, you probably would have left out potentially features. And maybe you didn't even make certain decisions on, let's say, high availability or scalability. Maybe you want to prove it out in only one region of the world and so on. So you have to find those balances and it becomes part of the planning conversations right in the front. And as you go into the further iterations of the product, it becomes part of the prioritization conversation with the product managers because it's not just about getting one part done and getting it out there, but as it reached the full level of maturity that you would want. I'm sure there's a lot of debates about in the engineer organizations because your engineers are very vocal, as you know. So you can fall in love with your product. If it's a time to market, maybe taking some technical debt to get product market fit. And that's my baby though when you got to re-platform or rescale it to make it scale, bring it to your point you mentioned. How do you guys manage that? Because this becomes a talent management. Some people say, oh, you got to manage the Ecos, but if some people are managing the projects and they're going too far over their skis on technical debt, you got to kind of rein that in. How do you guys manage the people side of the equation because it's an art and a science at the same time. What's your thoughts? Well, I'll say this. Supporting all aspects of change, right? That's also, as an engineering leader, it's a core responsibility and a quality priority for us. Not just the technical debt, but also the market shifts, technology shifts. We have new tech coming in. We are evolving every technology. So how do we adhere to and make sure that it's very important that engineering is supporting and kind of coming up with these technologies at the same time, we are not just pulling down to their version upgrades and all of that. So to, in a just, it's a core aspect of leadership to make sure that you, as we are supporting these changes, we are also making sure that these changes are not pulling us down. So there should be proper quality checks. There should be proper conversation and roadmap items which is saying that it's not a tech debt, it's more of a tech investment. And we are talking about, so that we are in lock steps with our business partner and not behind. So that now we are saying, okay, we need a whole quarter to develop new things. So it's an aspect of making sure a team is motivated. So this comes back to culture. Next question I want to get you guys' thoughts on is, building a positive work culture. You have an engineering led organization, Christine, you're leading that now. It's a startup. You guys are growing real fast. A lot of, you got a lot of engineers there. So probably a lot of opinions on what that looks like. What is the culture equation? Because this sets the DNA early on for startup. But as you are maturing organization, you got to attract the best talent. Some say, well, we work on, we solve hard problems. That's kind of the cliche. But ultimately you do have to kind of have that the problem solving aspect. You got to have a culture. What is a successful work culture for engineering? So everybody talks about engineers want to solve hard problems. I think that's true. But as Povna said earlier, if you can help every engineer connect what they're doing every day to the higher purpose of the organization, to the problem that you're solving, and how that makes the customer's life better. In our case, we're a company by engineers for engineers. So our engineers get really excited about giving other engineers in the world a better day. We have taken it one step further recently by starting a peer network because one of my observations coming into this organization is there are so many peer networks in IT because it's been a 30 year industry. There are tons of peer organizations for CEOs. There are tons of peer organizations for CMOs. But there really aren't for engineers. And if we want to help engineers really develop their career and their full skill set and therefore develop into their full potential, it's about more than just training them. It's about giving them context and full social skills and giving them places where they can learn not just from the other engineers in their company, but from engineers across the industry at their same level. And maybe from very different industries and maybe in very different environments. So I think in our case, really trying to bring these peer networks together has been one way that we can not only pay it forward for our own engineers, but also help a lot of other engineers around the industry. How are you guys handling the engineering talent? Retaining, attracting, and keeping the best balance? So I think that's where the whole company comes together in my view. So as an engineering leader, it's not just that I set the tone of my engineering org as to what that hiring is top priority. It's where the whole company comes together. You're recruiting team to build the stellar interview process. You're, you know, heads of other orgs to make sure that across the board you're helping define a mission for your company that resonates with your candidates who would wanna work with you. So it's a collective effort of building a stellar environment. For us, Glassdoor, one of the few values is transparency. And we live and die by it, which means that when someone is hired, they need to see that we, within the company, we are transparent. So we share a lot of data, a lot of information, good and bad, with every single person in the company. It's never hidden. At the same time, we build and set that trust in them to say, okay, it's confidential. Make sure that it doesn't leave the company. And it's been 11 years, and it has never been the case. Well, Glassdoor, you don't wanna have a Glassdoor entry on Glassdoor. You gotta be transparent, that's for your culture. That is true. And culture matters. I mean, your culture is all about sharing and being open. You will see, so the reason, this is what Glassdoor stands by for as well, right? Building transparency within the company culture. And more and more, as we see many stories that we have seen from various companies, and sometimes I get a bad story too, and I get an invitation, oh, you're from Glassdoor. But that helps. Overall, we are living and working for users and professionals. Trust is big for you guys. Absolutely. Professionals who are in this world looking for a job and life because you're spending a lot of time at work. So we want you to get up every day and be inspired and happy about where you're going to work. And for that, that's why we are sharing a lot of insights about the companies from reviews and ratings and CEO data to make sure that when you make your decision of the next move, you can be fully trust, you can be fully confident that the data we are sharing with you, with that, you're making a good decision. J.P., your thoughts. You guys are on a tear. We've got a great coverage of your annual conference in Vegas recently in Cube Coverage. Your company on paper looks like you're targeting one segment, you have a lot of range in your technical platform with data. How are you guys articulating to engineering? How do you keep them? What are some of the stories you tell them to attract them to join you guys? So number one thing is about the talent that we already have in-house. So people want to come to work at a place where they can learn, contribute and also further career as well both inside Coupa and as they leave. And coming into Coupa, they look at it and they say, oh, you have a wide variety of things going on here. You're solving a business problem, but at the same time, the technology stacks are different. You are on all the best clouds out there. So that's an easy attraction for them to come in. But also, it's not just about getting people and how do you retain them? And we've been lucky that we had very low attrition for many years right now in the engineering organization, especially in the valley, it is a big deal. And I think part of the things that drives that is the collaboration and the cooperation that they get from everybody. And it's an age old saying, diversity and thought, unity and action. So I really promote people thinking about various ideas and alternatives, but there is a time for that debate. And once we agree on a solution, we all pull in and try to make that successful. And when you repeat that often and it becomes part of the culture and the way the organization operates. As a follow-up to culture, one thing that's become pretty clear is that it's global. Engineering, you mentioned the valley, very competitive. Some startups that they get on that rocket ship can get all the great talent. If you're a public, everyone gets rich, everyone's happy. A good mission behind it, win-win. Outside, some startups have to attract talent. You've got a startup going on here. You might have a good kernel of great engineers, but you have development environments all over the world. So remote is a big thing. How do you manage the engineering with remote? Is it time zone-based? Is it put leaders in charge? Is there a philosophy in Amazon? Has a two-pizza team? Is there a big thing? Get small groups. How do you guys view the engineering makeup? Because this becomes a part of the operational tension but operating model of engineering. Thoughts? I can go first. I think there is a tension between keeping teams working on one problem and not distributing it across the world for efficiency reasons. But at the same time, how do you allow for continuity? Especially if you have a problem in one area. Can somebody else from another region step in in a different time zone and continue on that problem? So that's always a problem. And then the other one is in a landscape like ours, which is not uncommon for many, many companies, it is not that they built a lot of fragmented things. They all need to work together. So having a level of continuity within the various remote centers is really critical. And everybody has their own recipe for this one. But the ones that works for us, and I've seen that played out many times, is if you can get a set of teams to focus on certain problem areas and become experts in those. Are cohesive within their team work, physical space. And then also have enough critical mass within a center that gives you the good balance between working on one thing versus knowing everything. So that works for us. I think that's the way to go. That sounds like an operating system. It is. Kind of two-couple, highly cohesive. And you need to have the right technical leaders on both sides and be willing to collaborate with each other. Pop the thoughts. I want to emphasize on the last statement, you really need strong, good, really trusted leaders in the location to kind of then inculcate more bigger team and everything. Glassdoor grew from one location to four locations in the last three years. And one thing that we learned after our first remote location that we started was that when we seeded our new remote location with few people from the original location, that helped start the similar aspects of what Glassdoor stands for and our core ethos and values. And then as we added new people, they just kind of easily, it just transferred to them. So that helped us in a big way. And then we moved to Chicago with the same idea and of course, Brazil now with the same idea. So knowledge transfer, culture transfer. It all makes it easy when you have few people seeding from the original location. That was core for us. Pop actually started their first remote office in San Francisco, which has now become their headquarters. So she has a lot of experience. Yes. Every one of scaler's customers globally, we sell to engineers. So we're dealing with our customers who are dealing with this problem all the time. And in addition to culture, one thing that seems to bubble up regularly is can, do you know when they need a common tool set and where they can do their own thing? How do you balance that? And where do you need a single source of truth that people can agree on? And again, where can people have different points of view? You're talking single sources from code base to what could be whatever. Like in our case, it's, yeah, if you're going to troubleshoot something, where are the logs, the truths in the logs? Or are you going to have a single source for that? But for other people, it could be the data that they're bringing in or how they analyze the business. But if you can be proactive about understanding when is commonality of tools, of approach, of philosophy, of data, whatever, when is commonality going to be what we drive? And when are we going to allow people to do their own thing? And if you can put that framework in place, then people know when they have the latitude and when they got a snap to grid. And you can move a lot more quickly. And there's kind of a technical debt that isn't code-based. It's more about this kind of stuff, right? It's tool-based. It's process and culture-based. And if you can be more proactive about avoiding that debt, then you're going to move more quickly over time. And the video conferencing, very important. You should be able to jump on a video conference very easily to be able to connect with someone rather than just a phone call. So all of these face time, different ways of face time. Technology plays a big role. This is a modern management challenge for the new way to lead because it used to be just outsourced. Here's the specs, remember the old PRDs and MRDs? Here's the specs and you just kind of build it. Now it's much more collaborative to your point. There's real product and engineering going on. And it's got to be, it's evolving. This is a key new ingredient. Because the expectation on the quality of product is so much more higher. The competition is so much more higher. And when these engineers build it, in a lot of cases, they have to operate it now. So like you say, whether it's a free service to a consumer or it's an enterprise, the expectation is perfect. No downtime, no hiccups. And the reward incentives now become a big part of this now, new way of doing things. So I got to ask the natural question, what's the reward system? Because Google really kind of pioneered the idea of, oh, it's like 20% of your time, work on your own project, that was about a decade or so ago. Now it's evolved beyond that to free lunches and all these other perks. But it's got to appeal to the human being behind it. What are some of the reward mechanisms you guys see as management that's helpful in growing, nurturing, and scaling up engineering organizations? Well, engineers are human. And as every human, autonomy is critical for any aspects of motivation. And that's what plays the core level. And of course, lunches matter. And other perks and benefits matter. Snacks, of course. Good coffee machine definitely is the core of it. But autonomy of what you want to do and is it aligned with what we want or what we are trying to deliver and the aspect and the information of, I did enroll this out, what was the impact of it? That new should go back to that engineer who built that. So threading it through to the end and from the start is very core for everybody to know. Because I want to know as I'm going every day, how is it helping? And we really try, I personally try to make sure that each human on the team, regardless of their function, that we understand their potential and their career aspirations. Because a lot of times the normal ladder, whatever that ladder is, might not be right for every person. And people can pivot and use their skills in very, very different ways. And we need to invest in their ability to try new things. If it doesn't work out, let them come back. So we try to spend time as a company for engineers, not just in our company, but beyond, to really help them build out their own career and build out their own brands. Engineers more and more can be on TV shows and doing blogs and building out their own personal brand and their point of view. And that gives them impact that goes beyond the one piece of code that they're writing for a company in a given day or week. JP, you guys, when public stock options, all these things are going on as well, your thoughts? Yeah, I just came back from a trip to my newest Dev Center in Hyderabad, India. It's funny, I had sessions with every team out there. The number one topic was food. They were so excited about food. So there is something, you know, primal about food. Having said that, I think, price and recognition, the age-old things, they matter so much. That's what I've seen. When you acknowledge what somebody has done and kind of feedback to, like Pavna was saying, the impact that it creates, you know, it's a lot more fulfilling than monitoring incentives. Not that they are not useful, you know, occasionally they are, but I think repeating that and doing it more often creates a sense of, okay, here's what we can accomplish as a team, here's how I can contribute to it. And that creates an overall sense of purpose. Awesome. You guys talked about tools as a commonality, it's kind of key. There's always going to be debates about which tools, which codes, languages to use and coding, et cetera. But this brings up the notion of application development as you get continuous development. This is the operating model for modern engineering. What's the state of the art? What are you guys seeing as a best practice as managers to keep the machinery humming and moving along and what's on the horizon, what's next? You know, in my view, I would just say, so what's humming and what's state of the art, I think AI is core to most of the systems and applications, the core aspect of pretty much every company, as you see, and that's the buzzword even in Silicon Valley, for the right reasons, is how we have built our platforms and systems and ideas, but now let's make it smarter. And every company now has a lot of data. We are swimming in data, but it's very important that we can pick and pull the core insights from that data to then power the same product and same system to make it more smarter, right? The whole goal for us ourselves is we're making our platform more smarter with the goal of making it more personalized and making sure that as users are navigating our pages, they are seeing more personalized information so that they're not wasting their time. There we can make faster decisions in more rich data set, which is very catered towards them. So building that intelligence is core. And with continuous integration comes continuous risk, right? So no risk, no reward. And so we live in an era of freemium, free services, so why not take the risk? You don't have to do an A-B test, you've got digital, you can do A-B-C-D and use all kinds of analytics. So this is actually a creative opportunity for engineering as they get to the front lines you mentioned earlier, getting part of the empowerment. How is the risk taking changing the management? You know, I deal with a class of users who are willing to pay money, so I don't know if I can talk a lot about the freemium aspect of the problem. But there's always desire for new functionality if you want it, otherwise you don't want it, right? There is a lot of risk averseness that's still floating around, especially in the enterprise out there today. And it is a big tension that you have to deal with. And if you are not careful, then you can introduce problems. And today when you're operating on the cloud and you're servicing thousands of customers, a small change can bring down the entire ecosystem. So you have to take it very seriously, you're helping others run their business. And that means you have to invest in the right tools and processes. So you guys are obviously a freemium business model, but still engineers got a test of, they want to take the risks. So is it a cloud sandboxing? How is the risk taking managed? How are you guys encouraging risk without having people hurt them? Yeah, you don't want to over burden engineers to the point they feel stifled and they cannot do anything. So there is a right balance. So there are many techniques we follow. For example, we roll out the software to a staging environment so customers can play around and make sure things are not breaking for their comfort more so than for us. But it is an important part of the equation. And then internally you have to invest a lot in planning appropriately. There are the high risk content on the features and then there are the low risk ones. You want to think about experimentation frameworks, you know, A-B testing and so on. And more importantly about automation and testing. I don't think if a customer logs a bug and finds that problem, they don't want to see it one more time ever, right? So you really have to make sure that those things don't happen and you have to invest in robust automation around testing processes because there isn't enough time for the complexity of these applications to test anything manually. These were automation with the cloud comes in. Containers, Kubernetes, new types. All of those things, you know, you had to enable engineers with the technology set so that they can test at scale. You had to provide access to production like data because you had to worry about privacy, security and all those aspects. But at the same time, they need to have access to the variety of configurations that are out there so that they can test it meaningfully. So you have to invest in all of those things. And then I'll take it back to kind of where we started this which is the human factor with continuous delivery is this continuous risk. And it doesn't matter if this engineer is supporting a free consumer application or the highest end of enterprise. When something goes wrong, their stress level goes through the roof. And, you know, how can we equip these people to solve problems in real time, to have that visibility, to have whatever tool set or data, whatever they need because at the end of the day, a bad day for an engineer is a day when something is breaking and they're the ones that have to stay up all night and fix it. And a good day for an engineer, a human being, is the day they get to go home and have dinner with the family or not be woken up in the middle of the night. And there is- Or kite surfing or whatever they do. Yeah, whatever they do. But there's, you know, there's truly a human, we think about engineers and engineers get up every day and they want to change the world and they want to make an impact. And thank God we have, you know, teams of engineers that do that for all of us. And they're human beings and there's a level of continuous stress that we've injected into their lives every day. And to the extent that we as companies and managers and leaders can help take some of that burden off of them, the world becomes a better place. And how they're talking about the whole being seeing the results of their work too is rewarding as well. Right. And Scaler does a lot of stuff there. So I have to call that out. At the same time, you know, a lot of very good nuggets JP brought up, but one more thing that has shifted in terms of how a process or practice works is more and more engineers now participate very early on in product development phase. And they try to understand what is the context and why are we doing, and we do a lot of user research to understand that process so that they have full context that they are building and developing. So they are more of a partner now and not an afterthought. I think Agile and DevOps to me has proven that the notion of silos and waterfall practices has democratized and flattened the organizations out where interdisciplinary crossovers are happening. Oh yes. And this has been an interesting art of management is encouraging the right person to cross over the right line. And in other words, you give people a little taste but sometimes they may not be long and you got to kind of, these are called herding cats in the old days, but now it's more of managing kind of interests and growth areas. That original DevOps model though, if anybody read the Phoenix project like years ago, but it was really about bringing different points of view. It's a diversity thing. It's bringing different points of view around the table before the first line of code is written so that you're thinking about every angle on the problem and on the ongoing operation of whatever you're building. Well, let's talk about diversity and inclusion and diversity. I always like to say it's inclusion and diversity not diversity and inclusion because male and females are involved. We have two females in tech here. This has been a discussion. We still don't have the numbers up to the senior levels within engineering in general. What has to happen to move the needle for women in tech and or inclusionary people involved in engineering to get the right perspectives? What's needed? I'd start with JP because he's actually a huge champion and without the men involved, we don't have a solution. Inclusion and diversity JP, your thoughts on this was super important. Yeah, number one is recognition in my opinion, John. I mean, I was telling Christine yesterday, I just came back from India as I told you, took a picture out there of my management team, came back here, looked at it. There is no female, no woman, right? It's crazy. I mean, it's not that we are not trying and we had the same problem when we started our center in 2015, right? There was a group picture of the team. There were two women on the team. We put a lot of effort into it and two years later, a significant chunk of the organization has got women embedded in the teams and it came because we tried. We went out, looked for those who are good in this area. It's not that we compromised on the qualifications. It's really about putting some energy into getting the right resumes and then looking at it. The other thing we are also doing is cultivation. You have to go to the grassroots because there aren't just enough women engineers. It's unfortunate for whatever reasons they are not taking up that profession. I mean, there are enough studies written on it. So last two years, we have conducted something called Rails Girls in India, 150 school-age children, women, I mean, girls come in and then we have supported them, run their classes, whole day classes. And that helps, even if 10% of them choose to take up this profession, it's going to be a big boost. And we have to do a lot more of those in my opinion. You're a T.R.I.S. President, leading, engineering. What's your view? Well, I'll say this, you know, for the people who are participating in helping drive this mission, just like JP, I say thank you, especially for men who are participating in it. We cannot do this without you. But for all the people who are, if they're not participating in helping drive this mission, I'll share this one data. One of the initiatives that Glassdoor drives is gender pay gap, which is also an outcome of not having diverse outlook at all levels in the workplace. And we, in our economic research team, they did a study and they shared a projection of when will we close the gender pay gap? It's 2017. That's depressing. So for me, when I hear people who say, you know, they don't want to participate or they don't think this is the right approach of solving for diversity in workplace, I say, okay, but that's not the reason for you to not participate and stay out of it. Join it, join it in your own way. But it's only when all of us can see it as a real problem and participate, just like JP, as you said, grassroots level as well as outside. One of the example that I tell my team when they say, you know, we don't want to drop the bar, the quality bar, I say, sure, don't drive it, but don't drop it. But if you have two candidates, one with a diverse background who might be applicable to the same job in two to three months over someone who's slum dunked today, let's invest in the person who is bringing the diverse background for two to three months and then make them successful. That's not dropping the bar, that's still supporting and investing in helping the diversity. My good friend, Ian Heats, you saw at IBM, they put out a survey that said diversity, inclusion diversity first companies have a competitive advantage. So the investment is so much about lowering the bar. It's more of bringing a perspective because we're talking about software here. Software has male and female and the audiences are not 17% female. But it's not just, you know, I add two things to the comments, all of which I agree with. One, it's not just a pipeline problem. It is a culture problem where people have to feel welcome and it has to be a comfortable environment and they have to believe that their diverse point of view matters and it doesn't matter if they're men or women. But there are lots of times when we all make it hard for somebody with a different point of view to enter the conversation. So we have to do a better job of creating the culture. And secondly, there's a saying, you have to see it to be it. We have to see people of diversity, gender and of every other type, cognitive diversity of all types at every level in the company. And you know, we had the same thing so I'm lucky enough to send a Fortune 500 public board. And I spend a lot of my time helping women and people of color and diversity get on public boards. But if you go back seven years ago, we were 14% women on public boards and it did not move. And it did not move and it did not move. And in one year it popped over 20%. And that's before the loss. So, you know, you make these linear projections, we can with effort actually make a difference. It just takes a very concerted effort. And in this case, particularly for engineering and for leadership, it is making a concerted effort at every level from board to CEO, to executive team, to all levels down, making sure we have inclusion and diversity in those ranks. This is a modern management challenge in the new way of leading. Managing this process. This is the big challenge. This is the big challenge. Folks, thanks so much for coming on. I really appreciate it. Final question for you guys is, what is, if you could summarize the new way to lead in this modern era, from an engineering standpoint, building out a company, building a long durable value creation where it's company or product or service, what is the key, key to success? As a leader. As a leader. As a new brand of leaders. I would say, you know, this lot goes into, I'm sure you need to know engineering and all the strategic aspect of your job. But the core aspect I feel is, as a leader, my success depends on the quality of relationships I'm building with my team and members that I work with. So that goes into the people aspect, the people connection that goes into it. Jay, pick your thoughts. Absolutely, people are a big portion of the story. I also feel understanding the problem and driving for results. You know, it's not just about building something, it's about building for a purpose. What is it that you're trying to accomplish and continuing to refine that and working with the teams is so critical for success, especially in a fast moving environment. Christine. Yeah, I agree. It is all about the people and I think old and new, this hasn't changed. People need to feel like they belong and they're being appreciated and they're being heard. Scale, Glassdoor, CopaSoft, where you guys do great work. Thanks for sharing the engineering inputs to leading successful companies. Thank you, John. Thank you for the leadership. Thank you. Thank you so much, John. I'm John Furrier with theCUBE. Thanks for watching.