 So I'm really excited by this. Diversity and inclusion is something that defines CNCF. And if we are not diverse, if we are not inclusive anywhere, anywhere, project, event, please let us know. These are the people who are going to make a difference. I, as a governing board chair, I can make a difference. Please keep us honest with that. So with that, what we're going to do is we're going to start. Nikita, maybe we'll start with you. Start with your name. Start with your role in CNCF. And keep your answers crisp. Walk us through your individual journey. What was your first engagement with Cloud Native? And what was your path to get here? I know we can all tell long stories around it. But let's see what we can do. OK, that seems like a challenge. So I started out in the CNCF actually as an intern with Google Summer of Code long back, many years ago. Became a Kubernetes maintainer. At that time, Kubernetes was still in its nascent stages. But it looked like it showed a man's promise clearly. And I started contributing to it, worked with many SIGs in the project. I think one of the things that helped was doing a cross-sig work. So you meet a lot of people. You meet a lot of bright minds in the ecosystem. And then slowly, gradually learning from there, taking up more responsibilities and leadership positions. So a technical leader for a special interest group in Kubernetes. And then finally, joining the Kubernetes Steering Committee. And then now I'm part of the CNCF Technical Oversight Committee along with Emily Anlin. And I'm also one of the co-chairs for this conference. Yeah, I think that's kind of some setup. Hi, everyone. My name is Linsang. I'm the director for Open Source as Solar.io. I actually got involved in Cloud Native before Cloud Native Computing Foundation was formed. So in 2014, my management team asked me to work on Docker and providing Docker as a service for IBM Cloud. That's when we were not sure if Kubernetes was going to be the winner. And then I remember at one point when Kubernetes was donated to CNCF, we jumped on the bandwagon of Kubernetes. And IBM was a founder of Istio. I was one of the founding members. When Istio project has been created in 2017, and since then I've been primarily contributing to the Istio project. Hi, everyone. This is Nancy. This is my first KubeCon. So yeah, so I work as an engineer at LocalStack. I am a C and seven Basidore. So my first, like I've been using these technologies like since when I was a Google Summer of Code student. But it was the first time at Kubernetes, when I saw Arun Gupta and then Nikita giving the keynote about how to contribute to Kubernetes. That was my first time when I got to know that, OK, awesome. These are the technologies I've been using. And there's a huge community behind this. So that was my first interaction. And that inspired me to write my work in the blogs, giving the talks and the meetups. So that's how I started contributing to the community. It expanded to being a part of tag environment sustainability. And I'm going to co-lead the cloud-native sustainability week this year, in which basically, if you have a focus on sustainability and tech, you could come with the meetups in your local areas. So if someone is interested, please ping me over Slack. So yeah, that's about me. Hello, everyone. I'm Emily Fox. I chair the Technical Oversight Committee, where Nikita is my vice chair, and Lynn also serves. And it's my first time meeting Nancy, so it's great to finally meet her in person. I got started and cloud-nated at KubeCon Copenhagen. And I went to all of the maintainer track sessions, because I was trying to understand what this thing called Kubernetes was, and cloud-native technology, because I needed to take that back for a project I was working on. It started with getting over my fear of asking a question on a microphone in front of a very large audience, much bigger than this. To ask a very pointed question of, why are you doing security assessments of open source projects, and how are you actually doing them in a way that's observable and transparent? And that ended up with a lot of contributions to documentation and tag security, establishing security assessment processes and best practices for them, and then becoming a security reviewer, and then a lead security reviewer of various cloud-native projects. And it's been an uphill trajectory since then. Wonderful. Thank you. Thank you. We want to leave some time for Q&A from the attendees as well, so we're going to move crisp. What are some of the characteristics and qualities of a cloud-native technologist that prime them to be a leader? And what is one tip that you will give that start here if you were to start? Emily, you want to go start? Sure. So I will start with a tip, be humble, and ask questions. That's the best thing that I can tell people is staking the opportunity to learn and being emphatic in your desire to understand something can allow you to get a better connection with both individuals as well as with projects so that you really show that you're passionate and you care, and you can represent their interests in all the different areas that you engage. Yeah, I would add to last year, I had the opportunity to went to the Leadership Summit with Aron, and Jim Sembling was there, and he started to talk about three edges. So that's what I remember. I think I'll remember for the lifetime of me. So three edge stands for be humble, be helpful, which Emily talked about, and also be hopeful, right? As a leader, when other people are done, you want to be able to cheer them up and let them know there is a future, a bright future ahead of us. Yeah, I kind of have a, I think we're selfish, and that makes us a good thing. Selfish in the way that we've learned so much from cloud native, the community already, and that we love it so much that we want to give back. So we take up more responsibilities to take up more strategic responsibilities and keep this magic of cloud native alive. And while we do that, I think the other thing that I've seen is like you take up, like for growing as technical leaders, this also means that when you're taking up more responsibilities, you're making room for others to grow. So I think that's like one of the biggest things that being involved in the cloud native community or the open source community helps you in being like great technical leaders. One tip I'd say is, I think this is the spot for that, like build good partnerships or like build partnerships with people in the community. You can interact with Slack, people with Slack, Lloyd, on Zoom, but the main magic is when like you interact with people in person. So I know it's the last day of the conference, but as much as you can, build connections and I think that'll go a long way. Yeah, agree. That's how we got connected, Nikita. And she helped me a lot in Bangalore, like while organizing the sustainability conference for the first time, any conference. I would say that maybe have a big no mindset because that really helps. If you have a big no mindset, you can take the responsibilities in any of the area where people need that, where people need help. So that really helps in the community, just take the responsibility, execute it well and just help each other. Yeah. Be hungry, be foolish, as Steve Jobs said and as Jim Zemlin says, helpful, hopeful, humble. I mean, that is an inherent trait of any leader and particularly in CNCF, those traits are extremely highly valued. We all somewhere start with some sort of engineering and as we move on to senior roles, we tend to move away from pure engineering which is like coding as element of it. And not everyone codes, but we move into strategic work, right? How do strategic work play out when we talk about open source and cloud native? Like what do people think about it and what do people from non-engineering background can do? And then is it just program and project management or is there more to it? So I'll just touch on that briefly. I'm not a software engineer. I don't program, I don't code. If you saw it, it looks absolutely atrocious. I haven't done it in almost a decade, I feel like. But for me, I have an engineering mindset. I do a lot of design thinking. I do a lot of security assessments. And that allows me to do pattern recognition and more strategic and abstract thinking around software engineering architectures and how different teams can interoperate with each other. It's really building on those smaller discrete components and seeing how they can all fit together. That's where our strategy starts to come in is you're just moving further and further up the stack and abstracting everything else farther below and delegating those responsibilities to others. Yeah, so for me, I try to be recognizing people. That's, I feel like, so first, that's very important for me as a leader out there. I'll be able to recognize in people, give shout out to people in the community doing good work and people in my company are doing good work. The other thing I'm trying to do is I always think of myself as a user. So when I'm not writing the code, I want to always play with our projects and play with our project and how it integrate with other projects. For instance, I work on Istio. Now I'm looking at how backstage can be potentially integrated with Istio. A while back I was looking at Cillium. So I always try to think in the lens of the user and think about how we can make developer and user life easier and then use that to drive strategic decisions of the project, certainly, but also most importantly, because I work for a vendor. I want my vendor to be successful because they are the end of the day. They are the one paying my paycheck. So I do provide a lot of input to my leadership team as far as how we can be successful as a vendor, how the community can be structured to allow vendor to be sustainable. So we're not just doing pure open source, right? Because at the end of the day, if my vendor are not making money, my job would be impacted. The community could potentially be impacted if no other vendor can be successful in the ecosystem. So those are the three folds I'm taking. Yeah, I'll keep this quick. I think just to build up of what Lynn said, I think as you grew up the ladder or taking more strategic responsibilities, you also wanna make sure that you're fostering more ecosystem integrations. And as part of the TOC, we also don't wanna, like there's no king making in the CNCF projects. So we wanna make sure that a lot of projects that work around the similar domain thrive and integrate with each other. And also, I think one of our roles also involves identifying the emerging trends AI anyone and just kind of defining what the overarching goals and objectives of the CNCF or any project should be. Yeah, so I'm just gonna quickly say that. I think in my opinion, community collaboration, because that's something which I do the most, it's really helpful. And the customer centric mindset, like basically knowing that your end users is something which you're developing. Is it really aligned with end users? Are they really able to use it or maybe they need new features? So basically this whole product feedback loop is really important whenever we are doing something. It can be the certifications which we have in the CNCF. It could be the open source project. It could be the enterprise product. Anything, yeah. Awesome, thank you. Now as technical leaders, technical leadership, which all of you are in a position of, we do a lot of balancing. We have day jobs. Len, you can start touching upon that, but we have open source roles as well. So what skills do you need to gain in striking that balance that make you successful in both worlds? I would just say like the biggest one that I'm learning nowadays is conflict resolution. So as part of the TOC, there's so many projects that we need to look at and sometimes we need to tell projects that, hey, you're not doing a good job, but figure out what's going wrong and then suggest the right parts and people sometimes don't like to be told that, hey, you're not doing a good job, but this is not great. So learning how to give that feedback, backing that up with data and kind of working with conflicting interests and also contributors come from different companies which might have divergent agenda. So like working with all of these ideas and opinions and finding common ground, I think that's a big one. And also translates very well to I think your day job or just anything that you do as a technical leader in finding alignment and helping in like decision making overall. I'll just say communication. I can't say that enough. There's, as a security engineer, a lot of what I do is translation between two different very separate teams or individuals with different skill sets and being able to speak the same language to both of them and then cross that to the other. That's the best thing that you can do and that skill set pays dividends both in your career and open source and in your personal life. I guess I would mention communication because most of the time we, I mean if we can improve the communication, we can have effective communication in our, the open source part of thing, even in the day job. It's just gonna help us with the balance because most of us work synchronously in the teams, in the tags. So we already have pretty much like all our meetings. We document that so that we can, if you're not able to join that, I'm not able to join because of the time zone issue. So I can just go back and read those docs, whatever happened. I can see the recordings. So these are the things which really helps me with the balance, basically someone thinking that how can we have effective communication? Yeah, I would say I'm probably the exceptional here. Given my title is working on open source. I actually working on open source probably 75% of my time, which is, I feel like extremely, extremely lucky, right? So I spend a lot of time just to educating my management team on, hey, my work is being appreciated, hey, how my work can potentially help the company, which is really, really helpful so far. My manager hasn't told me to hold up much on open source, so I really feel so much appreciated. But one thing I do realize that a lot of time is actually not a lot of time contributing to open source. Like I started in CNCF beyond my Istio project, which I've contributed a lot of time. I think I made like 8,000 contribution to Istio. But outside of Istio, when I get involved in tech network, it's only like maybe five hours per month. It's not a lot of time. And I could potentially do that even when I'm a full-time developer on proprietary software, yeah. Wow, 70% of the time paid to work, 75% of the time paid to work for solo? For open source, for Istio? No, but buy solo, buy solo. That's a cool company to work for, you know. I mean, if you're paid to work on open source for 75% of your gig, that's pretty awesome. Yeah, exactly. Because that's what we need more. Exactly, I feel like the management team are so appreciative. And I actually, I'm also a manager too, so I actually manage a few engineer who also contribute to open source. So that's the one thing I really love about our company. Not only we're working on leading edge, but as a company of 150 people, we actually have a dedicated open source team, so that's pretty amazing. That's pretty awesome. And I would echo the comment that you folks made about comms. And one of the effective techniques that I've learned over the years is very radical technique, reflective listening. Listen with an intent to respond, sorry, listen with an intent to understand as opposed to respond back. Otherwise you've lost the thought and you are listening and you're trying to respond back. So listen first, try to understand, soak up the person, then respond back as opposed to react. That's pretty important. But not just respond back, clarify your understanding. No, understand, exactly, yeah. So there is no scope for you to pass your opinion until you have understood the other person clearly. That's super important. Because once you have understood the other person, they're more likely to hear you. Otherwise they're like, you didn't even understand my point. Who are you to make a judgment call on me? So I think that's super important. Lynn, again, you started getting ahead on my questions, but how do you people educate your management? What incentive mechanisms are created in the company so that you can continue to work? Sometimes it doesn't add to the bottom line. For a startup company, there is a bottom line, there's a VC pressure, or even for a big company, enterprise company, how do you educate and incentivize that within your company to be in a leadership position, particularly when it's not directly related to the product? Yeah, that's a great question. So for me, there are a couple of angles, right? So first of all, we are a big contributor to Istio. So we kind of structure the community in a way of, if you make enough contribution, you get a seat on the steering committee of the project, right? So like my company gets two seats, Google gets three seats, and these seats because they are leadership positions. So my company, sometimes when they are in sales conversation, they start talking about, look, we have these leaders in the community, and they do find it's useful when they are engaging in the sales communication, but another company, maybe they don't have any leaders, or maybe they just have one leaders. So that's one way to make sure my company knows the value of what I'm doing. The other thing is I also contribute to CNCF, right? So from Tech Network to now the CNCF TOC, I kind of educate my manager. I really try to increase the visibility of our company's solo, right? So maybe not directly useful in sales conversation, but the fact that people knows about solo because I was the one talking about it, I think that's a huge plus for the company too. Oh, yeah. So I'll talk. I used to work for Apple, and as you all know, Apple doesn't make cloud native products. We make phones and consumer goods, and electronics. For me, it was about the skills that you get in doing open source technical leadership roles, or really any open source leadership role is not anything that you will ever get from your employer. Doesn't matter how many leadership programs they put you through, you won't get the same skills that you get in open source. And those skills are, one, communication, the ability to actually run a meeting with an agenda and get outcomes. Finding people that can do that is very hard, and if you can do that in open source with people who have very different opinions, different incentives, different outcomes that they're looking for, you can bring that back in-house and you will be super successful. The other thing that I will add on top of that is mentoring others in open source gives you the opportunity to identify better paths to delegating other tasks internal to your company. In open source, you have no authority. Doesn't matter if you're chair of the TOC, or if you're on a steering committee, you have no authority. You are doing influence. That's how you're driving meaningful change. And if you can do that without a title to your name, or maybe you have one, but nobody's really paying attention to it, you can have the same level of influence in your company and in your organization. It's your presence, it's your passion. It's the fact that you show up and you're interested to ask the questions and that you're repeating back the things that you're hearing in a way that drives consensus collaboratively with others. There's nothing that an engineer wants to hear more than their own opinion being reflected in the strategy and the direction of a project. And you as a leader in open source, you can do that tenfold across thousands of projects across millions of contributors around the world. And having that level of impact, you will never get inside a company, but it provides dividends and business value back to them. I just want to add one quick thing. I think, so I work at VMware by Broadcom, and I've been involved in hiring a team, not specifically related to open source, but a product team that had certain percentage of time contributing back to open source. And one thing that's been really, I've done this across various companies of convincing managers, like, hey, let me work on open source, or let me let my team work this percentage of time. Initially they're like, oh, cool, like that sounds good, we'll get visibility. And then they start thinking like, hey, your time is getting affected, and maybe you could instead put this to work on a product, and that might help us better. So I think the one thing, this was also, I highly recommend checking out Bob Killenstock, he talks about how to convince, how to talk about the business value. And I think that's the most crucial thing, because I think we can convince management that, okay, whatever we're doing is important, but we're not using the right words. Executives might not necessarily speak the same language that we are talking about. If you say, hey, this bug solved this particular problem, they might not really get it, because they're not two hands down in the specific problem itself. But you need to talk about, even while if it's not affecting the bottom line directly, like Arun said, if you're getting close to there, or just talking about how it eventually helps the problem, but using the language that, I don't know, VP is, I don't know, you tell me, like reviews. I think that might make a big difference. How has your experience been along that line? Well, I love it. I mean, my team is all open ecosystem team, so everybody on my team is 100% on open source. So I love being at Intel, and this is the, like Emily, I used to work at Apple, and I remember reading Pat Gelsinger's letter back in September, 2021. He says, I have a strong bias for open source. And being at Apple, and reading that letter from a CEO of a company, I think, oh, wow. Here my manager doesn't understand the value of open source. Here the CEO is talking about open source, and if it's a top-down mandate, boom, it just flows in, because then you are talking to the middle management, or whatever, senior VPs. Pat wants us to do this. Are you in? Are you out? As simple as this. And I think one of the advantages of being at an executive position is, you just roll in. I want this to be done. How are you gonna do this? You figure it out. I'm okay in the implementation details, but I want this to be done. I think that's an advantage, having the budget and the title and all those things. But having that supporting management is super essential, and guiding them, nudging them, because I've been in the position up and down the chain. So I love it. And all right, I got 17 more questions, but we don't have time for that. I wanna make sure attendees have a chance to ask the questions. I think there is Mike down there. There's Mike down there, the hall. So if anybody of you wanna ask questions to these esteemed panelists, I'm not gonna be answering. They're gonna be answering. Please go for it. Any questions? Hey, panel. Good job sharing all of your thoughts. A quick question. Let's say that we're working for a younger startup, and they don't really value your time spent contributing to open source. You know, they don't see the value in that because they'd prefer your efforts spent more on the business logic that they'd prefer you to write. So have you seen this in the wild? How do you convince your companies that they should have at least some, like IOTA of bandwidth spend contributing to open source? I think I can just answer this first. So basically, so my first job was at Blinket, which is a grocery app, online grocery app, and they really focus a lot on business. I mean, tech was the second thing to them. They obviously wanted to improve the tech so that they have seamless experience. But in the team, I was the junior engineer back then, and I was lucky to have a good leadership. But what I saw, the leadership really admired the talent of open source people because they take extra mile to contribute. The other thing, like, this is how you can convince, we were using a lot of technologies back then, like Kubernetes, Grafana, Prometheus, and it had all the open source version. So one factor is the cost saving, and the other one is the community collaboration. So that is how I think our leadership convinced that we should focus more on the open source people, we should bring people who contribute to open source so that we are aware of the different technologies which are there, which can help us in the DevOps team, in the backing team. So, yeah, that is how it happened with me back then. I'll just add on to that and say that it's how you do things. For a lot of companies that are time and resource constrained and they want their engineers working on a product, or they want them working on a feature release, it's how you do that and how you carry yourself are what people remember the most, and one of the best ways to do that transparently, publicly, and building a brand associated with that is through open source. Startups come and go, they may eventually get bought, they'll be consumed, they'll be rebranded, but the people are the ones that you remember for the quality of the experience that you had engaging with them, either through a contribution, or them taking five to 10 minutes out of their KubeCon schedule to meet with you and answer your questions that you may have. That's what most people remember and that's another value that just puts a feather in the company's cap because you are your own brand, you are the thing that's going to bring customers to the company, to the product because of the work that you do in open source and how you conduct yourself in doing that. All right, we've got a question over here. Yeah, hi. You talked a bit about dividing your time between your day job and your leadership role within CNCF, obviously that's a big challenge because day jobs take a lot of time, leadership roles take up a lot of time, and add to that that the CNCF and the cloud-native landscape is developing really quickly. So how do you keep track of, do you even keep track of all the developments within the ecosystem and how do you combine that with your leadership role and your day job as well? Be okay with not knowing everything. That's the best piece of advice I can give. I chair the TOC, I've done security assessments of open source projects, I do due diligence on projects, I don't remember half of the ones that I do or remember the people and I certainly don't know all 184 projects in the landscape though try as I might. So being comfortable with the fact that you may not know something but you know the person to go to to ask the question to get the answer that it is that you're looking for and being humble about that, that's the best piece of advice I could have. Yeah, I can also add to, you also want to maybe participate more in the projects that related to your day job, right? Like I work on Istio, Istio is a security product so I kind of will indicate to Emily, I would be interested in security related project. So those projects, maybe it's more in your comfort zone that you would be, because it's kind of you are watching out what's growing in the ecosystem related to what you are working on. So those projects, you may have a little bit more insights into them but for the rest of the project, like Emily said, just let it go, delegate to the tag team and other people. I know I said I won't answer any question but here we go. It's very easy to get into that imposter syndrome that oh, this cloud native community is big and how do I find my way? And as Emily said, it's okay to be not okay. It's okay to not know everything. You know, just walk in with what you know, build on top of that and that helps you to be successful. Just make, do good in the area that you're doing and then slowly expand from there. Thank you. Very unlikely. Awesome. So one of the topics as a technical leader that you specifically mentioned it that you've been doing a lot more recently in is conflict resolution. So as a leader in a lot of spaces, right, that's something you're gonna have to do a lot of. So I would love to hear strategies from the whole panel about how to successfully do conflict resolution in this ecosystem. Emily, do you wanna take this one? So I have served on the interim code of conduct committee for CNCF when we had major community incidents. Conflict resolution doesn't just exist between individuals. It exists technically within projects as well. Part of the challenge is usually it's a communication problem. Somebody is saying one thing, someone else isn't actually listening, but they're replying anyways and there's obviously a disconnect there. So getting people to find commonality in the things that they're talking about is difficult, but if you can needle in and dig into what those differences are and where there's common, getting them to start that first step of agreement down that path is the right path to take. It'll take you a little bit longer. And in some cases you might have to have individuals, especially if you've got two software engineers that are super heated and opinionated on tabs versus spaces conversations. You might just need to take a step back and say what are we actually trying to accomplish here and just remove the personalities and what everybody's arguing about completely from the conversation and focus on what it is that you're trying to do. Too often as humans we like to get hung up on judgment and past transgressions and opinions and biases against individuals and you as a technical leader need to be the sound voice in the room that says I don't care what happened in the past, this is the path that we're going to move forward to get out of this so that everybody's voice can be equally heard or that we can get beyond this and be okay that this is not perfect. We're not gold plating things. Perfect is the enemy of good and we still need to make progress. If you often get stuck sometimes the best thing that you can do is to turn around and walk forward. You're not taking steps back, you're just changing your perspective and that's the best thing that you can do in some of these conflicts, either technical or between individuals is just have them try to see things from the other person's perspective. Don't just yell at them or talk at them, ask questions, sometimes queuing those prompts to say what, how, why, what is your reasoning and your justification? Give me your logic so that I can understand how you arrived at that conclusion and then I can reply and say ah, I see where you're going here, I'm coming at it from this perspective, this is where we have a disconnect and it applies whether or not it's two people having an argument about hair color or if it's two people talking about whether or not we should be writing WebAssembly and Rust or Go, any of those kinds of things. Yeah, I think Emily is right on. So it tends to feel female tends to be better at conflict resolution, I might be biased. So for me, I try to always think in the other person's shoes and I'm a good listener so I try to listen carefully on this one person, why they are thinking that way, this the other person, why they are thinking that way, what is their perspective, what is the background? After I have that thinking around, then I try to align them together, maybe leverage one idea, a part of the idea from one person, the other part of idea from the other person, because I find out when they find out some of their idea are being leveraged as part of the decision, they are much easier to give in to the final decision. A lot of time also just ask other audience, how do they feel, try to lean in on small inputs from other people to try to reach, you know, bring them together. Just one small thing to add to that is, I think we need to remember that even if there are disagreements, especially technical disagreements between people, oftentimes it's not out of malice. So just remembering that and ensuring that we're working towards a positive collaboration, keeping everything what they said in mind, I think that's the crucial part for me. Yeah, I mean, absence of conflict is apathy. We want that conflict, actually. And as a governing board chair, we look at sort of the conflict resolution all the time. And I think as Emily and Lynn were talking about, really think about, is it a personality conflict or is it a task conflict? Personality conflict gets emotional, puts a judgment label, oh, that person is saying, that person, that must break it down, make it about task, because then it becomes facts and data-based. What is the data? What is the reasoning behind that? Try to understand that. Once you peel the onion, it becomes a little bit easier. I'll just add one other thing. You never know what kind of day somebody had. They could be really angry and upset and it might come across as like an attack on you or an attack on the technology, but sometimes asking them how they're doing, seeing that they're visibly upset or that they're shaking about something, that can help break down that barrier. A lot of us have invisible problems that are not necessarily on the surface. I'm one of those people. I have significant nerve damage, so I'm in pain a lot, and I have really bad days today as one of them, so I'm keeping it together, go me. But asking somebody how they're doing, what is their experience? Why are they feeling that particular way? That can just sometimes eliminate all of the conflict because that's sometimes where it comes from. Yeah, just be kind. Just be kind, you know. Give them space, give them grace. You know what the person has been, and even if you don't know, give them that time. I think we are out of time, but any more questions? Well, if not, then I think we're gonna be, oh, one more question, last question. Let's wrap it up. It's, hi. It's not necessarily a leadership within CNCF kind of question, but technical leadership in general. So where at work we have various teams and subteams and team members, and some of them are, let's say, slightly more classical in the way that they view their things. So when they are given the option to own a project or tasks, they might never choose the open source thing because, well, it doesn't have a price tag, so therefore it cannot be good or similar ways of thinking. And it is relatively hard, even though they would have the freedom and the support of the company to make the choice and say, well, I'm going to low balance using a service mesh instead of this physical box that I'm going to put in my rack with a screwdriver. They will still not, by themselves, be able to make that decision because for some reason they are having a hard time valuing it. And with all the courses and all the YouTube videos we have, you can bring them to the information, because you cannot force them to eat the information, so any ideas on that? So one of the things that I learned early on in my career was media training, coincidentally, but also how to talk to a hostile audience. There are three kinds of people that you interact with on a daily basis. There are people that are already on your side. There are people that can be influenced, and then there are people that are going to be set against you. Knowing the people that are going to be set against you and avoiding them, or at least removing yourself from a situation where they are antagonizing you is probably the easiest path forward. Identifying the individuals that are influenced by you or that you can convince them to change their mind, that's where you should be spending the most amount of your time. They're going to eventually become your champions for whatever your ideas are. The people that are already on your side, they're your network. They should help you find those other individuals whose minds you can change. And as a technical leader, you should always have strong opinions, but keep them loosely held so that you can be adaptable to whatever the new and emerging technology is, because quite frankly, when I was going through school, it wasn't in computer science. It was through art. That's my background. But I realized that that wasn't a path for me, and when I started going down this technical road, virtual machines were just on their eyes, and I remember meeting with a bunch of graybeards talking about, oh, servers and racks. That's what we do. We do hardware engineering, and convincing them to adopt virtualization was a new thing for me to try to do, and eventually understanding what it is that they wanted, they were allowing themselves to be influenced, but they kept their opinions loosely held. All right, I think with that, we're going to call it a wrap, and I'm going to thank you all the audience and the panelists here. Thank you.