Jamie Hannaford: Making our spaces more inclusive

So today for our final talk of the final session we have Jamie Hannaford who is a software engineer with rack space, and will be talking about making us more inclusive {applause}.

JAMIE HANNAFORD: So our industry is defined by its ability to solve technical problems. We produce software, tests, documentation, sometimes of immense complexity as a result. But, let’s not fool ourselves the most technical problem in tech is not technical it’s social. People are more difficult to work with than computers and to day I want to talk to you about diversity but also about inclusiveness.

So the first diversity I want to talk about is diversity in the workplace, the challenges we face and some of the techniques and this we can do to mitigate and overcome them. The second thing I want to talk about is open source communities and how we can make them more inclusive for everybody. Thirdly I want to talk about physical spaces, conferences and meet ups and how we can minimise exclusion there. So, I think the first question we really need to ask ourselves is what do I mean by diversity?

For me, diversity is not just about hiring more women. Gender is only one part of the picture. We should aim bigger by incorporating a wider spectrum of people that covers race, ethnicity, sexuality and religion, age, disability, class, educational background and bodily appearance. These are all truly important aspects of what it is to have a diverse team. And to answer the question of why is diversity important the simple answer is it makes your teams better. Fresh ideas and new perspectives are introduced. And we begin to think differently and make better decisions. And as a result, we produce more innovative products which drive business up for the overall company.

In fact there have actually been studies that prove this. For example, the Kelup School of Management a few years ago commissioned a study where they got 200 people and placed them into groups of 3 and they gave them a simple detective problem. They were given a set of interviews and they had to determine the likely murder suspect. Now each person was given the interviews and they basically had to come up with their own ideas but they were in groups of 3 from the same social background so the groups were fairly homogenous. After 5 minutes a fourth member joined the team. 50 per cent of the time it was from somebody from the same social background so 4 people who effectively thought the same. The other 50 per cent of the time it was a stranger an outsider which was effectively composing a diverse team. The results were startling they found because the diverse teams guessed the correct murder suspect with far greater accuracy than the homogenous group. And this wasn’t just because of the influence of new ideas and fresh perspectives, what they found was it actually triggered more careful information processing, so there is a real, real compulsion and reason there for diversity in terms of what it gives our teams.

So, we know what diversity is and we know why it’s important, so what concrete tings can we do in our workplace in our team to incorporate diversity? Well, unfortunately saying we care about diversity isn’t really enough. Action speaks louder than words and one of the ways we can actually solve this problem, take a first step, is to reform a hiring process.

The first way, the first important aspect of when we start to think about how we can reform our hiring process is to look at the way we right job postings. Now the job posting is the primary interface of your company. It is the lens that allow prospective candidates to glimpse your internal culture. So if we want to write a really good job posting that’s inclusive and will encourage diversity, what things do we need to do? Well, we need to focus on the tone, we need to ensure it is friendly, accessible and completely assumption free, we should avoid all the irrelevant clichés like rock star, hero, ninja, we’re all tired of them now and they don’t contribute any knowledge to job posting itself. If you employer actually is willing to have a commitment to diversity make it explicit, there is nothing wrong with being open about it because it encourages people to realise what type of company you have. And lastly you really need to focus on offering things that people would genuinely want. So, not everybody cares about having free red bull and coke in the fridge or a football table. Things that people might want is flexible hours or remote working, childcare assistance, accessible and wheelchair friendly facilities, mental healthcare coverage, trans inclusive healthcare coverage, generous parental leave. These are all truly important things people look for in a modern diverse company.

The second aspect of how we can reform hiring is to look at the way we interview people. Now the technical interview has traditionally been a major arena where implicit unconscious bias enters the picture because we tend to favour people from the same background who went to university, studied computer science and as a result we kind of enforce homogeneity. We don’t promote diverse thinkers because we have a very monolithic way of approaching this.

Now, when we ask people to code on a white board or prove to us that theoretical knowledge or algorhythmic integrity we really have to ask ourselves whether me want to be part of an engineering team that was primarily chosen by its ability to write code on a white board. For me it’s kind of irrelevant. That’s not really what I do on a day to day basis as a programmer, I don’t really know anyone else who does that. So outspoken confidence and having an in depth and theoretical knowledge of algorithms is not the most important skills a team needs.

Also think that we shouldn’t be afraid of trying to redress the balance a bit because when we start a conversation or a discussion about changing hiring practices it can be really difficult with your team because it actually has a tendency to reveal potential internal problems with your own culture, culture and the teams culture itself.

