(Image from archeon on Flickr) Small engineering teams who want to diversify have a hard row to hoe. Large organizations can throw money at the problem, by (for example) sponsoring the Grace Hopper convention [1], or making a few highly public donations to non-profits. [2] But when you’re small, without access to those types of resources, what options do you have?
People ask me that a lot. I’m not a diversity consultant; I’m a code consultant. But I’m interested in these issues. I founded one of the first learn-to-code non-profits, and I’ve worked on code with a lot of different teams at a lot of different companies. On those projects I’ve seen diversity efforts that hit it out of the park, and others that crashed and burned. So I’m happy to weigh in with my reckons when people want advice.
If you diversify now, think of all the money you’ll save in 5 years when you don’t have to sponsor the Grace Hopper convention! (image from abiwt on flickr)
Usually, the people who ask me this are:
- Leader of a small dev team (fewer than 20 people)
- Aware of the diversity challenges software development is facing
- Wanting to diversify their team along (at least) the gender and race axes, at all experience levels
- Not super sure how to actually do it.
Here’s the approach I generally recommend.
1. Start the networking long game
You need to build up a network of diverse developers, particularly at the mid- and senior levels. This won’t happen overnight, but today’s the best day to get started. You can’t diversify without it.
That network people said you needed to get a job is now the one you need to get employees. (image from biker_jun on flickr)
Follow folks on twitter. Go to their talks at meetups and conferences. Talk to them about tech topics. Look at who they talk to and follow those people too. A spreadsheet is not out of the question.
This is often the first (and only!) advice people get about diversifying their team. “Get to know people, and then hire them!” I can’t disagree. Networking absolutely works on its own — if you’ve got years.
Most small companies don’t. A large network of diverse developers is necessary but not sufficient for success in the shorter term. Start forming it now, at the same time as you do these other things.
2. Partner with a local code school
Most small software development companies in san francisco only want to hire mid- or senior-level developers, but involvement at the junior level is a crucial step in attracting those more experienced folks. We’ll talk about that more in step four. Step two is where you grow your network of diverse junior devs and code school staff.
There are many ways to grow your network of junior developers. Even within your own company, folks in support or testing often would love to make the switch to engineering. Outside of that, code schools are probably the most efficient way. I live in San Francisco and you can’t throw a rock here without hitting a code school. They offer a targeted way to meet available junior developers, and their students are often more diverse than the industry at large.
I don’t make any money off of any code schools, but I do volunteer to mentor at some of them, including Hackbright Academy. (image from Give Photography)
What “partner” means will vary by school. Many of them have volunteer mentor programs that match students with folks in industry. You can often participate remotely. This lets you meet a student and get an idea of what they know and don’t know, as well as start to feel out what the code school is teaching. The schools have vastly varying philosophies and curricula; you may need to try more than one before finding a fit.
In addition to mentor programs, many schools have an official “hiring day” event that you can pay to attend as an employer. Generally this means you get to meet each of the students in person for a few minutes to chat about what they’re working on and what they’re looking for. It’s a great thing to do at least once to level set your expectations of students’ experience.
Your goal with all of this is to get a sense of what junior developers know before you plunge into step three.
3. Hire two code school grads
This will be the hardest part. Your team will be learning how to work with junior developers, and on a diverse team, at the same time.
Change is a-comin’Your goal is to make these junior devs successful. To do that, you’re going to have to allow for some culture change. It’s easier than it sounds; in practice it’s incremental, and most of your team will adjust. However, it’s useful to be explicit with your team ahead of time about this. Don’t let it surprise them.
Whatever you do, don’t hire diverse junior devs expecting to shoehorn them in to the culture you have now. It won’t work. They’ll quit. Diversifying your team necessarily means culture change — usually for the better! But it can be unsettling to some developers, so be prepared to work with them to adjust.
I could write a whooooole series of blog posts about the complexities of this step [3], but here are a few quick tips:
- Hire two. Being a solo junior on a team of mid-level and higher is a weird, isolating experience.
- You’ll all need to be more explicit in your communications. Things that were once fine to leave unsaid now have to be said out loud.
- Pair programming is the most efficient way to onboard, if your team is reasonably good at it. I have written before about how to pair with junior developers. (No time like the present to start practicing!)
- Make sure they have a manager and peers with enough time (and explicit management sanction) to work with them.
- It will help if you deliberately try to make your code more junior-friendly (starting now). Your goal should be no unintended side effects. In other words, when someone changes code in one place, it doesn’t accidentally break something seemingly unrelated on the far side of the codebase. [4]
- Your team will need to lose any “programmer ego” they’ve developed. They’ll need to get comfortable saying “I don’t know” when they don’t know something, rather than bullshitting an answer. This has to come from the top. You have to talk about it, and more importantly, you have to model it. Start before the juniors show up.
4. Start looking for mid/senior folks in earnest.
At this point, you’ve got some diversity in your team, but it’s uneven across experience levels. This is a poisonous dynamic if you allow it to persist. Stopping when their percentages look better but all the diversity is junior is the biggest mistake small companies make. This is because once your team gets used to “all the not-white-men are novices,” it’s really hard to break them out of it. It’s unintentional, but we as humans, and especially as developers, are great pattern matchers. Patterns of interaction that we see, and especially the ones we experience, become an unexamined part of “the way things are.” They affect interactions, promotions, interpersonal dynamics, and more.
Growing your own: nice idea in theory. Won’t work in practice.Some teams purposefully only hire diverse developers at the junior level, with the idea that they’ll “grow their own” mid-level and eventually senior devs. It’s a reasonable hypothesis, but it doesn’t work. Once senior devs get used to being in positions of authority over folks who are so obviously different from them, they often unconsciously resist the idea that people like that could be peers.
If you let this imbalance exist for too long, then even if you do hire an experienced diverse developer in, they’ll get unconscious pushback from their peers who have internalized this sense of hierarchy. As a result, a higher-level developer hired too late is unlikely to be successful.
So once you have your juniors, you should immediately start looking for folks in the mid-level and senior ranges. This is where that network from step one kicks in again. The difference now is that your higher-level candidates won’t be the first under-represented-group hire.
Strategy Revealed
It’s a huge risk to be the first woman, or the first person of color, or the first physically disabled person on a team. In the course of a few interviews, it’s hard to tell with any accuracy whether the group is a place they can succeed.
Reduce the risk a higher-level candidate takes in choosing your team, by diversifying first at the lower levels. (image from mauropm on flickr)
Developers above the junior level, no matter their demographics, have a huge number of choices. It’s rarely worth it to be The First. But now on your team they’re not! You’ve removed a significant barrier to hiring at the upper levels, by hiring first at the lower levels.
You might wonder whether all this sturm und drang is worth it. Is there anyone to hire from under-represented groups, apart from juniors?
I can see why people might wonder that. Higher-level developers from under-represented groups will almost never apply for your job. Fortunately for us, though, it’s a perception problem rather than a supply problem.
Developers from under-represented groups do exist at the mid- and senior-level, and in significant numbers. They don’t change jobs as much, though, because of this higher risk. That’s why building your network is so crucial. It is the only way you’ll get people interested.
Sticking Point: Speed
Getting a diverse team means being exposed to way more points of view than you are now. That’s incredibly valuable, but it also means you’re going to be doing more talking than you were before. By hiring people from similar backgrounds, you’ve been able to take advantage of certain efficiencies in communication. Many leaders see that as an advantage. Certainly it means you can turn out a higher volume of code per unit time than a team who spends more time talking.
Is “fast” always what we want? Or what we need?Ask yourself, though, if raw speed is really what you need. Often this idea comes to us from non-technical executives. They don’t know much about engineering, and they think they need speed from their team. What they actually need is thoughtfulness (to get off wrong paths sooner) and flexibility (so it’s easier to correct). It’s your job to adjust their perceptions — or to redefine speed to include the longer-term savings from getting off wrong paths sooner.
An executive with only a surface-level understanding of what “speed” means on a development team holds you back. Educate them.
What’s at Stake
As you grow out of being a founders-only startup into a small company with employees, what the business needs from engineering shifts. Keep your eye on that ball. Once in a while, ask yourself if you might be operating under previously-valid assumptions that no longer hold. It might have been true last year that you couldn’t hire junior developers because you had an investor deadline; maybe it’s less true now. Look for a way to make it possible.
Companies who fail at diversity insist they can’t hire junior developers.Companies who succeed find a way.
Incorporating people with wider ranging opinions and experiences is ultimately broadening for everyone, and ensures that the business is well set up to succeed longer term.
All that’s at stake is your long-term success.
End Notes
[1]The Grace Hopper Celebration of Women in Computing is a conference run by the ACM and the ABI. It is oriented around and designed for women who work in academia or large organizations. Sponsorships and tickets are priced accordingly. back to source
[2] These carpet-bombing tactics are part of the reason why you find more developers from under-represented groups at large companies than you do at small ones. Big companies have resources, and PR teams, and that shit works. We can’t beat them on those terms; we have to play a different game. back to source
[3] And perhaps I should? back to source
[4] I have many Opinions about how to accomplish no-unintended-side-effects, and what else makes junior-friendly code. Sadly it’s out of scope for this post. Folks seem interested in the topic, though, so I’m working on it. Let me know on Twitter if you have ideas. back to source
If you want to comment on this post, you can find me on Twitter. Thanks to JC Grubbs for giving me early feedback, and to many other friends for talking with me about their experiences.
