 Awesome, I think that's my cue and my mic is on and it's amazing. Hey everyone, in the back, I made these really awesome postcards which were inspired by my slides and they're all up on the front, like five or six rows, so if you really want them you have to come up here and sit here and get them. That's my bribe for you. Hi, I'm Colette, welcome to my talk, I just wanted to get a sense of who's in the room right now, so if you are a recruiter, can you raise your hand? Are there any recruiters in here? Amazing. Are there any managers of humans in the room? Awesome, and do we have any open-stack developers in the room? Hi guys. That's a good thing to know before I get started because my talk was sort of divided into threes for all of you. You might be wondering who I am, so hi. I'm Colette, I'm an engineering manager at IBM Cloud. The team that I'm on there is called the OpenStack Innovation Team and they mainly work on things related to CI CD solutions, some of the problems of scaling OpenStack and also just the work of integrating OpenStack into IBM Cloud's product. I'm also a rock-tellist. I play live shows and go on tours and I do recordings with bands. I was also a secret nerd in high school. I had a lot of friends who are really into computers and I had an account with them on ArborNet, which is one of the oldest re-nets around. And that's when I sort of started tinkering with systems administration. Over the last little bit, I've been working with the OpenStack community. I've actually had my job interview at the Ice House Summit in Hong Kong and I began working as a program manager with Hewlett Packard. So I've been working with all of you now for a few years and I absolutely love it. I've recently become really interested in leadership and culture in open source communities in general and I get really excited about the sort of messy people parts of the tech world. So this whole talk comes from that perspective. And if you want to find me on FreeNode, you can reach me at Gothic Mind Food. And on Twitter, I'm Colette Cello. What is this talk? Like a lot of excellent and not so excellent ideas. This talk was conceived of over some great Japanese whiskey in Tokyo at the last summit. I thought that I could share with recruiters and hiring managers some of my lessons learned while I've been hiring OpenStack developers over the last few years. After I realized that I actually had to sit down and write the talk, I broke all of my experiences down into a few distinct separate subject matters and then I scoped everything down into just one thing that could be useful for you today. So what I'm actually going to start with is what this talk is not. I'm not going to tell you how to onboard someone. That's a hugely important topic and I actually think it's something that the OpenStack community needs to focus more on and hopefully will be the reason I get to eat tapas in Barcelona in November because I will write that talk. But that's not today. And I'm also not going to tell you how to retain someone that you've hired who's working on OpenStack. I also think that's really important, but let's call it like return of the squirrels, turn of the king, part three in my like trilogy or something. So also hiring smart isn't an algorithm. So I'm not going to give you a really secret search term to put into LinkedIn and find all of the secretly amazing OpenStack developers because it turns out that hiring smart isn't about that. So now that I've dashed your hopes for everything, I'll tell you what this talk really is. It's about sourcing, interviewing and hiring great OpenStack developers. And really the question is how do we go about evaluating someone's suitability for positions that involve working within the OpenStack community. I first started doing this kind of work when I was at HP. Our group was in the process of expanding pretty dramatically and we were giving a bunch of requisitions by HR and we were told to go forth and hire. And when that happens, I don't know if any of you also work at huge companies, but I did or do still. And the first thing that happens is they're like, go talk to a recruiter. So I was really excited and I got on the phone with my recruiters and they were like, awesome, tell us who the perfect OpenStack candidate is for your role that you have opened. And I went on this really well-intentioned rant for about five minutes about who makes the perfect candidate for our team. And then there was silence on the phone. And that's when I learned about what a purple squirrel is. Wikipedia describes a purple squirrel as a term used by employment recruiters to describe a job candidate with precisely the right education, experience and qualifications that perfectly fits a job's multifaceted requirements. I think it's an understatement to say that the job of working on OpenStack successfully is one with quite a few requirements. And I'm sure most of the developers in this room would agree with me. It's very different from an entry-level engineering position at a startup making a web app where you can sort of throw out which stack someone's working on and ask some folks to apply based on that. OpenStack is a much more varied and complex environment and it's very, very unique in a lot of ways. So I looked up what the plural of squirrels was. It's called a scurry. I always knew that I worked with a bunch of awesome people, but talking about purple squirrels, it became clear to me that the OpenStack community is basically a large scurry of purple squirrels. Which is both humbling and terrifying when you're the person who's on the phone with the recruiters who are asking you how to find more of them. So the question facing our team was essentially how do we find more purple squirrels to hire? Well, it turns out there's one really easy answer to that and one really hard one. We, of course, went to the really easy one first. Recruiting existing OpenStack contributors, working for other employers currently. For anyone who doesn't know, Stacklytics is a website you can peruse to see stats on existing OpenStack contributors and who they work for and what projects they've been contributing to. It's basically like the OpenStack community phone book for recruiters. It makes finding a hire who's the right fit super easy. You can pick areas of expertise you need, you can find out where people work, you can hunt them down on LinkedIn, and you can probably even skip all of your interviews with your team because they already work with them. So who cares, right? So it's really late, right? I mean, like, you guys had a long day. Do you want to just go get some beers? We can be done with the talk. It's fine, right? We're cool. This is it. This is the solution. Except it's not really. Please stop hiring from Stacklytics. Please stop hiring existing OpenStack contributors. I mean, do, really, but try to minimize it as much as you can. And we came to this realization. We actually did hire a couple of very experienced people for senior positions, and that was really great, but we realized really early on that if we had 25 open spots on our team, filling 25 people was going to get really expensive, first of all. And it actually wasn't going to help the community. It's not going to increase the diversity of people inside of it, and it's not going to bring any other extra perspectives to the environment, and it's not actually going to even increase the overall quality. So when we had this moment of, like, oh, no, we probably shouldn't just hire existing contributors anymore. We should probably actually do some good for OpenStack as a whole. I kind of freaked out. And I'm sort of, I'm projecting a little bit onto you right now, but I think I might know what you're thinking, because it's what I was thinking when we realized we couldn't do that anymore, which was, this is so hard. And it totally is. We had crazy conversations on the phone. We're like, how do we know someone's going to be good at OpenStack if they've never done it before? It's this kind of weird, unique, strange thing, right? So before I get into all of the secrets of how to make this actually work, I'm going to give you a pep talk because sometimes when something is in front of me and it seems really hard and I want to go farm goats instead of do my job, I need a pep talk. So this is what I say to myself. All right, first thing. Successful people do the things that others know they should, but generally don't. Ari Weinsweig has written some of my favorite books on business and leadership, and he founded a food heaven empire in Ann Arbor, Michigan called Zingermans. I like this quote because it reminds me that each of us are capable of accomplishing so much, and that we do actually hold the answers to pretty much all of our problems within us. It's just that they might get obscured or bogged down in our busy schedules and our lives. If we commit to doing the work, we can actually get it done. This quote reminds me to get this next one is great. Huck and Force, by the way, who makes a bunch of presentation slides with Lego men, is one of the coolest people doing agile coaching around, I think. This picture reminds me of how the cult of busy or the rush to the finish line can obscure great innovation waiting to happen inside of yourself and on your team. It makes me feel better about doing something really differently, which is what I was about to do, by the way, even if it's new and scary. And a quick spoiler alert, we did hire a bunch of purple squirrels. That's a really basic chart showing you how we grew our team by a lot of people over the course of about a year and a half. I want to say we hired about 30 people, I think, something like that. Why should you care? Because I've already told you this is going to be a ton of work and that's going to continue throughout the rest of the presentation, just in case there's still no secret search term, guys, sorry. But you should care because you could keep hiring existing community members or just decide to hire whoever you want and not really think about it too much, I guess. But isn't that a little bit like pulling that wheelbarrow with square wheels and not getting yourself a little nice circular one? You need to do this because the OpenStack community is actually not at all about code. It's about the contributors that make it. And it's about the ops, people who use it. And if all of those people went away one day, it wouldn't matter anymore. So what I'm actually saying is that what you do matters. As hiring managers, as recruiters, you might not be writing code, but you're actually completely affecting how the community works, how it operates, and you're guaranteeing or perhaps sabotaging its survival. You're hiring for the entire community, you're hiring for Comcast, you're hiring for CERN, you're hiring for NASA, you're hiring for Rackspace. Who I hire at IBM affects your business and who you hire at your business affects my work at IBM. I know that's a lot of pressure when you think about it, but luckily the flip side of that pressure is that it means that you have a lot of people around you who can help you do this. We are actually all in this together. So now we're going to talk about how to build the right team. You guys ready? Yeah, awesome. So I love office space, can I just say that? Okay. As luck would have it, before we began our very intensive hiring phase, I had been doing a bunch of interviews with people on our team already about our culture and our values and our practices, which were sort of defining that culture. If you haven't done this with your team, I highly recommend it. I think culture is one of those weird nebulous words that gets you sometimes when we don't define a word and when it's kind of murky in meaning, it often gets used as an excuse or a crutch for things I've found, and it can get in the way of us doing things efficiently and effectively. Take hiring, for example. It's really easy to say this person isn't a culture fit for us if you haven't defined the culture on your team at all. And it's especially easy to say that when what you really would like to say is I just don't like them. But what if someone on your team really likes that same person? Suddenly, you're faced with a disagreement, and I feel like actually having a shared understanding of what your culture is can provide a rubric for being rigorous when you're having discussions and making really crucial decisions about hiring. Think of it a little bit like creating the tests for your hiring process. You're actually creating an understanding about what things pass or fail your own hiring gate. My own methodology to do and define our culture involved one-on-one interviews with every single person on our team. The interviews involved a set of questions that revolved around making someone good. I asked basically what makes someone good at OpenStack, what matters to an employee about working on our team. I also left some room for free-form input in those interviews, and then I compiled a summary of what everyone said, did a few collaborative sessions with the whole team, where we edited, debated, talked about the document that I put together, and then we ended up making this culture deck. It contained a list of practices that we all did every day, and those mapped to values that mattered for our team. And just to give you a quick look of how that worked out, this was just one of the values that we came up with. It's openness. So we communicate openly and honestly with one another. We make collaborative decisions with one another and with our customers and colleagues. We pride ourselves in providing accurate and timely information to anyone who needs it, and we place a high value on using and contributing to open source or free software and products of all kinds, whenever and however we can. Again, we actually had a ton of different values in the deck, but that's just one example for you to see what it ended up looking like. So this is how we talked about our candidates and their strengths and their weaknesses when we were actually hiring them and deciding who to hire over another person. I think basically this mattered because we knew that there was something more than just sort of like check the boxes of your engineering experience, right? We don't really want to hire someone just because they're great at Python, we want to hire someone because we think that they're going to be a great culture fit for our team. And so we would analyze those values and those practices when we were interviewing people. Step two, ask for help. Even aside from engaging our team with the culture discussion, we also engaged with them on a write-up of the job description that we posted. We asked for referrals, which are obviously always going to be your most effective mode of sourcing candidates, and then we engaged them in the interview process. So everyone in our team participated and interviewed as long as their schedules allowed and they were able to. Hiring was very much looked at as a group effort and we tried to keep it from becoming a siloed process as much as possible because we knew that purple squirrels were more likely to help us find other purple squirrels. This is your periodic reminder that I am on your team and everyone in this room is also on your team. This is obviously insofar as you can ask for help given NDAs or whatever you have issues with at your company, but I think it is absolutely worth engaging the whole community when you're looking for new people to hire. That can be for sourcing. You can even ask people to do an interview if you want and if that's allowed by your HR team. Step three, up your search game. The next step for improving our sourcing, we basically searched a ton of other places other than LinkedIn. Oh, sorry, this is an XKCD comic for those of you who don't understand why people are laughing at the search terms in the Google box. We figured out which companies were doing great automation and ops work with the same tooling infrastructure that OpenStack's team uses and we found out who was doing it for them via Twitter and LinkedIn. I actually cold contacted at least three candidates on Twitter by the way and sourced that way. I really encourage you to broaden your search palette when it comes to thinking about how to source great developers. Now that we're through the preparation and sourcing, I wanted to just touch really briefly on the actual interviewing process because if you present yourself well to a candidate, as you all know, hopefully they'll be more likely to come and work for you. Really, I used Arnold Schwarzenegger's space from Total Recall here to let you know that it's probably going to be a little bit painful no matter what, but we can try to make it better. Here are a couple of tips. Make sure someone is screening candidates before they run through the full interview gauntlet on your team. This is besides the recruiter screener interview, by the way. I was the person who did this for our team, but anyone who understands the values on your team and the ways that you work can also do this. I ended up filtering around about 20 to 25% of the people who came through our initial screening, by the way, out. So I did save our team quite a bit of time, I think, on that end. Your mileage may vary. It's also useful to come up with a battery of questions that interviewers on your team like and can work with during their interviews of people. At the very least, make sure everyone is evaluating candidates along the same themes, including the values and everything on your team. Oh, sorry. You should also absolutely use interviewers with unique skills and awarenesses on the team to assess those things in candidates. For example, I often try to have someone newer to the open-set community who is on our team interview someone, because I thought that they'd be much more aware and able to speak to the difficulties of getting started on OpenStack. I relied on this much more as our hiring velocity increased, especially this thing about requiring written interview notes within one hour of the actual interview occurring. I can't emphasize how much that improved the nature and the fullness of the feedback that I received from folks during interviews. It also saved my time because I didn't have to run after everyone and chase down interview notes a week later. But this is a really great thing to do. Just ask your interviewer to block out an extra hour of their time after their interview and write everything up and send it to you, and then we're all done, and it's great. Additionally, I did not allow any team members to see other interviewer feedback while the interviews were still going on, because I didn't want one person's impression of a candidate to influence feedback from others. Okay. We've reached the warning sign that treachery is ahead, which is, of course, my favorite part of the talk. I had this list of do's and don'ts written out, and I was bullet pointing all of it, and it was making my eyes cross as I wrote all of them down. So instead of giving you the do's and don'ts and long things to read, I decided to just throw out a lot of controversial opinions at you that I have developed while we were interviewing all these job candidates, and they're based on all of that culture and value stuff that I talked about earlier, and about how our team ultimately ended up ranking all the candidates we hired and didn't hire. I think you should run your interviewing process and candidate ranking in whatever way works for your team, but I hope some of these opinions stick, and I also hope you come up with some of your own. So, here we go. Personality traits matter more than stack experience. Otherwise known as I would rather hire someone with perseverance, determination, and grit, who knows more JavaScript than Python, than someone who is a Python expert but who's never had experience with rigorous code review. Relatedly, experience with ways of work beats out brilliant code. I'd rather hire someone who's a junior developer, but whose entire work experience has been with remote working and pure code review using Garrett than a senior developer who has only ever worked in in-person teams and has less experience with code review. Great candidates already practice your values. So, after you write your own team culture deck, you'll have a list of values and practices that the team can use in interviews. Ask any candidate just one of those practices and ask whether they can point to them in their work at all, even in their not tech work, in their lives in general, and you'll have a shockingly great interview question. It's a really valuable experience to have them reflect on that value and understand that it will also be valuable to them on your team after you hire them. Confidence does not equal competence. The tech world and the open-source world in particular are places where confidence is currency. That makes sense. Simply participating or sharing your opinion takes a certain amount of confidence and being willing to fight for your stance on a product. It is also true that the person who collaborates with others to sit down and write and review and ship code is the person who has the most impact in the community. Someone who has a lot of confident opinions or is the loudest arguer in the room isn't always the person who will be a great team member and ship the product. Relatedly, confidence in a candidate is less important than the ability to be vulnerable. The quickest and best way to learn about it is to check your bluster at the door and be willing to admit when you don't know something. 50% of your screen pipeline should be made up of candidates with diverse backgrounds. When we began our hiring, we decided early on we wanted to improve the diversity of our team. It followed then that to increase diverse hires, we needed to increase the diversity of the pipeline of a candidate. We were explicit about this when we asked people in the community to refer candidates to us. Don't make people work for free during their interview. This is so tempting, though, because in the open-source world, they can, right? You can just be, if someone is, like, really excited and they really want to get into it and they're going to go be like, before their interview, I committed some code already. Look at what I can do. We didn't favor that action, though. Even though it happened quite a bit and we definitely refused to make it an expectation of any of our candidates. That's true because a lot of candidates, especially by the way women, with families at home who are currently working full-time, just don't have the bandwidth in their day to do this for you. And it will give anyone who has stronger support systems at home, someone who can cook dinner for free time on their hands, an advantage that actually isn't quite fair when you think about it. Everyone on your team should be allowed to press the do not hire button and they should know they can. In practice, this generally means that the person running the hiring process is trusted enough by members of your team and so everyone feels like they can speak confidentially about any problems that they might have with a candidate to them. Don't hire brilliant jerks. It's been said a lot of times that if you hire a candidate, you don't have enough places, but it bears repeating. There is no one smart enough or talented enough to justify the continual torture of everyone on your team. They also won't actually get much done in OpenStack for you, I promise. And please, please, please, please, please come up with your own controversial opinions. Talk about them with your teams and vet them and make sure that you have a great set of interviews lined up for you. I think we have a little bit of time, so if there are questions or anyone wants to know anything, there are mics right there on this side and this side, so if you can go to those because this room is cavernous. Also, if you missed it everyone in the back, there are these really cool postcards, some of which are from my slides from the talk and they're all sitting on the chairs up here, so I'm not going to shame you for sitting in the back. Maybe a little, but you can come up and get them after. So you talked about value and culture, but you didn't mention shared purpose. And I'm curious if you ran into that with your teams that in hiring or preparing to hiring there was some confusion at times between people who had different tasks as to what the overall shared purpose is. What's the point? Why are we doing this? So that's an amazing question and I have to say coming up with a mission statement should not have been difficult because our team actually was immensely gelled in the space that they were in and HP, the team that I was on at HP was lucky enough to be able to work 100% of their time on OpenStack full-time. And eventually we debated for a couple of weeks on coming up with our team mission statement, our team purpose and we did write that out as part of the culture deck as well. So that was part of the whole process. I think that's really crucial. I hesitate to tell you how to do that because that's something actually that more companies have latched on to at the company-wide level but I do think that it's really valuable depending on how large your company is and how your team situates within it to do one for your own team as well. Go ahead. I was wondering if you had any conflict between culture and values and trying to increase the team diversity. No. It's so strange, isn't it, that when you start talking about I mean for me the beauty of, I know that project management and program management are really dirty words for a lot of engineers for really good reasons but to me the ultimate beauty of project management is making the invisible visible and in some ways that's what this process was, right? We talked about something that we hadn't really named yet but we all kind of sort of felt and we made it visible to everyone and in that clarity I think that everyone understood that there's nothing in our values that is about where you come from what the color of your skin is what your gender is or isn't and I think that actually only becomes clearer when you talk about the things that really matter for getting work done unless you work at a terrible place in which case I'm really sorry but I don't think anyone here does that right so it's fine. So you're from a big company, I'm from a big company have you trained your HR recruiters or are you still doing this on your own? I worked with two recruiters at HP I just started at IBM last September and I have not been lucky enough to be involved in hiring yet, I can't wait to do it there that's my excited face but I worked actually really heavily with recruiters at HP I had two main recruiters who were my points of contact and I drilled a lot of things into their heads So it's an education process? Yeah, they don't run when they think about purple squirrels anymore it's great. When you worked on the culture and value of your team and when you defined the questions of your recruiting questions did you have some troubles within your team where people seem not to fit the culture of the others? That's also a really good question I think I'm lucky enough to come from an environment especially with the direct manager above me at the time who is very much a believer in all of the humans on his team doing the best they can with what they have and I think that approaching the entire conversation around culture and values PS, one of our values was trust and that really extended to everyone trusting everyone else on our team and so it was actually made explicit that we don't really tolerate people sort of thinking that someone's not living up to without maybe being open and talking to them about it right? Or talking to somebody else to help them have that conversation So we didn't like discover that someone wasn't on board if that's what you mean but I do think that having really frank conversations we did have a few quite pointed debates around some of the language in the deck and I think that that helped everyone kind of come to terms within themselves what it meant to them to be a part of the team I think that sort of helped alleviate it's like little therapy sessions you know it's good Tim! I don't like hearing myself talk but how much interviewing is too much interviewing is everyone on the team interviewing every candidate that passes the screen? That person would never come work for you can you imagine? So we depending on the phase that we were in in terms of how many people we had on our plate and how many wrecks we had open I think that our maximum was we had so we had a screener we had the recruitment screener then we had the me screener and then when somebody made it to that they would usually see three different people on the team and I made it a point to pick three people on the team who didn't all do the same thing and work in the same realm and have the same perspectives on life but that was really the only the diversity of the interviews within our team were the only kinds of requirements we placed on stuff so yeah So there's another dirty word out there and that's internship trying to gather support to create an internship program and it's really difficult to convince whoever it might be the personality of experience because most people just don't have the experience like you said so I'm kind of interested to hear the large number that you said you hired where was that threshold of okay this experience versus just the personality that you mentioned or the other requirements and how you go about justifying that with solid numbers or whatever methods you use to be actual people that are responsible for the hiring. Well I mean the numbers we weren't like assessing people in a as rigorous a rubric of like on a scale of one to ten right them in this value we didn't do that but we did use the values that we talked about mattering to our team when we were weighing candidates against one another say for a single position saying well did they talk how much did they talk about their ability to work with remote teams how is this person more familiar with working on IRC than this person we saw a lot in particular a lot of systems administration candidates that would come in and would only have work would have deep deep deep system and knowledge like up the wazoo but who would only have experience working in a ticketing system so they would literally wake up in the morning to a bunch of tickets and they would work their way through them and then clock out at the end of the day and be done and I'm sure they were excellent at what they did but if they were to have shown up on our team they would not have known what to do we would have made an exception at that point for someone who was already involved in an open source project on the side let's say and had experience with like self-motivated self-designed more kind of conversational based work so really what I'm trying to say is like numbers didn't really come up we because you're talking about humans too right and no two candidates were ever the same so how can you even really create a similar system to rate them against one another all seems a little bit terrible yeah hope that answers your question a little anyone else no one more you mentioned you hired somebody with JavaScript skills because you felt they had the right personality have you had success with a large number of web developers like Java helping them transition into the open stack world well there actually is a in total fairness we hired some JavaScript folks who were actually going to work on front-end work in the open stack which there is work there as well right now that can be done you should hire some of those people are you thinking horizon only or what no no I mean there's a storyboard and you can go talk to my coach check about about working on a whole bunch of different UI and interface stuff for all of the projects in open stack actually so I think overarchingly there's not like a line that I would draw in the sand I would say that the person that we did hire that was very very very talented programmer in one language got up to speed in Python much faster than he got up to speed in the ways and culture of working in the community so I actually I mean and this is true across the board of managers and recruiters know already somebody who's really really great engineer will be able to kind of transfer their stack experience and adapt to new stacks pretty easily actually the people stuff is a lot harder I would I would really really vote for you to focus there thanks I wanted to ask you it kind of follows up on the last question but whether you said that personality traits outweighed brilliant code how about did you give any consideration to hiring people who showed the right aptitude and had the right personality traits but didn't have open stack development experience and look towards training them up bringing them up to speed well I full confession time I probably have the least engineering aptitude of anyone on our team and I wouldn't I do think that there is a low I think there's a threshold at which somebody should not be waiting into open stack in terms of engineering experience I would say that engineering experience at what I would judge between like a junior to medium level somewhere like lying in there it's fine to bring someone in I think someone who's just come out of an intensive code school or something like that might have a really difficult time coming in so I do think there's like a floor for where you really don't want to throw someone into open stack you might want to hire them to work on another project at your company and then like slowly introduce them to open stack over time but to just throw them into open stack full time would be extremely traumatic it certainly was for me that's why I'm doing this stuff so I think yeah I do think that there's like an aptitude or ability level but like the experience in engineering really actually does matter when you're having these discussions with the community that's what I was going to ask about work experience versus like just education somebody straight out of school no I mean school I don't care if someone has a computer science degree at all actually I'm I don't I was is that a radical opinion I thought we were already there as a as a group but but yeah I know a computer science degree means almost nothing to me and we did hire some people right out of school and they had participated heavily in open source projects already during school and that was actually what mattered to us the most when we looked at their work so anyone else now awesome well thanks so much for coming you guys come up here and and get postcards if you want thanks