So, what are the things we do to make these things better to make them more inclusive? Well, let’s be conversational, let’s not be adversarial. Nobody should be set up for failure. Instead we need interviewers that are more self-reflective and less alpha male, we need more effective sensitive inclusive interviews. Also let’s give the candidate something that will accurately measure their performance on a day to day basis so for example pair them, give them a problem and run through a - let them run through how they might solve the problem, can they debug? What is their code review process like? Can they fix an elusive issue? can they optimise a performance bottleneck? How will they re-influence something if they have a chance? These are all relevant questions that will accurately measure their performance of your team not ask them to scrawl stuff on a white board and actually Google they found zero correlation between technical interview performance and job performance so it just goes to show how meaningless the white board interview truly is.

So, if we move beyond hire itself and start to think about some of the challenges that are still left in our teams, one of them is a culture of fear. What I mean by that is the fear of asking questions. The fear of thinking you’re going to look stupid if you do, fear of thinking you don’t know enough, it’s a real fear of pretty much everyone in the technical industry and the fact is our industry is evolving at an extremely fast pace, we often expect ourselves to keep up with this constant onslaught of new technologies and knowledge but there is a constant threat of being left behind and out of our depth. We all face a knowledge deficit and people who start to {inaudible} are beginners, they often get frustrated really easily because they see other developers using really could technologies and they question themselves and say why bother? What can I do? I can do nothing. But guess what, we’ve all been there, we’ve all been beginners and we’ve all had that self-doubt. But it’s OK, it’s OK to be a beginner and it’s OK to have these feelings of inadequacy. Learning to programme is difficult but so is anything that’s worthwhile.

So, apart from beginners we also have a problem of fear with seasoned developers, experienced developers. One of the very common things we’re starting to talk about in our industry is the idea of imposter syndrome which if you are not aware is the psychological phenomenon which arises from an incorrect assessment of one’s own abilities so for example if you are an 8 or a 9 out of 10 programmer you yourself only think you are a 3 so it’s an inability to really understand your own merits basically. And how does it manifest itself? If you are on a team with somebody who has imposter syndrome they often won’t share knowledge because they don’t think they have anything worthwhile to contribute, they don’t speak at conferences, they don’t submit talk proposals, they don’t write blog requests, they don’t collaborate contribute to open source and they don’t apply for jobs. But beginner’s fixer these problem is more than personal responsibility, we can’t ask people to solve it by themselves. I think it’s endemic of a wider communal problem that we all have a responsibility to help with, we should all help each other.

So, Sasha Mundy gave a great talk at Python this year about how to give and get technical help and came up with a great line where she said: if people are afraid to ask for help it prevents from them stretching, if you don’t stretch you don’t grow. If people don’t grow your team stagnates and your company doesn’t build amazing things.

I think that perfectly summarises the struggles we all face when asking questions saw for people with the little voice inside their head telling them they’re not good enough we want you to fight it, we need to have the braveness to overcome it and having that struggle of trying to overcome it too and for mentors we really should be aware of it, so if we’re on a theme and we’re mentoring people with no self-confidence or people who are constantly questioning themselves be aware of it, reward question asking and realise how brave it is and if they are giving and asking too many questions shape their behaviour, teach them how to fish instead of just giving them fish.

So to switch focus now to look at open source communities, the most relevant and pertinent question me need to ask is why don’t more people contribute to open source whether it’s Django or PHP or ruby? For me the answer is that not everybody is aware of the full range of contributing options so for example you can contribute documentation, you can write tests, you can write blog posts, you can speak about something, you can design an interface or just give feedback. These are all equally valid ways of contributing to open source but people tend to get hung up on the code slinging code they tend to think it’s the only way to contribute and it’s not.

Another vastly underrated way of contributing to the community is organising conferences and events because it often takes months of very careful hard work to set up and it’s as much of a solid contribution as writing a new feature for Django.

Another reason more people don’t contribute to open source is often people don’t have the luxury of time and opportunity. Women for example are far more likely to be a primary care giver not only for children but also to ageing or ailing relatives. On childcare alone for example they spend more than twice as much time per day as fathers do and there are other reasons, some people might have medical conditions. Some people might get paid very low cannot sacrifice any contribution to do external things, some people have long commute and when they get home are so exhausted they can’t contribute to open source. So I was reading a blog post a few months ago on modern new culture and the question asked was why don’t you contribute to open source? And Anna who wrote the book post she said, well, I tried and people were unwelcoming and even cruel.

