Words matter. Thinking about how you talk about jobs if you want more women to apply.

Every now and then I see someone who has the best of intentions but who promotes job opportunities that will send most potential female candidates running for the hills.

It’s easy to do, especially if you’re passionate about the job and your team. And especially if your company is a bit blokey. (That is, you’ve already got lots of men and not so many women).

Happily, lots of people have been doing some great work to try to help us all write about our jobs in ways that are more attractive to female candidates. This is a good thing because it means that you’ve now got the attention of 100% of the possible candidates for your job, not just the fellas. Your chances of getting a good candidate are greater.

(Also, we know that having senior women in your organisation seems to contribute to its overall success. So increasing your chances of hiring a woman could help make your business more successful. Double yay.)

The short version:

“Men apply for jobs when they meet 60% of the criteria, while women wait until they feel they meet 100% of the criteria.”

This is the main thing you need to know.  What you need to do because you know this includes:

  • only make something a requirement of the job if it is absolutely essential that that person already knows how to do that before they start. Key your list of ‘need to know/do’ requirements as short as possible.
  • don’t make it sound like you have to be the most awesome person at the job ever to be able to apply. Men tend to think that they awesome well in advance of actually being awesome, where as women tend to have to convinced that they are awesome long after they’ve actually been awesome. If you know what I mean.So, even though you and I know that you’re after a ‘shit hot, ninja, thought leading <name of role>’, we should keep that to ourselves when we’re writing our job spec and promoting our job, if we want more women to contemplate applying.

If you want to know more about how to do this well, there are some really good articles and tools you should take a look at here:

Can a few well chosen words improve inclusivity

25 Tips for Diverse Hiring

Why we removed the word ‘hacker’ from Buffer job descriptions

Hire more women in tech

Not everything is awesome

Why women don’t apply for jobs until they are 100% qualified

Job listings that don’t alienate

Gender Decoder for Job Ads  (tool)

Job lint (tool)

and Alice Bartlett has a great list over here with some of these and even more.

So, there you go. Talk about jobs well. Get more women (and promote them when they’re doing good work). Profit (and other good things).

Many thanks to everyone who wrote these things up and pointed me to them on Twitter.  You are awesome. No, really, you are.

Don’t give up.

Don’t give up.
Don’t let yourself be convinced that this is just the way it has to be.
Don’t stop asking questions.
Do ask for what you need to do the job well.
Do trust your instincts and your experience.

Pay attention to red flags.
Work with people who care.
Conduct experiments.
Don’t take yourself too seriously.
Remember that confidence and competence are not always related.
Always be learning.

Ask dumb questions.
Maintain naivety.
Be able to explain what you’re doing to a five year old.
Make sure you know why you’re doing it.

Your life is a design project.
There are many possible solutions.
Don’t just accept the default settings,
be creative, imagine alternatives.

Don’t give up.

I wrote this for the Pastry Box at the end of 2012 and accidentally stumbled on it today.  I still say most of these things to myself most weeks.

When experience matters (and when it doesn’t)

A little while ago I wrote this, which turned out to be more controversial than I intended.

I wrote it after having several encounters, in close succession, where one of these had happened:

  1. Recruiting scenarios where people assumed that previous domain experience was more important than the overall research experience, and capability, of the researcher.
  2. Working with a researcher who had domain experience on a particular topic who kept shutting down team conversations based on experience they’d had in previous projects, which the rest of the team had not been involved in.

These are both anti patterns of domain experience in user researcher and should be avoided.

Recruiting user researchers

When you’re recruiting for a user researcher, there are three things that teams should be looking for:

  1. Firstly, ensure that the user researcher has experience in the methods of user research you expect you’ll be using on the project. For example, don’t hire someone who has a decade of experience doing usability testing when you need someone who is strong in contextual research to work on the discovery phase of your project.
  2. Secondly, be confident that the user researcher cares about the quality of the service that their team ultimately delivers, will be able to hold their own in the team and will be effective in communicating research findings in a way that compels the team to act on them. This is the hardest criteria to meet. Too many user researchers have had a great time doing research and making reports, then leaving the teams to do with it what they will. You want a user researcher who wants to have ‘skin in the game’, and wants to see their research valued and used in making service design decisions and in setting priorities for the team.
  3. Finally, if the researcher has previous experience in the subject domain of the project, this can be an advantage. But only once the first two criteria have been met. These first two criteria are much more important for user researchers than subject matter domain expertise, and they’re also pretty hard to find.

