Sharing the Data: How Technical Women Navigate Their Career

coaching-coders-coding-7374.jpg

In May, Automattic’s engineering hiring team launched a user research study to better understand how our approach to tech hiring resonates with women and non-binary folks who may experience similar gender discrimination in the workplace and are experienced developers. We asked participants questions about how they saw their careers and next opportunities, as well as specifically asking about their reactions to our job postings. It’s easy to find advice on this topic, but the volume is overwhelming and the information is often conflicting. We wanted to cut through the vast quantity of Think Pieces On The Internet to make some changes based on actual data. Our goal, unsurprisingly, is to identify ways to increase gender representation on Automattic’s engineering teams. 

This was a fascinating process, and we are truly grateful to the 71 people who responded to our request for feedback. Given that we had this level of interest within just five days speaks to the relevance of the topic, as attracting contributors to a research project can often be far more of a challenge. While much of what we learned (discussed below) lines up with research you can find online, listening to people share their individual stories was profoundly impactful on our interviewers. It also revealed further insights that we are eager to apply. Automattic’s hiring team has been able to make some immediate changes, but have much more to think about, and expect this to influence our ongoing efforts.

Methodology

Out of our pool of 71 engineers, we conducted in-depth interviews with 14 participants, and a further 24 answered our follow up survey. The majority of our respondents had over 10 years experience working in software development, and around 60% of them had looked for a new job in the past year.  71% of our respondents were from the US, and all but one participant lived in English speaking countries. All participants self-identified as women or non-binary. The research process was very similar to that used in product user research. We described our initial rationale, invited contributions, used a consistent script, and vetted respondents to ensure the diversity of our interviewing pool. 

Results we expected?

  • Respondents have strong networks that they use for job hunting and support.
  • Respondents are most likely to leave a current role in search of growth – for example, Deutsche Bank discovered that women were leaving to take “bigger jobs” (DB’s term) , than they were offered internally, something that was addressed by adding a sponsorship program.
  • Respondents carry out extensive research on companies before applying if they do not already have a personal connection in the organization, and are highly attuned to red flags. This matches what data shows on the experience of women in tech companies – in the Elephant in the Valley survey, 66% of women report being excluded from opportunities because of gender, 60% report being sexually harassed, and 60% of those who reported it were unhappy with the course of action. Womens’ career choices are too frequently based on avoiding a bad experience rather than seeking a place where they can thrive.
  • Women in technical roles feel pushed onto the management track, and have to fight to continue to focus on technical work as individual contributors.
  • Women receive a significant amount of personal outreach, and many have come to expect it. Generic requests from recruiters are unlikely to be successful.
  • It’s important that other women are visible in the hiring process. Many women have experienced being “the only,” and at this point in their careers prefer that not to be the case.
  • Hiring processes that are collaborative and responsive – a growth opportunity rather than purely evaluative – were perceived most favorably.
  • Respondents care a lot about a respectful process. Responsiveness is a key metric, and was also a theme in interactions.

What was surprising?

  • Respondents read job descriptions almost exclusively for red flags; for instance, they search for language encouraging all relevant employees (not just women)  to take parental leave.
  • Glassdoor is not considered useful, being seen as mainly a place for negative reviews  by former employees or unsuccessful candidates.
  • Many interviewees mentioned using Stack Overflow to look for jobs. We had previously advertised on that platform and discontinued it based on the demographics of applications it drove; diversity of applicants was even lower than the already too-low industry average (as also seen in their survey). However based on these findings, we are running another test on that platform.
  • For some participants, interviewing is seen as a skill to maintain. These people are continually looking at job listings (though at a less-intensive level than a full job search), to ensure that they are aware of their options – before reaching a point where they’re desperate to leave their current position.
  • Consistently being able to have an impact (including leadership opportunities) stood out as important, and they will leave their current role if they cannot find this. This is a key point related to research showing women are evaluated more on their past performance and men more on potential. 
  • Women are looking for more communities focused on connecting to other senior women,  and around more technical topics (many communities focus on entry to mid-level folks). Concerns around online harassment can put women off trying to build their network online.
  • Respondents look to have as much information as possible up front – about the job itself, salary ranges, the team they would join, and the hiring process, and expectations in terms of responsiveness.

