Not too very long ago, developers at Buffer were called “hackers.”
We had front-end hackers, back-end hackers, Android hackers, iOS hackers, traction hackers.
We started using the word “hacker”in Buffer’s early days because at the time, it felt like the most inclusive way to describe the work developers were doing. I asked our CTO Sunil to describe what the word meant to him:
“I think the original reason why we liked that word was because hackers are just people who get things to work well and fast. A ‘hacker’ doesn’t necessarily need a computer science degree or a lot of experience or need to be excellent in mind games, puzzles etc.”
Recently, as we began to grow and ramp up our hiring, Sunil noticed that Buffer was seeing a very low percentage of female candidates for developer jobs–less than 2% of candidates.
In researching this challenge, he met with Angie Chang, the Vice President of Hackbright Academy, an engineering fellowship for women, and discovered that the term “hacker” might be one reason why.
Angie said the “hacker” title might not be as inclusive as other titles and could be tough for many to identify with. She mentioned that many organizations that work with Hackbright often revisit their job listings in order to paint a clearer picture of what it’s like working there.
Angie’s take on the term was great information to have, and a few months ago, Sunil opened up a discussion with the team about a name change for the “hacker” title.
This started a great and important conversation. The more we thought about it, the more it seemed as if the “hacker” term was no longer the best representation of the engineering roles we had and wanted to have on the team.
We wanted to be as inviting in our job listings as possible. This also seemed most in line with the way we hire, prioritizing culture fit over technical skill.
We thought about some other ways to describe the development roles on our team, including options like:
- Code experimenter
Through lots of discussion, we generally agreed that engineer sounded neutral, and developer sounded the friendliest, clearest and most inclusive of all.
“Developer” is the option we ended up choosing, and the one that you’ll see today on our jobs page. (We’d love to hear how that feels to you, or if another option might be better!)
It’s interesting that while we were having this discussion about external job titles and descriptions, inside Buffer we were more or less doing away with job titles and descriptions as we became self-managed.
Internally, our titles weren’t important, but the outside world did not have much of a way of knowing that–and titles go a long way when someone is looking to apply for a role.
Although “clarity” is one of Buffer’s 10 values we strive to live every day, we definitely could have been doing a better job of paying attention to the connotation of every word in this case.
In putting together this post, I discovered that the wording for job descriptions is a challenge many organizations and candidates face. Here’s a great example from Hire More Women in Tech showing some of the seemingly small changes that can lead to a more diverse pool of candidates.
It was eye-opening for us to realize the ways we had perhaps been implicitly biased without realizing it. In fact, there’s an awesome Storify curated by Erin Kissane on creating job descriptions that don’t alienate.
It has a ton of useful information, and I’ve learned a lot from it. Here’s just a quick peek, but definitely read the whole thing if this is a topic of interest to you!
Continuing to refine the way we represent our job opportunities to the world is likely to be an ongoing challenge. We recently updated the look of our jobs page to add a bit more personality, and we made a conscious decision to randomize how team members’ photos are positioned on the page (different images show up in different spots each time you reload the page).
This felt like a way to A) acknowledge that our roles and passions are fluid in a self-managed team, and B) allow any potential candidate to have the opportunity to picture themselves in any position at Buffer.
As we begin to dig deeper into this important issue, we’ve been discovering a lot of great resources that I thought might be helpful to share here. Here are some of the articles, books and videos we’ve been watching, reading and studying lately:
- Implicit Association Tests on race and gender
- NPR podcast on the history of the gender gap in computer science/engineering
- A great article from Ann Friedman that breaks down some of the theories of the gender gap
Google’s Unconscious Bias Training:
We don’t expect applause for the small change from hacker to developer in our job descriptions.
A look at our team page shows that we have quite a ways to go in regards to both gender and overall diversity, and some of you have even been conscientious enough to share with us your thoughts on how we can improve in this area.
We hear you, and deeply thank you. There is plenty of work for us to do.
Right now, we’re working on diversity in multiple ways at Buffer. Various task forces are exploring topics including:
- Forming a strategy to measure and understand diversity in our candidate pool
- Creating a diversity dashboard with figures we can share each month
- Forging relationships with the many organizations and groups representing underrepresented populations in tech
- Crafting an official family leave policy for Buffer
I’m excited to make progress in these areas and report back to you. We’re not there yet, but we will be.
Members of the Buffer community have been amazingly kind to share their thoughts with us about diversity. If you’ve got thoughts, ideas, or even critical feedback for us, I’d love to hear all of it in the comments.
This article originally appeared in Buffer and is reprinted with permission.