So this is us line from Julie Pegano also at Python where she talks about imposter syndrome and she was referring to very bad habit we have in our industry of elevating certain people to God like status, we think they’re inscrutable and their code is flaw less we think they make incontrovertible technical decisions and think their status is untouchable but the direct consequence is that we doubt ourselves negate our own contributions and shy away from getting involved so her message was skill kill the heroes not necessarily that because she would violate the code of conduct but she said we need to leave the person behind and see them as a realistic person and it helps us equalise our own contributions and helps rationalise our own feelings of ourselves. Another really sort of insidious thing that happens in our industry is meritocracy the idea that power is bestowed by technical contributions but for me that’s deeply flawed because it tends to rule one type of contribution. I said about multiple different ways to contribute. Meritocracy recognises code and that’s it and another flaw is it assumes everyone is on the same level and has the same level of access to opportunity, time and money and we all know that’s not the same, people aren’t equal. So, what can we do to enable people and give them confidence in open source?

For me the biggest tip I can say is write a good contributing guide that formalises the transparent process that people need to abide by to get a patch merged; if you write it down and make it explicit there is no knowledge deficit there, people on the same level and know exactly what to do to get involved. We also need empathy and patience with issues and bug reports because if someone has taken the time to report a problem they have done that because they want to help the eco system and want to help strengthen the product itself and we should have honest intact, we should be appreciative of the fact that somebody has taken the time to write a feature.

Another thing I do with all of my projects is I deliver certain feedback really pedantic feedback through computers so if I have a very strict policy through syntax for example so in Python with indentation that kind of pedantic feedback is a lot better coming from an automated system or computer because if somebody thinks you are rejecting their contribution because they’re missing a comma, they’re probably going to walk away and say I don’t want any part of this ridiculous charade but if it comes from a computer because they’re stupid it’s OK like I will accept that feedback and change it and re-push and everything is gravy but if it comes from a person then I will probably doubt that a little bit more.

Another thing which I think is really important is to stop denigrating peoples doling interests. I am a PHP developer and every time I introduce myself as a PHP developer I can see the eyes roll back there is an implicit judgment on me and I don’t understand it I don’t understand how we can judge somebody’s choice of tool aunt language based on our own assumptions, I think it’s wrong, we need to be a lot more open. Another example is word press developers, they get a lot of flak because they have very strong opinions about the way the code is structured but the way the code is structured is completely irrelevant, they’re using that tool for a specific purpose and if it’s good for them it’s could enough for me and it should be good enough for you too.

And the final thing to really, that is essential to help improve inclusiveness is to document well. We had this idea earlier of documentation driven development and I completely agree, documentation is at the heart of all projects so we should make potential and assumption free knowledge sharing keep component of what we value nothing is ever obvious or easy and for extra bonus points you can do things like provide non English translations, you can focus on accessibility for visual impaired users, these are all really cool things you can do to make your project as inclusive as possible for as wide spectrum of people.

Lastly to focus on physical events themselves, what can we do to tackle exclusion? Now, I think it’s very important to reason Django is pretty much the shining light in our industry of how to do it right, they have a code of conduct which basically helps define and make transparent what kind of behaviour is deemed exclusionary or threatening so everybody is on the same level and can no longer plead ignorance. Codes of conduct help formalise the support system for marginalised people and allow them to contact organisers directly and also one of the things I regularly hear about the reason not to have a code of conduct is people say nobody else before has reported harassment but just because that’s happened doesn’t mean harassment doesn’t happen, it could mean somebody didn’t feel confident enough to report a bad thing.

So to wrap up, I think we should remember the 4 points I talked about today. We need to change the way that we hire, we need to remove the culture of fear, we should formalise the transparent process of contributing to open source projects and we should make an attempt supported events that value diversity.

We all have the ability to change ourselves and by association we have the ability to change the communities we all belong to. Bell hooks once said dominating culture has tried to keep us all afraid to make us choose safely instead of risk, same risk instead of diversity, moving through that fear finding out what connects it, revelling in our differences this the world that brings us closer gives us a world of shared values a meaningful community. I will leave you with that quote thank you. {applause}.

DANIELE PROCIDA: Thank you very much I think that was the perfect way to end today so thanks.

Just before we all leave the room a couple of very brief announcements.

