All righty, so I'm here to introduce Aaron Peterson. So Aaron is the SVP of Strategic Mobile Development at Timing. She's also the Executive Director of Outer Curve, an OSS Foundation focused on developing open source projects between enterprise software companies. She's a founder at Station 82, which is dedicated to providing technology access to rural kids. She's on the board of Girl Develop It, which aims to teach adult, particularly women, technical development skills. She was formerly the SVP of Paid Services Engineering at AOL. And before that, she worked at Microsoft in Amazon. She combines product management and technical management skills to spend time teaching at Girl Develop It. And she's a strong proponent of getting more people into tech and engineering roles. So with that, I'm thrilled to announce Aaron. Welcome. Hopefully I'm mic'd. Excellent, thank you. As somebody who runs engineering teams, one of the things that I spend most of my time thinking about is the people on my engineering teams. I think about how well they're doing. I think about how I can help them be more productive. I think about where I'm going to find more of those people, where I'm going to find the most productive possible people, and then how I'm going to make them as productive as I possibly can once I secure them for my teams. When I was first asked to speak at DrupalCon, I wasn't yet working at time. And I was finishing up a sabbatical. And the reason I took that sabbatical is that when I was running my engineering teams at AOL, I realized that I have enough time left in my career that it's worth taking some time out and trying to solve the pipeline problem. Trying to solve the sheer number of people that I had access to from a hiring perspective. And I took my year off, and I focused on Girl Develop It in station 82. And with Girl Develop It, I tried to increase the number of adults, but particularly women, that I could hire in engineering roles. And with station 82, I tried to find a way to solve the pipeline problem of getting rural teenagers interested in technology and getting them to go into technology projects and programs when they got to college. So a lot of what I'm talking about today is based on that timeout that I took. Now that I'm back in commercial space, I'm hoping to reap some of the benefits of what I've learned. Yesterday, when we were singing looking trees, he asked a question, which was, what do we do now that Drupal's becoming increasingly large, competitive with big projects, big commercial projects, big commercial partners? And the first thing I thought was, you engage in asymmetrical warfare.  And so when you're looking at somebody else trying to solve a similar problem, how do you compete against these large, well-funded incumbents who mostly look like one another when you are an open source project and you look very, very different? You find ways to make those differences work to your advantage. And this has some classic examples throughout history. So one of the ones that is very popular to point to is the Revolutionary War, where you had all these British redcoats who were just like one another and had successfully won war after war after war by marching into battle in these perfect lines. And then you had these American insurgents who were not at all like those British armies. They weren't well-funded. They didn't have good uniforms. Most of them, frankly, didn't even wanna be there, but they had to win. And they ran out in the woods. They developed a completely different way of engaging a warfare based on the characteristics they had as a community. And they just started picking off those redcoats in the woods, and they won. And that's sort of the classic example of how you compete when you're up against a well-funded, well-organized incumbent and you're the insurgent player. So there are a lot of models for productive systems, but one of the ones that I like to look at is Forrest. I like to look at a lot of the ones that arise in evolutionary biology and you can look across the sciences, but today I'm going to be looking at Forrest. And Forrest is a model for productive systems. Seashores are another good one. Tide pools. Anything where there's a lot of diversity and a lot of change tends to be a relatively healthy system. Interesting things come out of these systems. Raves. Lot of diversity. Interesting things come out of Raves. Really interesting system. Lot of diversity. A lot of interesting stuff comes out of Drupal. And in fact, one of the reasons that I'm betting on Drupal over the long term is the sheer amount of diversity in the community and the ease with which the Drupal community relatively manages those distinct voices within its community. Examples of systems that are not particularly productive. Deserts. Places where we've been hit by drought. Business class and your average aircraft. I love this picture. Every time I see it, it makes me laugh.  Because it's invisible to a lot of people.  Another open source conference not to be identified which doesn't display the characteristics of diverse representation that's found in the Drupal community. Blackberry. Classic example of a place that did not main to a healthy constituency in its community and a suffering of death as a result. An open source project is as healthy and vibrant as its community. When I'm looking to build healthy open source projects and I'm now having been running Outer Curve invested in 20 some odd of these projects, one of the things that I look for is how do we increase the viability of that community? How do we make it easy for people to make contributions? How do we make the documentation relatively easily available? How do we make people comfortable joining? So it's sort of all the hallmarks. And I think most people in this room have at the very least the gut level if not a data-driven understanding of what it takes to build a healthy open source community. And so how do you attract more participants to your community? So we know from looking at things going back to our forest example that within forestry it's increasingly understood that within forestry if all of your trees are exactly the same, you're not going to be particularly productive over the very long cycles in which foresters work. You want something that looks a lot more diverse than what they initially thought they were going for when they were planting these forests.  You have to actively engage and making sure that you've got a diverse representation of species within your ecosystem. You're planting, you're growing. And you're doing this not because you love trees. So this is not a tree hugger left-wing-y type thing. When I think about diversity, it's not because I'm particularly huggy because I'm not. When I think about diversity, I think about it from the perspective of somebody who's competing day in and day out with other big companies, other incumbents who also have large, well-funded engineering teams and I'm looking for a competitive advantage in the marketplace and that's exactly what foresters are doing. So to speak, I know I might have pushed this too far. So we're gonna move off the forestry example here. There are some very good other indicators that other people who are operating in the same competitive space I am are looking at diversity from the same perspective that I am. You've got Warren Buffett who's pointing out that as an American economy, we cannot be competitive worldwide unless we address the issue of the overall percentage of diversity within our large-scale commercial projects particularly technology. And in this case, he's specifically speaking to diversity as represented by the number of women in the community. Bezos, famously against social cohesion. At Amazon, this can show itself up as a particularly rankerous place to work with high attrition rates but they build great stuff. And if what you want to do is build great stuff, it turns out what you want to do to do that is build a community of people who are building your stuff, who are willing to articulate different points of view, argue vociferously about their point of view and then when you come to a conclusion, act in concert with the path you all decided to take. It's been very effective for Amazon. And Google, so this is some data that Google released this week and I found the response to be fascinating because when I saw these numbers, the first thing I thought was, wow, that's really good. That was not the popular reaction to their releasing this data. To me, that showed a lack of familiarity with what the day-to-day environment looks like for your average engineering team. And I think it's amazing that they publish this data. I think it's amazing that they've taken a public stance in wanting to shift this and as somebody who's competing against them for talent, I think it's brilliant because what they've just publicly done is said, we welcome diversity and that's going to give them an edge and recruiting against me unless I make it clear that our teams at time also welcome diversity. Now, why is this? Why does Buffett believe that? Why does Bezos believe that? Why do I believe that? That's because there's hard data that suggests that diversity in a team leads to better performance. Here's a couple pieces of data. And by the way, at the end of my deck, I've included all of my sources for anybody who wants to pull this data up and look at it. Companies that have more diversity perform better in almost every measure. Stock market performance, commercial performance. Firms that receive the Department of Labor award for implementing voluntary affirmative action programs had a stock price jump within 10 days. Women on boards are a consistent indicator of high performance of a company overall. And this is due to a phenomenon that has a lot of data behind it and it's well understood, which is that the collective accuracy of a group is equal to the average accuracy of any given member plus the overall level of diversity. So yesterday, when we were talking about how the Drupal community is growing, why it's growing and what has to be done to keep this a healthy growing community. One of the things I immediately thought was we have to protect the level of diversity that's in the community today. If we're able to do that, we have today as a Drupal community a competitive advantage relative to most of the big commercial engineering teams. And this is an advantage that as a community we want to protect, to continue to be competitive in the marketplace. Let's talk a little bit about the performance of diverse teams versus homogenous teams. If you've got, we can probably all read these bullet points. If you've got diverse points of view among people of similar skill composition, the diverse points of view are going to win. If the agents across the two groups have equal ability, functionally diverse groups outperform homogenously functional groups, does that make sense for folks? Functionally diverse groups outperform the best individual agents, which sort of blows out of the water, the one smart Maverick theory that's popular within software engineering. And last, a functionally diverse group whose members have less ability, outperform a group of people with high ability who are homogenous, also something for this community to be thinking about. There are problems associated with this diversity, however. As an initial pool of problem solvers becomes larger, the functional diversity of the group of the best performing individuals goes down. That's something the Drupal community is going to be grappling with. You're getting a larger pool of people, you can get more productivity, but the number of pure individual stars is going to be proportionally lower. However, that gain in individual abilities is more than offset by the functional diversity of the group growing larger in and of itself. So as a community, we are going to gain with this functional and social diversity. But the thing that's really tricky, and this is where most communities break down, is that diversity across the team makes it harder for people to communicate, and makes it harder for people to collaborate, and it makes it harder for people to work together. If you want to be successful, you have to find ways to actively make those things occur. You have to make it easy for people to communicate, you have to make it easy for people to cooperate, and you have to make it easy for people to work together. This is a guy named Ronald Coase. He's one of my favorite economists. Everybody should have a favorite economist, really. So what I love about him is he did a lot of groundbreaking work, won a lot of prizes, about the rise of corporations, and why corporations are economically advantaged, relative to a similar group of non-affiliated people with similar skill sets. And what he found is that the transaction costs associated with contributing and bringing a product to market were lower if you were part of a company than if a bunch of people randomly got together and tried to get a product into the marketplace. Up until that point, traditional theory suggested that an efficient market and assembly of people with varying skills should be able to, because they're competing on a per-person basis, at cost, be able to more cheaply bring something to market. And his theory of why companies grew is particularly interesting when you think about software and software teams. Because up until very recently, within, say, the last 10 years, hands down if you wanted to build something really big, an operating system, for example, and bring it to market, you were going to join a company to do that. The rise of open source, again, as an engineering practice, corresponded with an increase in communication channels, email, social media, now GitHub, that themselves lowered the transaction costs of people collaborating to bring things to market. Open source becomes a very attractive economic vehicle for delivering stuff. So then the question is, if production can be carried out without any organization, under what conditions would you want to invest in a corporation? So there's still some latent competition taking place. And one of the arguments I would make today is that one of the areas in which corporations have a competitive advantage relative to a lot of open source communities is they have the desire and the wherewithal to coordinate that communication across as employees. And so, going back to what we just talked about a little bit ago with the data, if those corporations are able to develop diverse groups of employees within those corporations and also lower the cost of communicating, it is likely that they're going to be able to outflank another community that is as diverse and not as adapted, facilitating communication amongst its members. And that's where you start to get really interesting analysis of free and open source versus commercial development. What we really want to do within an open source community to be competitive is have that diversity, have more diversity than the companies we're competing against and have better communication practices established for those communities. So, I'm about to use the presence of women in engineering as a proxy for diversity overall. And I realize I can get all sorts of trolling about this, so I'm acknowledging up front that I'm simply using the index of women as a proxy. This shows us the percentage of women in the general population and the workforce, those who subscribe to open source mailing lists all the way down to the percentage they make contributions. And I want to look for this data because many, many people reference the fact that 2.5% of contributions in open source come from women and I wanted to make sure that there was a sound basis for this data and there is, or anybody else is looking for it, it's at the end of my deck. So, let's think about women in engineering overall. Let's start here. So, I had this in little other life forms here before Dries yesterday with the alien in his deck, but then I was confident leaving it in and up till then I'd had it as a placeholder for myself. So, let's assume that we've got half men, half women, more women graduate from college right now than men do, but there's far more men graduating from STEM, particularly computer science programs and women, and a much larger percentage of those participants go on to professional development roles and I think we're all familiar with this data. So, I'm gonna go ahead and hold this for a second and move on. One of the things I next want us to all be grounded in is the percentage of STEM degrees relative to overall population. And you can see that while white men are represented in large percentages within software engineering, relative to their place in the population, it's not that unexpected. The number of black people and Hispanic people is way out of whack and this is something that we should look to shift if we're trying to encourage diversity. Let's next look at female attrition across science, engineering and technology. One of the reasons I like this slide is it shows that there's a couple of clear inflection points where we lose a lot of women out of engineering. Right out of undergraduate programs, a lot of them decide they don't wanna be professional engineers. Later on in their mid 30s to early 40s, a lot more women drop out, a lot again drop out, 45 to 60, that's probably retirement.  So if you look here at the prime motivators for why people go into engineering between men and women, you'll see that they want to contribute to society, they like making a lot of money, they like receiving recognition for the work they do, men slightly want a more powerful position. Clearly I'm an outlier there. And then next looked at young talent performance reviews. So this is performance reviews of people a couple of years, I believe this is two years out of their undergraduate programs. And you'll see that in engineering and technology, women's performance reviews are actually better than men's. So women are not leaving computer science and engineering because they're not performing once they get in there and get those jobs. Let's talk about what the factors are for female attrition. Hostility, isolation, broken ladder, the dive and catch. 63% of technical women experience harassment and bullying. I think we're all familiar with these numbers. I think most of us have probably had an opportunity to observe this for better or for worse. Isolation, women are lonely. When you're one of seven women on a 100 person team, it's really hard to find somebody to just hang out and chat with. And I was on this great team with all guys and me and I remember keeping track twice of the number of days I would go without seeing another woman in a meeting. And two times in a row, I mean any women, engineers, program managers, product managers, EA, any women, twice, I went 22 days in a row. I'm superstitious, I don't like even numbers, I don't like palindromes, that really stuck with me. And at the end of my second 22 days, I remember talking to my friend, Sundeep, who was on my team about this. He's like, yeah, we're getting coffee. He said, if you weren't on my team, I'd easily go six months without seeing a woman. Like no way. And then I started thinking about it and I realized if I wasn't on his team, that probably would be true. It can be really lonely. You have to make an active effort to go out and make friends. Let's talk about the broken ladder problem. The broken ladder problem suggests that because there are fewer women in engineering management, it's harder for women to find their footing on a corporate ladder and so the rate of attrition they experience at 35 to 40% is higher at that point for women than for men.  It's not 20%, it's not half, it's 10%. If your management ranks are comprised of 10% women, you're going to see a significant shift in the behavior of the other women associated with this organization. You'll see that women are 22 times more likely once it hits 10% to stay. So if you're looking to increase the overall diversity of your engineering team and the form of women on your engineering team, this is a number you can probably influence. And last, the last factor in female attrition is called the diving catch. So particularly within engineering, promotions are often given to people who have stepped into a difficult emergency situation and made that diving catch to save it. They've flown on a plane to go to another country. They've shown up for work at two o'clock in the morning. They've taken on a high-risk project and they've found a way to make it to the next time you could fail and they delivered it to safety. For women, taking the risk of a diving catch is riskier than for men for two reasons. One, if they fail, we've already talked about the social factor. They don't have the social network to help them rebound from that failure. And two, because there are so few mentors for those women, when they're successful, or a guy has a mentor who will trumpet that diving catch, come review cycle, for example, women often don't. I will acknowledge that I had this. I've managed my career on a couple of diving catches and each time I've had a mentor, there were men who were very clear about the impact of my efforts in those high-risk situations. Those are critical factors that allowed me to grow my career as an exec. So let's look now at proportion of men and women in engineering overall. So give or take, coming out of college, approximately 41% of the people who are available, who have the technical skills to fill the open software development roles are women. And I think we're all very familiar with the concept that your highest performing engineers are going to outperform your medium performing engineers. It's about 10x. So the way that really translates is 20% of the people on your engineering teams are going to be responsible for 50% of your results. You really wanna make sure those 20% are effective. So it's 14 bugs left, right? I think there's 14 bugs left in your blade. You wanna get those solved, go find your 20%ers and make sure they're throwing themselves against those problems, right? So I look it out of my engineering teams. So let's assume at this point that engineering talent, the best engineering talent, is evenly distributed by gender. Given what we looked at before with women's performance reviews, it's probably a safe bet at this stage. We have something that looks like this. Now let's say that a large proportion of your women talent walks out the door somewhere between the ages of 35 and 40. And suddenly, you're looking like this. You've just lost 16% of your high-performing talent. If you're in a competitive situation, that is painful. But what's more painful for me is that it's not just women who are leaving engineering, men leave engineering too. And what a lot of people don't talk about is men leave software engineering almost at the rates that women do. And it's not just that I'm losing those 16% of high performers because I've got women walking out the door. I have people walking out the door. And this is true across software. And again, I've got the data in the back of my deck for this. This is something we don't often talk about. People quit software development. 55% of your high-performing developers are walking out of the industry before they're 45. It's not just women. This is not necessarily, at this point, a diversity problem. While you might want more women, more people, frankly, on your teams to increase their overall intellectual capacity and productivity, what we really need to solve for is keeping more of these people in the pool overall. One of the things that's interesting about this data is that of the men who leave the industry, or leave software engineering rather, sorry about that, 48% of them leave because they found something else in which they can make more money. Maybe they're going into consulting. Maybe they're doing, who knows what? 48% of them leave because they can make more money doing something else, of the ones who leave. Women tend to leave for other reasons. And as a result, the proportion of women who have left engineering and want to come back significantly higher, 78%. That suggests that there's an opportunity here to recoup talent that has walked out the door if we find ways to make it easier for these contributors to on-ramp back in the communities. And that gives us an opportunity to not only bring back talent overall, but to recoup some of that high-performing talent that we saw walk out the door in one of our earlier slides. Now, if this is what your community looks like, it's going to be tougher. And within open source, the largest, the average contributor to open source projects is a 27-year-old male. This is about to become germane, everybody in the room. When I looked at why women are leaving open source projects, or why that contribution factor is 2.5%, I was struck by something really interesting. There's not a lot of good study done on it. One of the most thorough is this one right here. And what this talks about is the fact that while women begin to lurk at the same rates of men, and while women begin to make additional queries in the community at the same rates as men, women are more likely to erode from participation. And one of the factors is not that those women themselves receive more vitriol or less warm welcome because statistically, they don't. Statistically, they receive the same amount of vitriol as any newbie joining a community. But that seems to have a greater impact on them. Not the vitriol that they themselves receive, but the dynamics they observe in the community itself. And this is what I find to be fascinating about Drupal as a community, is that this is a community like Python that has systematically made an effort to make sure that all participants are welcome in these communities, that all participants find their footing, and that in and of itself seems to be a factor in increasing the overall diversity of the Drupal and Python communities.  It's a really safe place to start. Women can be ferociously competitive. They're certainly interested in achieving the satisfaction contributing to projects. It's a good place to start. But if you want to be competitive overall, it's not just about bringing on more women. It's about finding ways to increase the intellectual and social diversity of all the people within your community, and also finding a way to help them communicate more effectively amongst each other than the incumbent players you're competing against. If you've got those two pieces, you've got the diversity, and you've got the communication skills, you're going to build a better, more sustainable, more competitive community. Let's talk a little bit about Boston Python. This comes out of a deck I saw. Jessica McKellar and Angie Byron deliver last fall at All Things Open. And Jessica McKellar went ahead and she was trying to address the problem of diversity within the Boston Python community. She made some changes. She made the documentation better. She helped drive a warmer engagement and less aggression in the community overall. And what she saw is that very rapidly, that community not only increased its overall percentage of women, they increased it to 15%, but the size of the community itself grew enormously, grew to 1,700 participants. It's now 3,000 participants, which is very, very big for a local user group, and it remains 15% women. Does anybody know who this guy is? This guy named Bob Sutton. He used to be a professor at Harvard. He's now a professor at Stanford.  And what he discovered is that even a high performing jerk, not worth it. Because they rode the ability of that team to communicate, they rode the overall productivity on that team.  He wrote this great article, Nasty People.  And it turns out, based on a branch of game theory around altruism, that there's a formula for determining the optimal amount of cooperation, nice behavior, and jerky behavior that you want in your community. You want a little bit of jerky behavior in your community. And here's why. Because a community that is always nice and only nice invites other more aggressive communities to move in and disrupt its productivity. If, on the other hand, you've got a community where everybody's a jerk all the time, there's not enough cooperation taking place within that community to allow that community to be productive. And the sweet spot is one nice gesture. So one third of mean gestures to every nice gesture. That is the optimal ratio. And I've included links to the papers here. If you guys want to see it. And when I was first being trained to manage large engineering teams, I was taught that there were things that I did, characteristics that I showed as an individual that made it really difficult for me to manage big engineering teams. Sarcasm, that's one. I love sarcasm. Turns out that if you're sarcastic all the time at scale, you can really erode morale and productivity on an engineering team.  And if I do that, but I'm mostly nice, but occasionally I'm like, seriously?  It keeps the bad behavior in check. Somebody on my team does something just bling, I'm like, really? And that keeps behavior in check. So it's important to not be nice all the time. You have to figure out what that ratio is to keep the healthy community here. Bob Sutton wrote a book about this. I never swear this way, certainly don't throw on stage, so I'm not gonna repeat the title. You guys can all look for it. It's a great book. And it talks about the dynamics of building healthy communities and why a workplace or a team can't sustain jerks. But basically here's what he talks about. Like here's a list of things that list of behaviors you want to avoid happening across your team because it's just going to erode the productivity of your team. Insults, violation of personal space, unsolicited touching, threats, sarcasm, flames, humiliation, shaming, interruption. I do that one too. Backbiting, glaring, snubbing. And what I find to be fascinating about this list is he developed this list based on his study of corporate environments, which are significantly male. This was never a gendered list. The fact that this lines up really nicely against what a lot of women asked for on a code of conduct is really interesting to me. Let's go back to the notion of women on a team as a proxy for the overall health of the diversity on a team. If you want to ensure the overall productivity of your team, these are behaviors you're going to adopt regardless of the proportion of diversity on your team. If you want to encourage more contributions within an open source community, be thoughtful about the ratio at which you deploy these behaviors. Be thoughtful about the ratio at which you deploy sarcasm or at which you deploy interrupting. Find a way to make it productive. Rare, it has to happen happen a little bit, but make sure it's productive. At the end of the day, basically what Bob Simon is saying is the most competitive team is the one with the highest variation of the skills of diversity and the smallest number of jerks. It's not quite what this looks like, but it is what this looks like. I took this yesterday walking down the hallway. This is just sort of a random crowd shot here at DrupalCon. This community looks a lot like that ideal representation of diversity and that effective set of communication skills that is being actively practiced with an eye toward managing the most effective level of contributions from the highest possible level of contributors. It's Drupal. Now let's go back to this slide, which is similar to the one that I showed before, but this slide represents the proportion of attendees at DrupalCon this year who are women. That is astonishingly high. It's yellow by the way, in case you weren't able to figure that out. That's astonishingly high for an open source community. And if we're just looking at that as a proxy indicator for how well this particular community is doing at encouraging diverse points of view and variation in its contributors, this is a really good indicator. This is something that we should preserve and protect. This frankly is something that a lot of large, competitive software companies would like to be achieving on their teams. This is an asset that this community has built, that this community can leverage to be competitive. At time, we're moving all of our CMSs to one CMS and we're moving to Drupal. This is not something that a few years ago I would have predicted that I would be willing to do. It's a combination of things. I'm a fan of Drupal 8. I'm a big fan of the fact that the Drupal community is growing and that means it's going to be easier for me to find talent to work on the projects and the products that I need to bring into the marketplace. Most importantly, I need to make sure that I have diversity of thought in the teams that are building my products, the ones that are directly on my teams at time and the ones in the communities on which I have a deep and long-term commitment and a deep, long-term dependency. And that's Drupal. More than any other CMS, more than any other option that I can look at. So thank you very much for your time. Here's a list of the data sources behind what I talked to you today. If I've missed something and you would like to find out about my data, go ahead and hit me up on LinkedIn. It's E-R-Y-N-N. I'm pretty easy to find.  I am hosting dinner tonight at Frank. You guys haven't been to Frank, go, but not at six o'clock, or you're gonna make it longer for my order to come in. But the first 30 people who think that they might want to work for one of our teams, we're in Seattle, New York, Birmingham, London. Come on up to the stage afterward. We'll put you on the list and we'll take you to dinner. Me, some of my time compatriots here. I'd really like to hire into my engineering teams the sort of diversity that I see in the Drupal community. Not, again, because I'm particularly nice, except when I'm actively have to be, because of that ratio. But because I'm competitive and I want to build the best stuff for my audience. Thank you very much. Thank you very much. Thank you. Have a seat.  I hear aggressive behavior. Is that the same or is it different? I think it's different. So, I think of myself as being quiet and introverted. People who know me socially cannot believe that I get up on stage and talk to people. Natively, I'm an introvert.   I can be sarcastic a lot of the time. I can interrupt.  It's not just about being aggressive. See, I look at it as, when you were talking about it, I was thinking, I have friends that I want to be on their side in a bar fight. Right, right, right. And that's kind of what I was making the analogy with where you need people on your team who are not only gonna be aggressive within the team, but stand up and fight for the team as well. Is that kind of what you're going after there? No, but it's funny you would ask that because I've done a couple of startups. And one of the things, this is sort of an ongoing joke amongst our friends, is you say, you want to work with people who have been in bar fights. I have been in bar fights. It's not something that I want my children to necessarily do. But it's a really interesting indicator, right? Of the degree to which I'm willing to engage.  All right, so now this ratio. Okay. So you said for three nice, I don't know what the word is, I'm gonna use gestures. Yeah, we can use three nice gestures. There's one, the right ratio is one jerk gesture. That's about right. Okay, so I know a lot of people in the community. And I can go days or weeks without seeing one of those jerk gestures. Is that a sign that we're not healthy? Or am I just not paying attention to the right people? That's a long list. The insulting, the bullying, the lack of respect to physical boundaries. I would argue that those are behaviors that probably carry a heavier overall weight. So one of the classic ways that a lot of people talk about it is when they talk about the fact that women don't like to be touched unless you say it's okay to be touched. But what they often don't talk about is that men do that too.  It's so annoying.  It's annoying if you're a woman and it's just a complete lack of respect of personal space. And so I would say there's a long list of behaviors there. And some of them couldn't be deployed in a lightweight, effective way. Sarcasm is one of my very favorites. So I think there are ways to mediate that.   So let me just go one more step on it. Okay. Does the medium matter? Meaning a lot of times we spend a lot of our times on IRC and in forums where it's written and it's permanent. Is the ratio different if it's face to face versus online? That's a great question. I've never seen data on that. My gut sense tells me. I'm gonna say, yeah, yeah, yeah, yeah. You're married, right? I'm married. I've been married more than once. I could probably speak to this. If it's there, it's documented and you can go back and see it over and over again. It's an opportunity to continually inflate the situation. Right. I think that's where I'm seeing. When I saw that three to one or four to one ratio that's where I kind of went. I don't see that but I think it might be the medium that is delivered in. It could very well be. And there was a great piece on NPR, I'm gonna say it was three, four years ago now that covered a lot of this in depth. So if you're interested, if anybody else is interested, it was a great layman's introduction to this concept, the mathematical basis for altruism. Okay. It's a great place to start.  All right, so Doug Green had a question which related to something I was thinking about as well but he asked, what is free and open source software doing wrong with respect to diversity when the introductions are generally anonymous handles and we don't know each other's genders and colors? That study that I showed that I cited participation in free and open source communities by gender was really interesting. It's very, very long, it's very dense. Of all the links I have up there, it's by far the most dense. And that was something the researchers struggled with. And they realized that there were consistent markers of gender and how people engaged in a community that led them to identify male and female participants. However, note that what I pointed out about the way that free and open source communities engage is not that women themselves are more frequently targets of aggressive behavior than men. So it's not that anybody is saying women are being more, are targeted more frequently. It's that they observe the impact differently than men do. And so what I think is going on is that those few women in the community are an early warning sign so to speak of an overall lack of health in the community at large. Canary in the coal mine. Canary in the coal mine. You know, if you look at the Drupal community, there's a lot of diversity in the Drupal community. All sorts of diversity, it's not just gender diversity, there's class diversity, there's geographic diversity, there's skill set diversity, there's a whole bunch of different points of diversity. And I think that one of the hallmarks of Drupal, and again, Python as communities is the mechanisms that they've used to deploy to make sure that communication is nice, to make sure that it is easy to contribute, to make sure that people do feel welcome. Nothing would make a person feel more welcome than Megan dancing across stage to walking on sunshine. That was awesome. Those are hallmarks of a healthy community and I think that's what we have. All right, but is it an advantage for a community like ours where much of the initial interaction and much of the ongoing interaction is through this, you know, online medium where, you know, our diversity isn't, you know, it's not, I guess, on display. Right. It's just your username and an IRC window or your username on a form. Does that give us an advantage over, you know, organizations and open source organizations probably aren't the best example where more of it's face-to-face then online?  I've engaged with a lot of different open source communities over the last few years. And one of the things that I see in other open source communities that, frankly, I've never observed within the Drupal community. I'm not saying it doesn't exist. I'm just saying I haven't seen it is either a subtle or a strident declaration of feelings as to whether or not women should even be in that community in the first place or whether this is even a conversation worth having. Those comments are often to be found in other communities. I just don't see them in this one. And I think the very absence of those dynamics within this community marks that one almost immediately to someone new to this community as a friendly one, as a warm one. All right, let me, we'll search topics a little bit. Let me find my question here. So you talked about attrition and stemming attrition. Not capital SEM, but stemming attrition. How can we, you know, from what I got from when you were talking, it seems like mentoring is a pretty big hammer that we can wield to help stem that. Are there, would you agree that that is for a community like ours the single most important thing we can do? And the data suggests that. So the two things that I observed to be the most powerful is mentoring. A woman with a mentor is 11 times more likely to stay within a community than a woman without a mentor. So finding ways to make sure that those women in a community have that mentoring is really important if that's an area of diversity you want to include. It's not just women, right? It's not just women. Okay, I know that you're slides, right, right, right, right. And that's why I'm being very thoughtful about this is that while the data suggests that that's an influence factor for women as a diverse community, I don't know about other communities in which you want to increase engagement. So I specifically can only speak to the data I've seen, which is influencing that cohort of a diverse community. And then the second thing is just women in leadership roles. That has an impact on women as a diverse community, as a diverse cohort, if you're trying to increase that retention number. Okay, so you threw a lot of data at us. Was this US specific or do these numbers hold up internationally? We're a very international organization, so. Everything that I cited in the slides I use was specifically US data except the FOSS data, the free and open source data. That set of data in and of itself is around worldwide open source programs. And that's all called out and the sources that I have. I would like to have more data about diversity in the communities overall. And that's something I'm actively looking to find. Okay. So I'm happy to have that. Just a couple more here. You talked early on in your presentation about, we have to be actively engaged in increasing diversity. Trees don't walk themselves over.  Right. So specifically for open source communities, we just touched on mentoring, but what other types of programs have you seen that would be good to take? I think we're at about 20% on women. So how can we bring that to 30, 40, 50 and beyond? 50 would be tough. You're drawing from a very specific pool. It's a great goal. I think that would be tough. Something that I think about too quite a bit. One of the most effective ways that I've seen to be able to grow the population of contributors in your community and grow a diverse population as well is to contribute to camps, which you guys are doing, and also contribute to classes and making sure that learning materials are available online. I'm on the board of Girl Develop It. And Girl Develop It, it's ironically named. And the goal is to get more people, but particularly adult women, engaged in software engineering. And we've graduated over 5,500 women from our technical classes in the last three years. That's a huge number. We're now scaled out. The end of this quarter, I think we'll be in 43 cities across the US, and I think we'll have somewhere around five cities internationally. And that's a great, cheap and effective way to roll out learning materials and increase the number of women in your community. So there's places you can pull levers like that. Organizations that exist. That contribute to camps. Yes. Financially, or? We'll hold, even just holding them. So other, yeah, yeah, just having a camp. You guys are already having a camp. Making a place accessible. Making it accessible. We're people who can come and learn and engage. Yep. Okay, very good. I think we have one more in here. Yes, okay, so this is from a Vidic Star on Twitter. If a Drupal community is open and welcoming, what are the continuing barriers to entry for women and people of color? We say that the greater risk is that as you grow, that percentage falls away. So the challenge really becomes how do you maintain the ratios that you have today as you grow? The Drupal community is going to be facing all sorts of challenges over the next couple of years. The release of Drupal 8 is an inflection point that I think is not well understood even by most constituents in the space. It's not just that this is an amazing suite of software. It's that it's coming out in a period of time where the incoming players are fighting for market share. They're fighting with their platforms. They're fighting with their distribution channels. The major media companies are finally developing the technical sophistication to compete head on and question the efficacy at the way they've been partnering with those channels. They're looking at the large closed source commercial system that most of them are using and they're like, hey, Drupal looks pretty good. But that also means that within the Drupal community itself that's a significant change. That's a big change for the Drupal community to go from being the small, happy, warm, sort of lightly commercial community to one that has found significant footing at the enterprise level. And a lot of the characteristics that benefited Drupal over the last few years since inception really around warmth and openness and friendliness engaging have come from that population of contributors who feel that just being a person walking around those are the characteristics that you should show to the world. Those are the characteristics you should emulate as you become bigger and more commercially attractive making sure that you're fighting to keep those characteristics in place and keeping that constituent, diverse voice alive is going to be really important. I mean, is this something that we should be actively marketing? Like, we're more diverse than other... I mean, how far does this... How far do we take this? I mean, it's one thing to be diverse and to be proud of it and to grow this healthy, diverse community, but should we be leveraging it? That's a really good question. So talking about diversity is a double-edged sword. I can talk about diversity because I talk about it from a very practical point of view. But it's difficult to even say the word diversity without people having a variety of emotional reactions to the term. And that's something that's really hard to handle in branding. All right. I'm not entirely sure. I'm not sure that I would play that as a starting point for establishing yourself as a commercially viable option, but I'm absolutely sure that I would play it as a card for continuing to recruit contributors of diverse intellectual backgrounds and social backgrounds. So I'm incoming rather than... Incoming rather than outgoing. Yeah. All right. Very good. Well, we are out of time.