When you hire a user researcher, the domain they should be most expert in is user research.

In teams, diversity is a strength

For most projects, having some subject matter expertise is essential. In most cases, that would be at best inefficient and at worst dangerous to do otherwise.

What is equally problematic, though, is a team full of people who have extensive experience working on the problem space they are just about to tackle.

Teams like this have so many shared mental models and assumptions about how things work, what things mean, where the constraints are, and how people think and work, and, despite their experience, not all of these things are right.

The CivicPatterns website calls this the Clean Room pattern and says:

If your project operates within any bureaucratic system, ensure that the person responsible for its design knows as little as possible about how the existing system works.

Most people hate dealing with bureaucracies. You have to jump through lots of seemingly pointless hoops, just for the sake of the system. But the more you’re exposed to it, the more sense it starts to make, and the harder it is to see things through a beginner’s eyes. Therefore, when building a system that helps someone bypass bureaucracy, start by designing how the system should be, with as little pre-knowledge as possible, and then, when you need to add any complexity, work as hard as you can to hide that from the user.

Lack of diversity in experience-levels (and lack of diversity in general) in the team will reduce their ability to consider a full range of service design options that can streamline the experience for users. This will limit the potential for transformation.

There are some roles where experience the domain of the project is essential and teams would be foolish not to include them. Designers and user researchers are not those roles.

Design your teams so they have diversity, in gender, in age, in backgrounds and in subject matter expertise and you’ll design better experiences for your users.

Death to ‘it depends’

Lately I find myself on a mission for mass simplification. Possibly over simplification, but I’m not sure it matters.

It’s one of the things I care most about at the moment – how can we simplify what we are asking people to do so that there is nothing else they can do but start doing it, instead of following their natural inclination to make a list, hire a consultant, write a white paper, do anything but doing the thing.

It requires that I stop saying (or even thinking) one of the things I have probably said most in my entire working life – ‘it depends’. That’s hard, but I think it’s the right thing to do.

It depends is paralysing.

It is a stop sign. It tells people they can’t do anything yet. That it is complicated.

And it presents things as  complicated at a time when the person asking the question usually doesn’t have the capability to understand they subtleties you are trying to explain.

Of course, most things are complex and it usually does depend (on context), but knowing what to do in the face of all of that is less important than just doing something now. Ideally something that gets you on the right track to having the ability to ask more nuanced questions, to have a more sophisticated understanding of the thing you’re doing and the context you’re doing it in.

What does this mean? For me, at the moment, this means trying to create a massively simplified message for teams across government about how they should start doing user research.

Lots of different teams, different projects, different audiences – a whole world of it depends.

Forget all of that. What’s something massively simple that all of them can start doing right now.

Here’s an idea.

  1. Start doing some research in every iteration (we’re all doing agile)
  2. Start by getting 5 or 6 people in a lab, give them the thing you’re making and a task and watch them use it. Talk to them about what they find difficult. Maybe also ask them about how they use the internet in real life, what kind of interaction they’ve had with government before. Don’t explain your thing.
  3. Get as many of your team as you can to observe (hence the lab). Aim for 2 hours every 6 weeks for everyone as a minimum.
  4. Capture what you hear and see on post it notes. Do affinity sorting to analyse research. Write down what you learned (your insights) and what you’re going to do about it. Do those things, come back and do the same in two weeks.

Now lets all start saying this to everyone, every chance we get.

It won’t be the best thing for every project to be doing all the time, but it is way better than doing nothing.

As soon as you start doing this, you will start to learn about different and better things that you can do (if for no other reason than because you’ll need a user researcher to do this and they can tell you. Before you start this, you probably won’t have that person).

Now we just need to do this for all the things…

Related: I watched this video from the ever grumpy but rather clever Russell Davies the other day. He’s scaring the pants of people who are studying to become Planners in the advertising industry and telling them that the best strategy is not the most creative one but the one that actually gets anyone to actually do something.

There’s an interesting section on the value (or not) of research as well.