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

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 difﬁcult
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 difﬁcult talk to write from the last two years.
Let me tell you a little bit about myself...

View Slide

@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....

View Slide

http://www.ﬂickr.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.

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

http://www.ﬂickr.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...

View Slide

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...

View Slide

http://www.ﬂickr.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 qualiﬁed 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...

View Slide

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.

View Slide

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.

View Slide

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.

View Slide

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,....

View Slide

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?"

View Slide

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 -

View Slide

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 ﬁnally: 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...

View Slide

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.

View Slide

Team-Level Impact
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.

View Slide

Team-Level Impact
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...

View Slide

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.

View Slide

Team-Level Impact
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...

View Slide

http://www.ﬂickr.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.

View Slide

Team-Level Impact
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.

View Slide

Community Impact
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:

View Slide

http://www.ﬂickr.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.

View Slide

http://www.ﬂickr.com/photos/thecreativecoast/9293533522
26
And that's how I think about rails bridge. Every time we do a workshop, thirty to ﬁfty 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...

View Slide

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...

View Slide

http://www.ﬂickr.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.

View Slide

Thank you!
@sarahmei
[email protected]
29
Thank you very much.

View Slide

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

View Slide

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

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

sarahmei

More Decks by sarahmei

Other Decks in Technology

Featured

Transcript