 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. Because if you're a member of a diversity group and you've spent your entire career being something that's different than most of the people around you, you learn how to make that difference work for you. 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. And every time I get on an airplane and I look at all those guys in the first six rows, it just completely cracks me up. Because it's invisible to a lot of people. But if you're looking for it, you see it every single time. 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. And if you're a forester you also know that simply providing the conditions, sunlight, air, water, isn't enough. 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. And it's not because they're less committed or less smart or they're not performing as well as their male peers. 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. And there's a sweet spot. 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. If you want more diversity, if you want to be more competitive, you want more women. 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. He's done a lot of groundbreaking work on the impact to your corporation, to your workplace team, of having a jerk on your team. 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. And having a jerk on your team or having otherwise nice people act like jerks lowers the overall competitiveness of your team. He wrote this great article, Nasty People. And this is where he began to quantify the impact of having nasty people jerks in your community. 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. But I can't be nice all the time because every once in a while, somebody's gonna ask something stupid and I have to say, seriously? And if I do that, but I'm mostly nice, but occasionally I'm like, seriously? It keeps the stupid behavior in check. 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. And also, last but not least, I, like every other SVP of engineering, is hiring. 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. So, you mentioned the word jerk a few times and when I heard that. 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 don't think of myself as a jerk. And it took me a while to realize that I had a couple of those behaviors that are really jerk behaviors. I can be sarcastic a lot of the time. I can interrupt. I think examining my own behavior first has really led me to be thoughtful about what signifies a jerk. 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. It's not something I advocate doing necessarily, but yeah, somebody who's been in a bar fight, somebody you want in your hip pocket. 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. So you guys have all seen the mental management suck up guy who's trying to like suck up and show his organizational prowess and I'll come up behind you and he'll like put his arm around you and tap you on the shoulder. It's so annoying. It's annoying if you're a guy and a guy doesn't you. 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. I'm not advocating for more jerk behavior in Drupal. So I'm ignoring everyone's questions because I'm fascinated with this whole jerk thing. 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, I'm gonna let go of the jerk thing for now. 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? You know, you and I had a little conversation yesterday where you talked about the fact that because you've been in this community for so long, you don't sometimes see the things that are unique to this community. 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. You just can't sit back and be nice and hope that it happens. 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.