Want to hire for more diversity? Then throw away your culture fit requirement.

So you want to start having more Diversity in your team and organizations. How do you do that? Well, you can start by throwing away your culture fit requirements and questions when interviewing candidates for your teams. 

Most people think of Diversity and Inclusion at work along typical lines of race, gender, religion, sexual orientation, or abilities. Diversity and inclusion are more than that. Things like neurodiversity or even personality traits like introvert, extrovert, and ambivert go beyond what people typically think of when it comes to Diversity.

You tend to employ very similar people when you hire based on cultural fit (aside from the usual skills). And when you do that, you decrease the potential Diversity on your team. You increase the echo chamber of sameness, similar to what you find on social media with posts that you like, and end up having a very narrow, skewed perspective. Studies have shown that more diverse teams perform better than less diverse teams.

Solving Jigsaw Puzzles

Yes, you most likely will get along better with people similar to you when you have someone who matches your culture fit. However, getting along is only part of the equation for high-performing teams. One of the critical things for high-performing teams is the impact they produce. When you have more diverse opinions on a team, the team has a better chance of coming up with really unique and novel solutions to problems your business is trying to solve. 

It does take work when hiring someone who isn’t quite a cultural fit. And I think most people and organizations fail to realize that there is more work to do when hiring for Diversity. Because you now have to ensure that you are inclusive of everyone when you have a diverse group of people. Diversity and inclusion are two different parts of the equation – one without the other will cause problems if your efforts aren’t balanced.

No one ever said that Diversity is easy. Most organizations I know hire for Diversity, but once these people are in the organization, companies fail in providing an inclusive environment. Instead, they constrain people by telling them they need to act or behave a certain way. In the end, you’re only creating Mini Me’s that defeat the benefits of Diversity.

How I Went Against The Grain

Let me give you an example of what I mean. At a start-up I was working in, I was the engineering director, and we were interviewing software engineering candidates. From the skill side of the house, we interviewed one candidate who had ticked all our boxes regarding skill sets. 

However, everyone on the interviewing team (including the CEO) had their thumbs down when it came to a decision for hiring this candidate. I was the only one who had a thumbs up. I had asked why everyone had their thumbs down. All responded and said they didn’t think he matched our company culture fit. They felt the candidate didn’t fit the culture because he was more reserved, introverted, and quiet in his demeanor. He didn’t display the high-energy, gung-ho, peppy personality people wanted. They felt he would only keep to himself. 

But I saw things differently. I noticed that our candidate had solid engineering practices. Yes, he didn’t fit the culture fit questions – that was very obvious. But I overrode everyone as Director of Engineering and proceeded to hire him. It was my decision to make in the end. 

Once I hired him, I made sure that I put in some extra work to be more inclusive of his style in order to incorporate it with the rest of the team’s styles. I put in a little more effort to ensure that our new team member would succeed. And I also suggested to my direct reports (including our new hire) how to slightly modify their approaches to other peoples’ styles.

In the end, my decision to hire against the grain of culture fit paid off.  Our new member brought fresh perspectives to problems we were trying to solve. He came up with some very creative approaches that the team had not even thought of or considered. He even managed to mentor some of the more junior engineers. 

In the end, my CEO was impressed. He said that I had made a good decision in hiring him despite everyone saying no due to the lack of “cultural fit.” It took this one example to show everyone that hiring for Diversity goes beyond the standard checkboxes of race, gender, creed, or sexual orientation. It took this example to make people realize that hiring for Diversity can be achieved in other ways. And incorporating this expanded view – with the commensurate amount of work – can enable teams and organizations to create more meaningful impacts and outcomes.

Your Company Culture Starts with Recruiting. Don’t Fu*ck It Up.

A lot of companies of late have been touting their incredible company culture. They extoll how their culture has enabled them to succeed and how people can have a lot of fun while co-creating products and services that their customers love.

Companies often think about their culture once you join the first day after you sign on the dotted line accepting the offer. But sometimes, I wonder if these companies really understand their company culture, and specifically, where it begins.

Ru Paul Drag Race ©World of Wonder Productions
Ru Paul Drag Race ©World of Wonder Productions. Copyrighted content falls under the guidelines of fair use.

Recently, I got contacted by a very well-known company to help with their Agile rollout. This company is very prominent here in Silicon Valley, not far from where I live. I have a few friends who work there, and they tell me they’re having a blast. They’ve been on a hiring binge during the pandemic, and I’ve seen a lot of LinkedIn postings extolling their company culture to entice job seekers.