Actually I’m so sorry, Jamie, sorry, I didn’t ask - there must be some questions for Jamie. I’m sorry I didn’t mean to - I’m sure there must be questions for Jamie come and stand here so - yes please.

NEW SPEAKER: Hi Jamie thanks so much for that great talk. I get from the sense of your talk that you are deeply into diversity because you think it is the right thing to do but I was interested in how you kind of led the beginning of your talk with the idea that - I mean I kind of promulgated it in my talk too like when you have diverse teams we make better things and so I’m wondering do you ever kind of use that line to kind of finesse diversity to some people instead of - because I come from an ethics background I believe diversity is the right thing to do. Can you talk about the way you play with that sometimes?

JAMIE HANNAFORD: So, I think that it is very important when you believe so strongly in something and you are trying to make changes to be sensitive to the fact that not everybody is going to have the same ethical framework as you. They are going to think differently because they are going to have different moral and political beliefs so I think it is important not to hammer my framework on somebody. I find the presenting facts and psychological study is kind of a neat way out because our industry loves numbers, they love stats, they love very technical things that we can’t argue with, if you give them that, how can they say no? It is a better way of trying to achieve change than just trying to talk about ethics but I think both are important.

NEW SPEAKER: Truly tremendous talk, really well done. It was really refreshing and I think it is a real testament to Daniel’s vision that we have got so much inclusivity at this meeting.

(APPLAUSE).

I am a research astronomer and we, there is a group of us who crossed over into this sort of dark world of software writing and the some of the lessons that we brought back are including things like codes of conduct in our meetings and it is really, really important to us that you guys are leading the way in this. Because we can benefit from this. The epidemic community for a long time tried to a lot of the hinges, like you said, nobody has said they have been harassed, why? All those sorts of things so, that was really what I wanted to say that it actually it is wider than just this community. It does trickle back into other areas and it is really, really important certainly to us.

JAMIE HANNAFORD: Some of the problems I talked about some doubts and voices, they are applicable in every industry, I think it is great that our tech industry can be seen like an archetype of how others can act, we all have a responsibility because we are on the front lines, we are the ones defining future generations of other industries too. We need to pitch in and make it better.

DANIELE PROCIDA: Last one.

NEW SPEAKER: Thank you for your talk, so my question is, if you have managed an open-source project, ... a guideline not just for the coding and the patches for doing research, ... and all sorts of contributions.

JAMIE HANNAFORD: Are you talking about personally? Do I – have I seen others.

FROM THE FLOOR: Have you seen?

JAMIE HANNAFORD: Not that I can recall, I can look into it. The types of projects I maintain I make it key priority when I start them to focus on unfortunately just on code contributions but now that you have raised this issue of different types of contributions I think that is something I will start thinking about with my projects too. I can be on the lookout if I see ones that are of particular interest.

DANIELE PROCIDA: Right thank you once again.

(APPLAUSE).

Okay, it is the end of our first day of our open day. So I have got a lot of thank you’d, firstly thank you all for coming especially if you weren’t part of the conference and came to visit our open day, we are really glad you are able to be our guest here today, maybe we will see you at some other events.

Thank you to our speakers and the workshop leaders today, who have, I have seen most of the talks, not seen all of them. The workshops were all really busy, so thank you for everybody who put so much effort into that too.

Our volunteers, are any of the volunteers in the audience? No, well you will have to thank them, look, yes there are, Damien has been yes, you Damien, you will have to represent the volunteers they have done a fantastic job and grateful for everything they have done.

The people who provided technical services, our speech to text reporters, people doing the filming, people looking after the AV for us and people looking after the network for us, so thank you very helping keeping today running.

Once more, thank you to Cardiff University if you can send a little thank you to Cardiff University that would be nice, they have put an awful lot into this event. Who is a sponsor here? Representing a sponsor, come on I know you are, thank you very much because you are also one of the, you also make this possible it would not be possible or not possible like this were it not for the involvement and active participation of sponsors, thanks very much to all of those. (APPLAUSE).

I hope you have enjoyed today, I hope that you will be able to come to one or the other of the meals that we have got on tonight. You do need tickets for those, tickets for the VFS are still available from the tickets page on the website. Whichever of those venues, be there by 7:15 this evening, if you are going the the VFS, they don’t serve alcohols but you are welcome to take in your own bottles. They don’t serve alcohol at the clink for entirely different reasons! see you later or tomorrow!