Haus claims increased openness and fairness through our product. When we began building Haus the foremost issue was how we would build a great team to help us achieve these goals- which to us means a diverse one. After many casual conversations, two months in we had our first “Diversity in Hiring” meeting to create a plan for making it a reality. Below is a summary of our first steps down the path to building a diverse company.
Our then team of three came to the meeting with a strong values-based bias that diversity is important for societal reasons. But “because we want it to be” is neither a good business reason, nor is it the way we develop our product, so we structured the meeting like our product meetings. We began by defining why a diverse workforce is critical to our building the highest-functioning business. We then identified the core of our strategy to build a diverse team — be inclusive of all qualified candidates.
To include all qualified candidates we needed to define the qualifications for the roles for which we’d be hiring. Not wanting to deter a candidate from applying because of things that don’t really matter, we pinpointed the essentials and got rid of the rest. With the qualifications updated, we dove into our interview tactics to try to identify anything that might limit our pool of candidates. We realized that asking a prospective employee to join a happy hour was biased toward those who drink. Or that having those drinks at 7 p.m. was biased against parents who want to be home for dinner-time. While it’s important for us to have a social interaction with our prospective teammates we can give them options. Similarly on the assessment side- we ask engineering candidates to complete a technical evaluation, but for our business it doesn’t matter if they do it on a whiteboard, in a pairing exercise or as homework, so why not give them the choice?
When it was time to grow our team, we looked at our job descriptions and realized that in spite of the work we’d done to shake off our biases, a candidate might still carry their own about the role. So we decided to make it clear that attributes often associated with a role, fairly or unfairly, are not required. In doing so, we came up with “Non-requirements,” a list of often presumed requirements that we don’t want getting in the way of us building a great team.
Haus Non-Requirements
None of the following are required for our software engineer position:
- Identification with a particular gender, race, religion or national origin
- Having worked with anyone on the team before
- A particular age
- Sharing the same hobbies as the other members of the team
- A specific number of years having written in a language or framework
- A certain level of activity on a Github account
- A minimum reputation level on StackOverflow
- A particular Myers-Briggs type
Pulled from our engineer job description on Haus Jobs
We don’t have enough hiring data yet to measure how well these steps are working, but given that tomorrow will be our sixth meeting we know our expanding team embraces building a diverse and inclusive one.