After talking with the recruiter for the company, I seemed to be a good fit for what they were looking for and dove right into the interview process. I went through the interviews for about two weeks and passed with flying colors. The recruiter called me one day and said the job was mine. I asked him what they were going to offer me, and he said the paperwork for the offer is coming. Still, in the meantime, I needed to submit to a security check. 

I responded, “Uhm, isn’t this the other way around, where the security check is done after the offer has been signed and accepted?” He said that it usually is, but he wanted to start the process early. I politely told him no, and that I’d rather wait for the offer. The recruiter said okay and hung up. I never heard back from him again.

The recruiter never mentioned to me that the offer was contingent on agreeing to a background check. Why would I let a company conduct a background check if I end up not accepting their offer? During my entire career, background checks always occurred after accepting an offer. If this is a specific requirement for the actual offer, at the very least, the recruiter should have told me.

Mind you, this is from a renowned company here in Silicon Valley. I have a few friends who work inside that company. They said that what you see on LinkedIn: the work that people do, the environment they work in (including remote), the perks they get, the collaboration – most of those are true. The company culture inside is, in general, fabulous. 

But I asked, “Well, what about my recruiting experience?” All of them said, yes, they all had bad experiences while being recruited. Some of them even said they almost didn’t say yes to their offer.

I’d be happy if the recruiter just called me back and apologized, saying the position didn’t work out in the end. It’s all about common courtesy and treating people as people. I am not a quota to fill.

I’ve had a few experiences with recruiters who did just that. I particularly remember two particular recruiters. For both these scenarios, I was very much along the path to getting hired. They both told me the offer was working its way to the system. And then, something happened. They couldn’t follow through with the offer for particular reasons (not relating to me as a candidate). They apologized, and I was obviously disappointed. However, I still remember these two recruiters because of how they treated me as a person.

 

Recruiting includes valuing people and interactions

Twenty years ago, the Agile Manifesto was published. One of the key values was that we “value individuals and interactions over process and tools.” If you genuinely want to be that company that can tout company culture from the get-go, you need to start at Recruiting. 

Sadly, the recent experience I just recounted isn’t new. I’ve had similar encounters happen to me all these years where I never hear back from recruiters. Whether I get the job or not, shouldn’t recruiters treat potential candidates as if they’re already part of the company? 

As a hiring manager, I make it a point to contact the people I’ve interviewed and tell them the news – good or bad. Yes, people are dejected when they hear they didn’t get the job. Still, quite a few responded positively even with not-so-good news, telling me that it was great to get a callback since people often never hear back when the news isn’t good. I’ve also interviewed at a few companies who treated me as if I was coming to join them. And though the position didn’t work for me in the end, it worked for a few of my friends who I recommended after the process because I had an excellent experience with recruiting.

Recruiters and hiring managers need to begin with empathy and kindness in dealing with their potential hires and not f*ck it up if company culture is a key value. It’s all boils down to living what you say you’re doing.

 

Postscript: Remember that well-known Silicon Valley company? I did get contacted by other recruiters for other positions over the following months. I politely declined, saying I wasn’t interested in the positions they were hiring for.

Let Them Eat Cake

How do you proceed to eat an entire elephant?

One bite at a time.

Wait – I thought this was a post on cake? Why are you talking about eating an elephant? Let me get to that in a moment. (Unless you made an elephant cake, of course.)

I’m not trying to be facetious here with the eating an elephant analogy. I’m highlighting a struggle that many Agile teams face when they are first going about their Agile journey. How do you break down a project or product delivery into smaller pieces? How might you deliver something that has value to someone every two weeks (or even much less, like three or fewer days for Kanban)? You will need to create small bites – or slices – that someone can use if you want to deliver within your iteration. In other words – it has some value to someone. 

Marie Antoinette and Cakes

Think of it this way – say you’re serving a 5-layer cake (are you noticing copious food analogies here? 😉 ). When you give the cake to someone, you don’t give them the entire bottom layer (since it’s the only one you’ve finished baking, perhaps), and then wait for them to finish before giving the next layer (which hopefully is done by the time they consume the first layer). That’s just too cruel and disappointing, right? No, you give them a slice – a small sliver that contains all five layers and icing.