Hello everyone and welcome to the end user lounge where we explore how cloud native technologies are adopted by end user organizations across different industries and sectors. Just as a reminder, the CNCF end user community is formed of more than 145 organizations that use open source tooling to build their services, but they don't sell it. So the vendor neutrality is quite an important characteristic for our community. My name is Katie Gamanji and currently I am the ecosystem advocate at CNCF and I am leading and representing the end user community, but at the same time making sure to bridge the gap between the end user, the practitioners and the project maintainers. These live streams, as mentioned, we aim to bring end users to showcase their organizations, navigate the cloud native ecosystem and we'll try to deliver these streams to you every first Thursday of month at 9 a.m. PT. As well, just some housekeeping items. This is an official live stream from the CNCF as such a subject to the CNCF kind of conduct. So please make sure that you are respectful to all of the attendees, the guests and the hosts today. And if you have any questions, please ask them in the platform of your choice that you're currently watching us. We'll make sure to monitor them throughout the stream so you can ask them for our Twitch, YouTube, LinkedIn or Periscope, your choice of the platform. We're gonna see your questions. And I am currently extremely delighted to have Jasmine James, which is our guest today. And we're gonna talk about how can we elevate the developer experience using cloud native tooling. Before we dive into some of the starting questions, Jasmine, would you be able to introduce brief yourself and what you currently do? Absolutely. Thank you so much, Katie, for having me very excited to be a part of this great and new live stream. So hi everybody, my name is Jasmine James. Currently the developer experience lead at Twitter. Previous to Twitter, I worked for Delta Airlines working in the DevOps Center of Excellence, had a hand in implementing not only the tooling that enabled modern development, but also our cloud native journey. So very delighted to be here. I've been a part of a lot of the CNCF conferences and community as an end user and how I've learned a lot. So I'm super excited to share something today. Thank you for being with us today. I'm super excited to have you, especially that you have been prominent in the community for quite a while and now you're one of the co-chairs for KubeCon and Cloud NativeCon North America. So we're gonna dive into some of those areas and topics as well. But before we do so, would you be able to maybe introduce some of your motivation to become a developer experience lead in your past roles and your current role? And could you maybe introduce what your team's responsibilities are at the moment? Absolutely. So I kind of found myself in this role by being a quality engineer at the start of my career and a systems engineer when I transitioned to Delta. And historically, all of my roles have been supporting the software development lifecycle through writing tests, automation, providing infrastructure automation to make it easy for deploying, but never actually software development. So DevOps is where I found myself over the past few years. And by having a large interaction with developers, enabling them learning about their woes and pain points, there was always a part of me like, well, we could leverage a lot of this automation and a lot of the capabilities that are out there to make their lives easier. So during my time at Delta, we did that through a variety of capabilities automation, Kubernetes implementing the platform as a service. And I really loved kind of the ease that it provided. You didn't have to worry about so many aspects of deploying and it really changed individuals' lives. So it became a passion of mine. Recently, I found myself working, coming into Twitter and leading the developer experience pillar. The primary responsibilities of our pillar is to make sure that we're interacting with customers, internal customers being engineers and making sure that they're heard in learning their pain points throughout their development process. So I work closely with product management to make sure we're talking to customers, driving data gathering and making sure prioritization of our internal projects address the most impactful and impactful ways to our internal engineers. So that could be things like making sure that our laptops are performant. That could be things like making sure that we have documentation in place, even something as simple as making sure that they're supported while they're using these tools. So those are the core responsibilities of my pillar right now. That's actually quite insightful. Thank you for sharing your background story because I think everyone has such a different unique way to get into using cloud-native tools or being within this community. So it's kind of, for me personally, it's always interesting to dive into that. Now you've mentioned that the developer experience at Twitter at the moment is kind of a cornerstone one of the, maybe the features that your team is focusing quite heavily. Now, would you be able how this developer experience actually shapes the way you create and ship your services? Like what is actually the impact of having a separate developer experience too? Yeah, absolutely. So developer experience at my current company is not something new, but it's never been a centralized focus area. And what I mean by that, there's always feedback in the organization, right? There's always people that have, they wanna talk about the pain points, what's going well, that's not going well, but sometimes those conversations are held like within different ends of the organization and it's not centralized. So our focus is making sure that we're talking to everyone, right? And understanding the themes that are preventing a large part of the organizations from being as productive as possible. So we're taking this information, synthesizing it and then gathering data to make sure we're validating the hypothesis of what the improvements could be. So why is it a cornerstone? I think that by making sure all development community is heard and that we're validating these things, we can then drive high priority, high impact projects that really make waves within the organization and drive productivity gains. Now, this is really cool. And actually being responsive to the feedback within the organization, I think it's one of the main engines to drive the product by the culture inside as well. And I would like to maybe ask how you achieve delivering this best developer experience using cloud native tools and what motivated your transition into looking to cloud native tools and adopting them internally? Yeah, absolutely. So I have two very different stories about this because between Delta and my current company, Twitter, two very different environments. So the first part of my journey in adopting cloud native tools was at Delta, of course. And there were events that transpired that really made us think, how are we going to make our infrastructure more modern and become more agile essentially? And a large part of being more agile is making sure that you can move quickly and re-architect those services. You go from monolithic applications to microservices so that the changes are not so large and disruptive to the environment. So a large part of the impetus of cloud native at Delta was a new CIO joining the company. And he sparked the, just really the start of us start working towards adopting Kubernetes internally first within our local data center, but then also thinking about how we can flex within the public cloud as well. So making it easy for us to, if we need additional capacity, be able to quickly scale up certain components within our environment and application ecosystem so that way we could have the capacity necessary to serve that need. I think about, even COVID last year, and I'm so happy that at Delta, we made that the start of the journey before then because you see how disruptive, that super disruptive to the airline industry, but Delta was able to adapt very quickly and when it came to implementing new applications to fulfill the COVID government requirements, all those things, had we not taken the steps that we did and, you know, or have the framework in place to even re-architect real time, it probably would have not been as fast or successful of an adaptation. So that was a large part of prompting within the Delta environment at Twitter. However, you know, very different environment. I was so surprised, you know, going into such a very, like mature organization work using the best of the technologies that are out there for scale because the scale of Twitter is just so, it's very, very large. So it was very interesting to see how they were leveraging it in very specific ways, right, for very specific capabilities because a large part of the platform needs to scale quickly. So they were using the best of breed technologies to do just that. So those are the two things I think that prompted it within the different environments. That's really cool, actually. And now that you've adopted all kind of had to be experienced with using Cloud Native internally, could you maybe share some of the current challenges that you're facing or maybe something that you're looking along the way to solve as an roadmap item or anything like that? Yeah, so I think that one of the biggest challenges that we're currently facing within the current environment is just making sure we're continuously reducing that friction. And that's a large part of how my team came about because there is a lot of innovation that's happening at Twitter, right? We have to make sure that we are constantly rethinking about how either, you know, inputting new pieces within the SDLC could impact the delivery of value, the speed of delivery of value. So making sure that we're reducing that friction in many ways by having specific teams that are dedicated to those pieces. So having a team focused on deployment and improving that consistently and constantly, whereas a lot of companies have a team that is focused on the entire CI CD pipeline from source to deployment, right? We are focused on those individual pieces because once you get the depth of knowledge, you can then kind of iterate and understand how you can improve the different components. So I feel like that's the challenge, but we're continuing to address it in the individual team space. There's a huge breadth of range of stacks at Twitter. You know, people are using a lot of different things. So one of the challenges that I think exists is how do we make sure that we're abstracting a layer away so that when we do switch new stacks, new technologies and bring them into our environment, it's not so disruptive. It's still easy to continue to deliver and it's not something that slows teams down, whether it's for performance reasons, whether it's because, you know, there's a new better capability that we wanna start to leverage new features. It's make it as least disruptive as possible. Another thing, a challenge I think we have is just making sure that we continue to have customer feedback on the new things we implement. We're in both public and private infrastructure spaces within Twitter. So making sure that we're hearing customers and acting on that feedback, which is my job. So it's challenging because Twitter organization is huge and very opinionated, which is great, but making sure we're bringing all that together so that it's a holistic experience for everyone. Now, this is actually really cool because I'm actually looking forward to see what your predictions are for some of the themes when it comes to cloud nature technologies and if these actually fulfill the challenges or help you to solve the challenges that you currently have. Now, before I move forward with those questions, I'd like to remind everyone that if you have any questions for Jasmine, please put them in the chat of the platform of your choice that you're currently watching us, be it Twitch, YouTube, LinkedIn or Periscope. So looking forward to the questions from the audience as well. I have some two more questions on the developer experience. And one of them is, how would you define a good developer experience? And if you have any guidelines for someone who'd like to maybe improve the way they interact or collect feedback or action of feedback, do you have any guidelines around that or maybe some standards or resources you could share for everyone? Yeah, absolutely. So in my experience, a good developer experience has a few different sort of attributes. It's seamless. When I say seamless, I mean that it's very fluid and it's easy for changes to go through the process with little to no manual intervention. And some of the environments that I've worked in, it's not been a huge possibility just because of the infrastructure types we were dealing with or just the technology. So it's not always feasible to get to 100% automation or have a fully seamless, but to aim for that, I think is a great developer experience. And on that same token like automation, absolutely like automate everything that you can. All of the mundane activities that developers have to do over and over, like find ways to make it easy so that they can worry about those other problems that they have to solve daily from an architecture structuring perspective. So things like certificate, applying certificates within the environment. Very mundane activity, you have to do it yearly sometimes more often depending on your security requirements. So automating that and making it easier for developers to focus on the delivery of that value I think is a great place to be for developer experience. Another thing I think is important is to reduce the amount of waiting. So in most environments that I've worked in, there's always some component of waiting, whether it's a human you're waiting for for approval or maybe it's capacity constraints that don't allow you to move as quickly as you want from a build perspective. But making sure you have infrastructure or processes in place to make sure that people are not waiting very long periods of time because with that comes kind of context switching. So usually a person will go do something else and then come back and have to kind of get started and the momentum is sort of gone at that point. So minimal amount of waiting. And lastly, and this is probably a huge, one of my favorite and most important things I think you can do is make everything that you can self-service. Developers want to have capabilities that they can go do real time in the moment and get things done quickly. So they're all really related now that I say them and they kind of feed into each other. But I think that those are all great components of a good developer experience. As far as guidelines, I think that there's a lot of industry like companies that are doing great things for developer experience, dedicating teams like Twitter has done by hiring me and allowing me to build a team within our company. But making sure that you have a pulse on the organization. However you do that, just make sure you have a pulse. Some companies choose to do surveys. Some companies choose to make sure they're having customer advisory boards or even quarterly business reviews with leadership, just making sure that you're tapping into all levels of the organization and understanding what's important to them. What is making the most impact to their productivity and then working with them to solve that whether that's a dedicated team of engineers because the team that's doing work doesn't have time to explore the hypothesis, but just making sure that you're actioning on it. You can learn all you want, but if you're not actioning and prioritizing those customer feedback, it's all kind of, it's not a great place to be. So. I couldn't agree more to be honest. And thank you for sharing all of these good pointers. One thing that you've mentioned before and I would like maybe to expand on this, I've mentioned the documentation internally. Now, do you have any maybe advice as how can we create this asynchronous communication channel that is effective and efficient at the same time? Yeah. So by documentation channel, when just solutioning for features or defining new processes, what aspect? Actually both of them because I think when it comes to developer experience, like one of the thing is like, how do you consume a feature? So is it me going to a different person? Or is it me maybe having a wicked page internally and you'll provide all of the right information? So do you have anything in place now? Or again, do you have any guidelines on this one? Yeah, yeah, absolutely. And this has become very important given the distributed nature that we're all in right now. Everyone's distributed right now. But I think at Twitter especially, asynchronous communication is very important. We took the step of becoming a disparate, like globally dispersed company. So it's very high priority for us to make sure information is easy to find and also readable, right? And it actually has impact on what you're trying to do. So I think that what you can do within your organization to make this something that is helpful for your users of your features or people that are working with your tooling is making sure that as you're developing that documentation is a part of the definition of done and making sure that not only are you continuing to maintain that documentation as you iterate on the product, but also make sure that even outside of iteration on the product, go through it. Make sure that from a customer perspective, it still makes sense based on the use cases that your customers have. So use cases change all the time. People use many different tools in ways that I'm sure the creators of those tools never thought. So just always examining those different use cases and making sure you're maintaining documentation very frequently because this is a place, it's a central place and you can cause a lot of toil if it's very, it's not, there's gaps, right? You can cause a lot of toil from your end users. So just prioritizing that I think is a great thing to do within your company, yeah. I think, yeah, as you mentioned iteration is key in developing any features, but more importantly in developing and maintaining documentation as well. And we've been talking about the distributing nature, distributed nature of the teams nowadays. And I would like to ask you that currently we know that developer experience aims to improve the complete, or the overall software development life cycle. However, I'd like to ask you how it actually having a good developer experience internally, how can it impact the culture? But more importantly, can it help to build like different recruitment strategies by any chance? Absolutely, I firmly believe it, I'm probably biased, but I feel like a great developer experience can make the difference when making like an offer to a candidate, especially if you use it in sort of stages as a perspective, I'm sorry, a competitive advantage, because if you are using the latest and greatest tooling, but also have a great culture of your developers being heard, right? Those developers, their feedback being taken into account when planning future tooling decisions or even process decisions. I think it's very important for our developers to be heard. And word of mouth is so powerful within the tech community. Developers talk to other developers, right? So if someone is having a great experience and leveraging amazing tooling and are just like kicking butt on delivering features, I think that that sells itself. You want that experience, so it can kind of spread like wildfire within the community. That's really cool. Well, you've mentioned that you've developed your team internally at Twitter, so hope you get good to see the top talent within the industry as well. We're hiring, so I'll just drop that seed. We're hiring, so yeah, I will definitely be posting some new roles recently in the near future. So definitely looking for the best and brightest talent out there. That's great. Hopefully gonna get a lot of practitioners from the cloud made to applying for those as well. Now, the next one I'd like to move is of course KipCon and CloudNativeCon, North America. We just finished the KipCon and CloudNativeCon Europe, which was just two weeks ago, but now we're already looking forward to our hybrid event which is gonna happen in Los Angeles. So Jasmine has been chosen as the third co-chair for this conference, which I would like to give my biggest congratulations. I think this is absolutely amazing. And I would like to ask what are you looking most forward to doing this role, being a co-chair for KipCon? What are your feelings about this one? I was just super humbled in a felt so privileged like to even be thought of because being a part of this community, that was a win for me. Like learning from peer companies, learning from peers of different companies, like that was the win for me. But now to be able to work with the other like veteran co-chairs like Steven and Constance and learn more about the process of how this experience is shaped and how we're like fostering and nurturing the community. It's a real, real privilege. So I'm really looking forward to going from a participant and taking the gyms that are dropped and within the CFP process, right? Going through and seeing the themes there, double clicking on a lot of them to understand like a perspective of abstracts and understanding exactly how we can shape new conversations and bring about these new perspectives that a lot of presenters will bring for the conference. Outside of just having insight into the themes, I think that the community is one of the most important things in one of like near and dear to my heart as it relates to KubeCon and Count Cloud NativeCon. So being able to help people from especially nontraditional backgrounds get more involved within the Cloud Native community and understand what their perspectives are, how we can help lift them up within the community as well as connect with other end users. Like I was an end user and I was coming into this space learning a lot but highlighting other end users on their journey, companies that are doing great things and building community with them so that we can all help each other, all things that I'm looking forward to in this role. This is great actually. So currently I'm definitely looking forward to the keynotes which are going to be of course curated by the co-chairs. So I think it's going to be great. And I think the community is absolutely blessed to have someone like you as a co-chair as well. And moving towards more of the technical part of KubeCon, now that KubeCon Europe is complete, we have seen some of the underlying themes and maybe some categories of new tooling such as like Wasm or Security Edge. I think this whole is going to be there. At this stage, I know it's quite early but do you envision any new predictions or any new themes that are going to be covered during KubeCon and A or maybe some trends you've seen from your perspective as an end user and as part of the community or more involved in the community nowadays? Yeah, absolutely. So it is quite early but based on kind of what I've, the pulse like out there of what I've been hearing through the grapevine, Twitter, places like that, I think that once I go through the North America process I'll have a much better idea. But I just, I think that the new technologies, new projects like Wasm you mentioned are going to be highlighted in ways as they start to get adopted by additional end users, right? So finding new use cases and ways to apply these new technologies is what I'm most interested in learning about. And we've seen like from cloud, KubeCon EU, different ways that people are applying technologies for COVID, like utilizing Proud Native technologies to literally save the world. So it's very interesting to hear those really impactful end user stories. So I'm hoping that they start to reference some incubated projects so that way we can just learn new use cases, new ways to solve problems out there in the world using these new capabilities. Absolutely. So when you're mentioning about how can we apply cloud native technologies to real use cases, Priyanka actually had a great keynote on how can we apply this within the COVID time? So I definitely would encourage everyone to see that keynote and watch it again. I think it is done great on that one. The other thing that I wanted to focus on as well is of course, Jasmine, you are a big advocate for diversity and inclusion within the technology industry. So I'd like to kind of maybe explore your view of what do you think or where do you think the diversion inclusion stands at the moment within the cloud native ecosystem? Absolutely. So this is very important to me and I feel like at this point in life and where we are as a country in the world, diversity and inclusion is definitely a part of a lot of conversations that are happening, which is great. It's really important that there's acknowledgement of the gaps that do exist within multiple spaces, not just cloud native and tech in general. So I'm so happy that these conversations are even starting because it's been this way for a while, but now that the conversations are starting, we can start to work towards making it a better environment for everyone. So I think that we do have a long way to go, but like I mentioned, the conversation has started. I do think there are companies that are doing great things to make sure that people from underrepresented backgrounds are lifted up and enabled in ways that they weren't before, the CNCF process, like a CNCF conference process, making sure that we have allies that are working with these underrepresented folks to work on talks, making sure we have representation, but then all the talks are really great things to do. I feel like our code of conduct, the things that we do to make sure folks feel comfortable will also help make sure that we have good participation from folks from other groups too. So I think we're doing great. We have a long way to go, but it's just a continuous conversation that we have to just kind of keep top of mind. Yeah, again, I think it's one of those things that we need to keep talking and it should be at the forefront, especially now that we have more conferences and the community is growing and we have more elements which are gonna be virtual, we're gonna have hopefully some elements which are gonna be in person as well. So hopefully we're gonna be considered of all of the diversity and inclusion practices. And another question I want to ask from this point is what do you think we could do as a community to increase the engagement from these underrepresented groups? Yes, absolutely. So I think that it's important to just be there as an ally for the people that are from underrepresented groups and make sure that we're making them feel comfortable. This is a new space. It's making sure they feel comfortable contributing whether it's through the point of contributing. So even some of the projects, if a person does not have a traditional background that it may be a little daunting to kind of hop into open source contribution. So there's someone who's interested in doing that, support them in that process and use it as like a mentoring opportunity. I think that there's a lot of great leaders within the cognitive community that we have and using everything you know to lift someone else up is such a great thing to do. It's just really, really great thing to do. So I think that that's one thing we can do to really start to increase engagement and pull people in to our fantastic world that we've created, yeah. I could agree more. One thing that I want to mention here is that we have the diversity scholarships that you can apply for if you'd like to attend KubeCon. So if you're a part of these underrepresented groups you'll be able to join the conference. We're gonna give you a... Well, CNCF is gonna give you a ticket. And what I want to mention here is that that was my first experience how I got into the community. I got to go to KubeCon in Seattle. That was in 2018, sounds like eight years ago. But that was one of the... Still personally for me was one of the best KubeCons ever. It was in Seattle. I'd remember the keynote stage and of course we had at the time Kelsey Hightower giving a killer keynote. So for me, that was when I got the kind of the maximum proximity to the community. And I couldn't be delighted more. And that's why I stayed since that KubeCon I'm still part of the community now. So I would encourage everyone to do the first step. And again, we have the diversity scholarships for KubeCon and make sure to apply for them as well. And the last series of questions that I have are around the end user experience. Since we've been working for organizations such as Delta Airlines and Twitter and both of them are end user organizations which means they use cloud native tools but they don't sell it. So vendor neutrality, the true practitioners we have this firsthand experience of adopting and integrating tools. So could you please share maybe from an end user perspective what was your experience being part of this community and how do you make the best use of your maybe end user stages if I could say so? Yeah, it's a great status to have. And I'm so happy like we're highlighting end users because there's a lot of value in using cloud native technologies within large companies and solving problems, unique problems. So my experience started a little like different than yours Katie. So I actually got thrusted into the cloud native world by being a part of Delta in my company which isn't the case for most folks. So that's why it's so great that CNCF has scholarships to encourage other folks who don't have that opportunity to be a part of this great world. So during my time at Delta, I'm not even sure that the end user sort of term or status was a thing but there was just always great stories, always great stories of how companies were applying Kubernetes, different type of capabilities, messaging capabilities to really level up the value that they were delivering to their external customers. And at the time, we were very early in our cloud native journey and one of the main focuses that I had was we cannot reinvent the wheel, right? One, I didn't have the people to really sort of like develop all of these things internally. So we tried to do it any great thing that we tried to take as much as we can, right? And then form it up into a solution for our purpose. So my experience was just focusing on those stories and learnings and it made getting started with cloud native a lot easier because we didn't have to go through the sort of the toil and like the failures that other folks went into. Like it was a very transparent conversation. People talked about where they went wrong and how they would improve it if they could go back and do it. And we took those tidbits and formed up our own journey. Another aspect of being an end user is that, a lot of times, we do leverage vendor tools. So they were part of the conversation too, which was really great. They wanted us to be great as well. So we were supported in that aspect as too. So it was a really great experience. I'm happy to still be in the end user sort of status at Twitter, although it's from like just a different like side of things. But it's just a great community to build relationships and be able to talk transparently about your challenges sort of like a support group. But we talk about how we can get past those things. We don't just dwell on the failures. This is great. Yeah, I couldn't agree more with the end users. I think the experience is so important, but I would like them to show more of how they use these tools. So again, hopefully we're gonna see more of these stories in our future events as well. And one of the last questions I have for you is, again, how can we contribute back? So from your perspective, how as an end user organizations is the best way to contribute to the wider cloud and different scale? Absolutely. As an end user, I feel that I've taken a lot of stories, a lot of just information from the community. And it's important to give back, right? It's the reciprocal relationship. If you're using and you're learning from others within the community, share your learnings. How are you applying what they are putting out there? How is it working for you? Having those transparent conversations, you can do that by way of submitting to CFPs. The KubeCon North America one just closed, but there's ones coming soon after, so that you can tell that story. And we are really focused on highlighting end user stories because there's so much, there's jewels within all stories. Articles, I know that the CNCF supports like articles writing about the different, really just journeys and steps that companies are taking to reach the cloud native and implement it within their organization. So working with like partners from the CNCF. So you have to do that, participating in streams like this are all great ways to tell your story. Another component I think that's very important is if you're leveraging CNCF projects heavily internally, how can you operationalize giving back to that open source project? Making sure that if you are building on the open source component with internally, why not contribute that information back? It could be solving a problem for another end user out there because we heavily rely on open source to build value for our external customers. So giving back and giving another company a hand up is a really great way to get involved as well. Well, that was truly inspirational fantastic answer I would say. I would like, I would encourage everyone to take these these advices. So pretty much this are all of the questions and topics we wanted to cover today. Do you have maybe any last remarks in regards to the upcoming KubeCon or maybe would like to highlight some of the resources that you'd like to share with the wider audience? Anything? Yeah, absolutely. I would just encourage everyone to register for KubeCon North America. It's our first hopefully hybrid event fingers crossed that in LA we can all see each other. I'm just talking to Katie earlier. I'm very excited to get back to interacting with folks and sharing all of those gems that we talked about especially from the end user side of things. So the website is KubeCon North America. You can register there. Other things just be a part of the community. We're on Slack, we're in a lot of different places. So this is not just something that we're doing once a year. The community is always there and ready to share and really bring people in. From the diversity and inclusion perspective, I'm always open to help people form up CFPs for future conferences. If you're needed help, really like honing in on your topic. I'm so happy to share and make sure that everyone feels confident in submitting to tell their story on the cloud native con and KubeCon stage. So those are the things that I wanted to mention. But yeah, and just thank you, Katie for having me today. It's been a real pleasure speaking with you. Thank you for being the guest for the end user launch streams. I think it's been absolutely fantastic. Thank you very much for all of your input as well. And personally, I'm definitely looking forward to the hybrid KubeCon North America so we can actually have a coffee in the hallway. So with this, I'd like to thank all everyone who joined us for the latest episode of cloud native end user launch. It was great to have you Jasmine and especially talking about how the developer experience can be elevated to using cloud native tools. We will try to bring, as a reminder, we'll try to bring the streams every first Thursday of the month at 9AMPT. So please join us in June. We're gonna have Paratis AI as the next guest. And as mentioned, don't forget to join us for KubeCon and cloud native hybrid North America, which is gonna happen in October 12th to 15th and where we can hear the latest stories from our end user community. And another thing that I'd like to mention, we've recently redesigned our end user page, which you can see popped up here, which is cncf.io for a slash end user. And you'll be able to find all of the latest case studies around our end user organizations and all of the benefits of being part of our community. And with that, thank you Jasmine again for joining us and I hope to see you in the future streams as well. Thank you.