What changes did we make?

  • Existing work and life commitments mean that it is important to know the details of the hiring process at the outset: we have published a public page that clearly outlines our hiring process so that people have a concrete understanding of the expectations. We’ve also put together a more detailed document about what to expect during interviews, and will be creating similar materials for the other phases of our process.
  • We are revisiting our employment branding strategy to take into account the extent of research by candidates, revamping our developer blog, collecting resources on what it’s like to work as a developer at Automattic.
  • We are working on supporting our existing developers to increase their visibility externally, through encouraging them to write (our OSS culture goes beyond our willingness to share code), speak, and engage more in their communities. Many co-located companies use their office space to host community events, and it’s clear that is a smart strategy, because it builds employer brand, awareness, and personal connections between candidates and the host/prospective employer. We are looking to find a more distributed, office-less way to approach this.
  • Historically, we’ve resisted asking existing under-indexed employees for second shift work – it’s a too-common reflex- to put the work of “diversity” ahead of and at the expense of those for whom we should be doing the work of “inclusion.” This research made it clear that the highest-leverage activity for our existing under-indexed employees was chatting with potential candidates, and we are making casual chats with other women more available to potentially interested applicants. We see this as more impactful than asking women in particular to interview. While this still amounts to asking for second shift work, we are aiming to identify the highest leverage activities and ask just for participation in those, rather than putting the full work of “diversity” on the diverse, and expecting them to do everything on top of their current job.
  • We removed all the little games from our job posting page. We were trying to test people’s attention to the job posting and filter out unmotivated candidates; it turned out we were also putting people off who we want to apply.
  • We removed all the language that emphasized that hiring is a competitive process -for instance, removing language about application volume.
  • We will be testing adding “(Senior)” into all our technical job postings. Historically, we’ve been reticent to do this because it implied a job ladder that doesn’t exist at Automattic, but the research clarified that its absence sent the message that our positions are all mid-level roles without the path to growth that women candidates tend to look for. 
  • We rewrote our job postings highlighting the learning and career opportunities for the candidate, rather than focusing on our needs.

What are we considering going forward?

Some of what we learned was less concretely applicable, or requires broader changes across our engineering organization.

We’re considering how to adjust our messaging with respect to D&I, and whether some of this messaging should be tailored to developers and D&I within the engineering organization specifically. We also need to consider how this interacts with the commitment to Open Source – the data shows that women are less likely to contribute to Open Source projects, in part because of the culture of many of these projects.

The best way to retain the women we have is to ensure that they have opportunities for growth outside of affinity networks. This is something we’re mindful of as we look to improve opportunities for growth across the organization. We’re also considering the research in Women Don’t Ask, and thinking about how to offer under-indexed folk opportunity, rather than expecting them to ask for it.

Another key area to explore is the importance of titles. As an organization, we have an unorthodox approach to job titles, promotions, and leveling; employees are free to create their own job titles, and promotion and leveling are holistic processes focused on the specific employee, their skills and development goals, and current team needs, rather than on a preconceived hierarchical chart. We hire only experienced engineers who will make the whole team better – the way they choose to do that is up to them and their team lead. Bringing in titles would be a significant change to the way we operate, potentially reduce our flexibility, and if not done carefully and thoughtfully would be destined to fail. We have to consider whether we can better facilitate growth, and make the opportunities for growth and recognition clearer in our job postings and hiring process.

Some changes we’ve made relating to this recently:

  • We took a group of >20 team leads and developers to the Lead Developer event in London, and facilitated a day together. We will repeat this for US-based team leads in Austin later this year.
  • We have started offering candidates the opportunity for one-on-one calls with a member of our Developer Experience team during later stages of our hiring process; we’re starting with under-indexed folks, with a view to rolling this out to everyone. These exist outside the regular hiring process, and is premised on the idea that it both provides an  opportunity for the applicant to ask any questions they have and for us to better understand their career goals and motivation so that we can assign them to the team that’s the best fit. 

It’s early for all of this, but we’re excited about the concrete changes we were already able to make, and the initial markers of progress we are tracking. As our Creed states, “I am in a marathon, not a sprint” – we have much more to do.

This project was a team effort from @sinitivity, @tobynieboer, @rlwilliams0803, @annahollandsmith, led and coordinated by @annezazu. You can find the official announcement and a more complete whitepaper here.

