Sarah's Incomplete & Mostly-Wrong Guide to Working With Men

From the SheCodes Conference in Mountain View, CA, on August 9th 2013.

Description: The reality is that these days, most of us work with a whole lot of men. It runs through all of the levels of our experience, from our 5-person teams up to our 50,000-person communities. Let's look at what form "impact" takes at these different levels, and what tactics we can use to be heard in each place.

Transcript

1. Incomplete Mostly-Wrong Guide to Sarah’s & Working With Men 1 Good morning! I'm Sarah Mei and I'm here to talk to you about men. Gender is a very difficult subject to talk about. I do a lot of conference talks. Most of them are forty minutes, a few are thirty minutes. This one’s twenty minutes, which sounds like it should be easier. But this has been the most difficult talk to write from the last two years. Let me tell you a little bit about myself...
2. @sarahmei 2 This is me, on all the important places on the internet, which for my purposes is github and twitter. I'm a developer - I do a lot of Ruby and Javascript and a little bit of a lot of other things also. I am what the kids today call a "full stack" developer, which in practice means I write a backbone.js app, and the API that the backbone.js app consumes, and the data crunching code that the API draws from, and the ETLs that get the data that the data crunchers crunch....
3. http://www.flickr.com/photos/rgalgon/6457781479 3 I think you get the idea. Turtles all the way down. I've been writing code for money since 1998. I worked at several product companies, of different sizes, but for the last four years I've been doing software consulting.
4. 4 Most of that time I was at a company called Pivotal Labs. I actually just left Pivotal and I now run my own consulting shop called the Ministry of Velocity, we call it "mini fast" for short. Any George Orwell fans in the house? Only you guys get that joke.
5. 5 Anyway, software consulting is an interesting way to work. The way Pivotal does it, which is how we work at minifast, as well, is that developers who work for the client company come in and pair program with the developers who work for consulting shop. The consultant engineers and the client engineers build the project together, as an integrated piece of the client's engineering team. Typical project is three to six months...sometimes shorter. So in the last four years, I've spent anywhere from a few weeks to a few months at a time inside over a dozen different engineering organizations, and as a result, I've seen a lot of different ways that you can organize developers to write code. A lot of the conference talks I've been doing over the last year, including this one, come out of that experience of seeing so many different ways to get it right, and so many incredibly fascinating ways to get it wrong.
6. 6 Outside of my work, I've been involved in a bunch of different efforts to fix the gender gap we experience as developers. One thing that I do is I volunteer every summer at GetSET - anyone know the GetSET program? It's run by the Society of Women Engineers down here in Santa Clara/San Jose. It's a week-long sleep away summer camp for high school girls from under- represented minorities. The girls come for four years, with the same group each time, and they take classes in all different kinds of science and engineering. I teach the programming class to the incoming juniors. We build a little paint application using shoes, which is UI toolkit for Ruby. The goal of the program is to get these girls to go to college, and to major in some kind of science, engineering, technology type thing. You should check it out. They have a terrible website but it's a great program, very effective, free for the girls involved, and it can always use more financial and volunteer support. I've also been working to improve the communities that are closer to where I actually work. Getting more girls into programming is a long-term effort. In 2009, I co-founded a nonprofit called RailsBridge that works on a more short-term problem.
7. http://www.flickr.com/photos/harvesthq/5710640016 7 At RailsBridge we put on free 2-day workshops for women who want to learn Ruby and Ruby on Rails. Anyone here ever been to a RailsBridge workshop? Yaaaay! Anyone ever volunteered at a RailsBridge before? Nice!! Well, if you're at all interested in Ruby or Rails, you should check it out: railsbridge.org. If you know any Ruby or Rails, you should also check it out to volunteer, and help other women learn what you know. We do these workshops a couple of times a month in San Francisco, which is where I'm based. We've expanded to other places as well - we've done over 100 events now, on six different continents. I'm just waiting for someone to organize the Antarctic Ruby Conf so we can get continent number seven. But we've concentrated in SF, both because that's where our volunteer base is, and because that's where the most companies that use Ruby are based. They sponsor the events and make them free for the attendees. And in the last four years, in San Francisco, as we’ve done all these workshops, our Ruby meet ups have gone from 3% women to about 15-20% women. Which is pretty awesome! Now that's certainly not parity - it's not 50/50 - but most open-source communities, of which Ruby is one, hang out at about 3% women, so by that standard, we're doing ok. We're doing ok! But there's more work to do. People have asked me, once in a while...
8. http://www.flickr.com/photos/kevharb/4326680636 8 "Why do you care about this stuff? Why do you care about getting more women into the Ruby community and why do you care about getting more women into programming in general?" And I think that's a fair question. For me, the answer is two-fold, and the first part is selfish. First, I love this stuff so much. I love programming and I love building things, and I want to go to meet ups but I don't want to be the only woman there. So for me it's partially about feeling less alien on my own turf. When I go to a Ruby meet up, I don't want to feel like I am visually distinct from everyone else in the room. The second part of the answer, is that software is capable of solving some really important and difficult problems. Science tells us...
9. http://www.flickr.com/photos/frerieke/3242180386 9 ... that diverse teams are better at solving hard problems than non-diverse teams. And that is true even if the diverse team is less qualified on paper than the non-diverse team. The theory there is that having to interact with people who are not like you puts your brain into a more creative mode and leads the group to better outcomes. So with diverse teams, we as an industry could do a lot more. Because I don't need any more grocery delivery services, or any more ways to hail a cab, and I don't need anyone else mining my social graph. I want to see software tackle hunger and poverty and violence. And we can. It's a hard problem. It'll take bringing in all sorts of people to programming that aren't there right now. But my little piece of that is bringing in more women. Because that's what I know how to do. And I want us to do more. So that's why I care, big-picture. But this...
10. Incomplete Mostly-Wrong Guide to Sarah’s & Working With Men 10 is still a very hard conversation to have. And the big danger here is over-generalization. Everyone has their own experience of gender as an engineer, and it's human nature to over- generalize from our experiences, but in doing so, we unintentionally alienate people whose experience is different. So that's why I call this my "incomplete" and "mostly-wrong" guide. Because if you work in a big company, or you don't work in open source, these experiences may not feel truthy to you.
11. http://www.flickr.com/photos/formaspace/8288504772 11 To give you an example going the other direction, I heard a talk once from a woman developer at Google, and her advice on how to have more impact was two things: sit at the table when you're in a meeting, and make sure your voice is heard on important email threads. And I had to ask her what she meant by those things, because they just didn't make sense to me, and she explained that when she was in big coordination meetings, there was a table with chairs around it, and then there was a ring of chairs around the outside of the room - overflow. She was advising that you always sit at the table instead of in the overflow seating so that you are more involved. And at the companies that I work with, that makes no sense at all because we're not big enough to require that level of coordination. All the coordination we need can be done ad-hoc and in person. Same with email - small companies tend not to have an email culture, either, because you can just turn around and talk to people instead and it's much more efficient. Now there are small companies that have meeting- and email-centric cultures but that's usually because they're run by people who used to work at a big company, and they haven't figured out yet how to slim down. Which, by the way, means market opportunity. So keep in mind, I'm generalizing from a wide range of small companies working in open source software, and these tactics may or may not apply at the scale of where you're working.
12. Incomplete Mostly-Wrong Guide to Sarah’s & Working With Men 12 So that covers the "incomplete" and "mostly-wrong" part of my title. Now what about this part? I called this the guide to "working with men" because I want to talk about gender in the context of having greater impact with the work that we do. Impact comes at different levels. There is impact within your team - getting your technical and architecture ideas heard. There is impact within your company - getting engineering-related ideas heard by non- engineers. There is impact within your community - getting your ideas heard outside the company, in the communities around the frameworks and languages that you use.
13. http://www.flickr.com/photos/dullhunk/2816284089 13 Let's talk about having impact at the team and company level first. What I care about - the reason I'm here, in this industry - is to write great software that solves real problems. I want my work to have an impact. I want to be effective. I want to ship useful code, as often as possible. And at the scale of an individual team, that requires, more than anything else, cooperation and empathy. Because producing good code on a team is largely a function of your team's communication structure. I did a whole talk on this last year at RubyConf that you can find online, but the short version is that Carnegie Mellon in 2008 found that good communication was the strongest indicator of good code from a team. Good communication was a stronger indicator than developers' familiarity with the code base, or their experience with the technology. And this science matches up with my experience with these different teams. Teams that talk to each other more are more successful. Teams that isolate developers are less successful. Now success in this context means that they produce the right product. Isolated developers may generate more volume of code, but if they don't talk to other people, they're probably building the wrong thing. So if you want to write better code, and have the code you write be used and useful, focus on improving your team's communication. Now you can do that as an individual. On a team, it's interesting,....
14. Person Person Person Person Person Person Person 14 ...if you think of people as the vertices, the communication structure is the edges. And it's the structure and number of those edges that determine whether you as a group are successful, just as for example when you're looking at a network topology, it's the connections that are the interesting part, rather than the machines that they connect. So given that we work with mostly men, and given that having a bigger impact at the team level means improving communication, what I want to ask is, "How can I use my understanding of gender to write more good code and make a bigger impact in my team, in my community, and in the world?"
15. Team-Level Impact 0. Get past the archetypes 15 Step zero is to get past your archetypes. We are all individual human beings with our own experiences of our body and our presentation and our personality. There's a wide range of genders out there -
16. http://itspronouncedmetrosexual.com/2012/01/the-genderbread-person/ 16 This diagram is called the "gender bread man," and it explains all the different ways that we experience gender in ourselves and in other people, and all of the different axes along which it can vary. At the top we have gender identity: “how you, in your head, think about yourself. It’s the chemistry that composes you and how you interpret what that means.” Next: gender expression: “how you demonstrate your gender (based on traditional gender roles) through the ways you act, dress, behave, and interaction. Next: biological sex: “the objectively measurable organs, hormones, and chromosomes.” And finally: sexual orientation: “who you are physically, spiritually, and emotionally attracted to, based on their sex/gender in relation to your own.” These axes vary independently. So even among people whose gender presentation is masculine, there is a wide range of gender identities, orientation, and sexes that don't necessarily track their gender presentation. Now this is not just a crazy San Francisco thing, like...
17. http://www.flickr.com/photos/kindle/4740232543 17 ...the Bay to Breakers or the Folsom Street Fair or something. This is actually a much more scientifically accurate portrayal of gender, and it's gaining traction in lots of different corners of the world. Now from a practical standpoint, I can tell you my experience with RailsBridge and the San Francisco Ruby Meetup. Once we had more women coming to the meet ups, that visual difference sent a sign to other gender variant people that the meet up was likely to be a friendly place. So somewhat paradoxically, by bringing in more women, we also brought in more gay men. We brought in more transgender people. We enlarged and diversified the community in lots of ways we did not expect. It became livelier and more creative, and today it is the most active ruby meet up in the world. Now day-to-day, I see a decent amount of gender diversity even among the men who make up the engineering teams that I work with. But the majority of the people I work with are still masculine-presenting and male-identified. We'll call this group "men," if you will, although that shorthand feels often insufficient. I wager you work mostly with "men" too. But a more nuanced understanding of gender can give these men space to be themselves too. Lots of men will tell you that they hate having to pretend to enjoy sports. I had a friend who used to watch sports center every night, not because he cared, but because he wanted to fit in with the other men in his group. Getting past these stereotypes means you're communicating better, and having more authentic interactions. And communicating better means as a group you write better code.
18. Team-Level Impact 0. Get past the archetypes 1. Just show up 18 Step 1 is to just show up. Come to work every day as your authentic self, wherever you fall on these gender axes. Your presence alone make the group more creative and better problem-solvers.
19. Team-Level Impact 0. Get past the archetypes 1. Just show up 2. Expect change 19 Step 2 is to expect change, both in yourself and in the people around you. When I started working at Pivotal, for a while I was their only female engineer out of about 40 people. It was a very developer-centric culture, so there weren't many women at all, in any role. I had been at Pivotal about 8 months when they sent me to an offsite project, which was a bit unusual, meaning I went to the client's office a few blocks away instead of the client developers coming to our office. At this client company were women. Quite a few of them, actually, in different roles, and some of them were quite feminine in their presentation. I was at that client office every day for three months, and then I came back to the Pivotal office, where as before, there weren't really any other women. And I realized that in the three months I was at the client office, I had stopped...
20. http://www.flickr.com/photos/kusine/4569275134 20 ...wearing pants. I had started wearing more dresses, and even heels occasionally, and all of these things felt good. And I realized that over the 8 months I had been in the Pivotal office, I had slowly stopped doing all of those things. My uniform had become jeans and a geeky t-shirt and sneakers. Very similar to the men around me. Now some people love that uniform, but that wasn't naturally me. And from that day on, after I realized that, I started deliberately wearing more dresses and skirts, even though no one else around me was doing it. And then one day I came in and one of my co-workers, a man, was wearing a skirt. And he looked at me and he said, "well, you were doing it, and I like skirts, so, uh…I thought I'd wear one today." I had given him tacit permission to be different, and in doing so, increased the visual diversity of the team. From then on we actually saw a much larger range of clothes on everyone, including the men. The office felt more creative, and I don't think it was a coincidence that after that it felt easier to attract and hire women and gender-variant men into the engineering team.
21. Team-Level Impact 0. Get past the archetypes 1. Just show up 2. Expect change 3. Keep showing up 21 Step 3 is to keep showing up. Impact is a funny thing. It sounds like something that happens all at once...
22. http://www.flickr.com/photos/lunarandplanetaryinstitute/4933264110 22 Impact! But when it comes to a code base, impact looks more like small commits over time. Show up every day. Write some code. Talk about the code you write. Show it to people. Talk some more. Tell people why you did things. Seek their suggestions. Over time, socializing your code is how you have impact.
23. Team-Level Impact 0. Get past the archetypes 1. Just show up 2. Expect change 3. Keep showing up 23 So that's what it looks like at the team level. Let's talk about what this looks like at the community level.
24. Community Impact 0. Get past the archetypes 1. Just show up 2. Expect change 3. Keep showing up 24 Yeah. It turns out, it's the same damn things. Treat people as individuals instead of archetypes. Show up as your authentic self. Expect change. And always have a pull request open. Because it turns out that impact at the community level is the same accumulation of sustained effort and small changes over time. The Ruby programming language was created by this man:
25. http://www.flickr.com/photos/stmpjmpr/8145209242 25 Yukihiro Matsumoto, known as Matz, in Japan, about the same time that Java was created here. And if you read the wikipedia page for ruby, for example, you might think that it just appeared. A work of genius. Impact! But a few years ago, at a conference in Singapore, Matz and I - long story - ended up together on a walking tour of the city, and in between admiring the lovely gum-free sidewalks, and the many beautiful tall buildings, I asked him how he came up with the idea to build the Ruby programming language, all those years ago. What was the inspiration? And he said, well, in my job, I had to write C. And I didn't like C, so I started making my own improvements. I wrote macros so that I could write C code the way I thought it should be done. After making these little additions for 5 or 6 years, I had a summer where my company didn't have anything for me to do, so I decided to graduate my set of macros up to its own language. And he told me that, and I though….huh. Even Ruby, which for all the written history looks like a bolt from the blue, Matz goes into a cave and emerges with his work of genius - even that was really just the slow accumulation of improvements over time.
26. http://www.flickr.com/photos/thecreativecoast/9293533522 26 And that's how I think about rails bridge. Every time we do a workshop, thirty to fifty students show up. And of that group, I will feel successful if one of them comes back to a meet up. The key is to do it, and keep doing it, and one person here and one person there adds up over time. Changing the ratio ourselves in a slow and sustainable way is the path that leads to parity. And...
27. 27 we can do it. You're doing it right now, by just showing up, by going to work and demonstrating for the world that the term "software developer" describes a wide range of people. So when you think about impact in your own career, realize that impact is nothing more or less than the slow accumulation of directed change over time. You can start doing it today, in fact, you’ve probably already been doing it for years. And pretty soon you’ll have your own bolt from the blue. People will look at it and think wow, she’s such a genius! How did she make such...
28. http://www.flickr.com/photos/spettacolopuro/3826568927 28 ...an incredible impact in such a short period of time?? They don’t see the little changes over time. I won’t tell them if you won’t.
29. Thank you! @sarahmei sarah@minifast.co 29 Thank you very much.
30. Photo Credits Most are inline. Others: Slide 1, 10, 12, and 29: http://www.flickr.com/photos/linus_art/5080100891 Slide 2, Ruby logo: copyright Yukihiro Matsumoto. Slide 4, Pivotal Labs logo: copyright GoPivotal Inc. Slide 4, Ministry of Velocity logo: copyright Ministry of Velocity LLC. Slide 5: copyright GoPivotal Inc. Slide 6, GetSET: http://www.joyandshine.com/GetSET/sites/default/files/picture.jpg Slide 6, RailsBridge logo: copyright RailsBridge Inc. Slide 27: public domain. See http://en.wikipedia.org/wiki/File:We_Can_Do_It!.jpg 30