When you break things down to their smallest value, you have to think about delivering in terms of valuable (consumable) slices (of yummy cake). You might say – yeah – but I still had to bake all five layers, make frosting, put it together, and then get a slice of cake to serve. For cakes, yes – you have to do that. But when it comes to work and what you deliver, do you genuinely need to build every layer?

A Simple Slicing Strategy to Start

One of the most common ways to start slicing is looking at the Happy Path Scenario and building that. We solve for all sorts of flows, where someone starts from point A and ideally ends up on point B. 

For example, if you’re building a website, one small flow you can work on is creating an account. The Happy Path here is landing on a sign-up page, providing an email, providing a password, and voila – you now created an account. 

Does your sign-up page have to be high-fidelity at this point? Not necessarily. When Google first started, all they had was a simple space bar and a Search button.

What if the user entered an email that already existed in the system? Well, you may not have built that yet. As I said, this slicing example is the Happy Path. This example is what I mean by a slice. A slice is a small piece of work that is achievable in a tiny amount of time. And it has value – we enabled a user to create an account. And we can get feedback to help us enhance and modify what slice we potentially will do next: Do we continue with the current cake? Or do we pivot to another part of the cake? Or do we make another cake entirely?)

You might be saying, “Yeah, well, if this was your cake, you still can’t serve one piece to the customer. They are buying the entire cake.” Yes, you are correct. The beauty here is that you’ll find yourself building a bunch of small slices. And when you aggregate these slices together, you will end up with a “good enough cake” that you can serve. It’s valuable enough for people to use. You may not have built everything you wanted yet. But you may have something usable by a small but sufficient amount of people to be valuable enough to release.

Other Slicing Strategies

In the previous section, I already alluded to two other slicing strategies. Were you able to spot them?

The first one that may be obvious is slicing for different error conditions: What if the email account exists? How do we prevent a bot from creating a bogus account? And so on.

The list of error conditions can be infinite. Do you need to build for all of them? Not necessarily. You can now look at prioritization strategies. You might create a variant of an Eisenhower Matrix. Your X-axis can be the probability of the error (low probability to high probability). The Y-axis considers your risk (low risk for the customer to high risk for the customer). You can target the error conditions in the high probability, high-risk quadrant as the ones to build out first. (Or, another alternative instead of prioritization is to build a story map.)

The second strategy may not be as evident with the Google Search example: start at very low fidelity, and build up from there. Using this strategy is most effective when you’re collaborating with UX Researchers and Designers. Working together, you might target a low fidelity scenario for the first slice of cake you’re producing to get feedback on what you’re creating. You’ll be continuously learning from feedback while still building for the whole.

Beyond Software Delivery

You might be saying to yourself, “JF, this is fine and dandy for software product teams, but I’m not in software.” 

The same slicing strategies apply. For example, let’s take a look at HR and onboarding a new hire. From the moment a new hire clicks on Accept on their offer letter to the first week they start, an onboarding flow exists. And you might want to build a flow that is engaging and frictionless for the new hire.

As a startup company, your new hire flow might be somewhat low fidelity. You might start with a simple document that they sign, a questionnaire for what machine and login/email name they’d like so that these are ready on their first day. You might start sketching out a manual process to start and then slowly automate it over time.

As the startup gets bigger, your onboarding flow might become more complicated since your company may be hiring many people. You might want to automate the procurement of laptops, for example, so that it gets automatically configured and delivered to the new employee in these times of pandemic.

And here’s the third slicing strategy that you can use. When you have a long and complicated flow (whether existing or new), you can break down the long, complicated flow into smaller flows that you can target. 

It’s like driving from San Francisco to New York. You can do it one straight shot, but that’s going to be too tiring and leave you with no time for enjoyment. You can break the trip down and have some pit stops for exploration and fun. You can design your trip to stop in Arizona to explore the Grand Canyon. Then head on over, making a left at Albuquerque so that you can grab some good ol’ barbeque in Kansas. 

You can do something similar with HR onboarding. You can concentrate on a subsection of the flow and fix problems. You may want to modify it. You can also add new, additional flows to make the whole onboarding process better by adding one small flow at a time.

These are just a few quick ways to break down things into deliverable pieces of value during each iteration. There are many other slicing strategies that people have written about, which you can find through Google. I typically start with these strategies when I’m coaching teams that are new to Agile. Hopefully, these few suggestions can help you on your path to getting comfortable with breaking down items that fit in an iteration.