Meet Justin Shreve

Justin Shreve

Justin Shreve

Meet Justin Shreve: self-taught coder, cat daddy to Harris and Skylar, Google Summer of Code grad, and all around awesome guy.

What motivated you to become a developer? What do you like best about coding?

When I was little I used to sit in on the HTML classes that my parents would teach during the summers. I found it fascinating and wanted to learn more. By the next year I was answering questions that their students raised. From there I taught myself PHP and Javascript and eventually began working with WordPress.

Teaching himself PHP, probably.

Teaching himself PHP, probably.

I was so enthralled with how the different pieces worked together. That’s what really made me want to become a developer. To figure out how things were built, and how I could take them apart, rebuild them, and improve them.

The thing I like best about coding is there’s always something to do. Coding doesn’t get boring because there’s always a feature to add or a bug to fix.

Describe the killer app you’d build, if your wildest fantasy came true.

It’s a vague idea but I’d love to do some kind of augmented reality (AR) game. Maybe an app for something like Google’s Project Glass. I’ve always been interested in games and game design. I think AR and AR games could really be brought to a whole new level with the stuff that’s being developed. It’d be amazing to be a part of that and build a “killer app/game.”

If you could share just one piece of hard-won advice with young coders, what would it be?

Don’t be afraid to break stuff. It’s how you learn. Just jump in and start coding. There are plenty of resources available to you and plenty of people willing to help you learn.

Also, seriously consider playing with open source projects. I learned a lot more once I started working with WordPress and moved away from proprietary code bases.

Meet Justin Shreve is the second in our developer interview series. We’d like you to meet Beau Lebens, too.

Meet Beau Lebens

Hello there! Welcome to a new feature of the WordPress Developer Resources Blog — interviews! In this inaugural instalment, we’d like to formally introduce you to Mr. Beau Lebens, though he insists you can call him Beau. Beau is famous for many things, including Krav Maga, and instituting burrito Fridays at Automattic headquarters in San Francisco.

How did you get into working with WordPress and how long have you been at it?

Beau Lebens

Beau Lebens

I kept an eye on WordPress just out of casual interest more than anything else (in the beginning). The first time I really used it for something serious was to make a blog for a company I was working for at the time.

That was in 2005. (I had probably been following WordPress loosely for about a year before that.) When I left that company, I started a startup with a friend which was all based on WordPress (MU, as it was called at the time) and bbPress. It was called MyBabyOurBaby.com and was basically a shared scrapbooking site for families to save memories around a child.

While building that, I worked for about eight months, day and night on nothing but WordPress. I was trying to make it do a lot of things that it wasn’t supposed to, and trying to integrate with bbPress (which was really rough at the time), so it was a pretty huge learning curve. That exposure gave me pretty solid experience with WordPress though, and I was hooked. Once MyBabyOurBaby was built, but not really taking off, I started doing a lot of WP freelance work on the side. I ended up mostly working on performance and larger-scale sites since I had a bit of background in server management in addition to WP. That ended me up at Mashable.com for about six months, helping them get their site stable, building out some custom statistics/reporting systems and a few other plugins.

After that I ended up at Automattic and the rest is history 🙂

What’s the most important advice you can impart to a young person who wants to get into coding and development?

Dive right in. It’s just code, so you really can’t break anything too serious. Get a copy of an open source project in your language of choice (oh hai, WordPress.org!) and you can start pulling it apart to see how it works. Never be afraid to try something, even if you think it will probably break everything — that’s what “undo” is for. And backups. And source control. 🙂

What’s the most important challenge currently facing WordPress developers?

I think WordPress provides a lot of the components required to build amazing products (themes, plugins, entire web applications), including everything needed to make them secure. This is where the challenge comes in for developers — ensuring what they build is as secure as the core software is. Almost every security vulnerability or exploit that I hear about is via a plugin or theme. It’s up to WP developers to build software that lives up to the platform that it’s running on and to help ensure that we’re all running a safe, secure system. Having a good understanding of a few core concepts around security (especially within WP) can go a LONG way.

Knowing these two documents inside out and applying the ideas to your code will put you ahead of most other WordPress developers:

For more on Beau, check out his blog, Dented Reality, and follow him on Twitter.