Reading Time: 14 minutes

Diversity is not chiefly a pipeline problem. At the industry level, it is chiefly an inclusion problem tied to very specific monetary outcomes for your company.

And you want to build an inclusive company. But at this company that you’ve built/joined, you’re struggling to make progress.

You’ve done hours and hours of implicit bias training, but somehow every time you dare to do an anonymous survey, you get additional tips from employees about exclusion-related bullshit that happened to them. On your watch! After you shelled out bank for all these gahtdamn bias trainings! 

Aren’t people paying attention in the bias trainings?

They ain’t.

“What?!?!? *pearl clutch* I was paying attention!”

I don’t mean you personally. I mean people, as a whole, who get assigned this bias training, aren’t really paying attention. Mind you, everyone kind of thinks they are paying attention. But they ain’t. And the reason they ain’t is that, usually, the information has no bearing on their career trajectory.

Bias trainings are interesting, but after they’re over employees don’t focus there because they’re not evaluated on their inclusion literacy. Instead, employees focus on the skills they need to get ahead—writing code, appeasing the boss, establishing influence.

Individual people treat inclusion like an elective because the company’s incentive system treats inclusion like an elective.

It’s time to evaluate people on inclusion, too. Once employees need it to get ahead, suddenly they’ll be going  above and beyond those bias trainings to learn it.

We have specific rubrics for technical skills. For example, we expect programmers to know about variable naming, class design, architecture design, refactoring, testing, performance concerns, security, accessibility. We should strive toward an equally rigorous rubric for inclusion literacy.

A Proposed Rubric for Inclusive Company Culture

Let’s talk about five skills that your employees need to contribute to an inclusive company culture. Higher levels of these skills merit consideration for higher positions. On the flip side, someone who lacks these skills, especially when promoted to a position of power, will actively prevent your culture from becoming inclusive.

You will notice that these skills do not mention gender, race, sexual orientation, or any other demographic group: not once, not anywhere. That is deliberate.

Implicit bias training usually highlights the groups that catch the brunt of implicit bias: women, people of color, and LGBTQ folks, for example. People from marginalized groups are more frequently and more aggressively excluded by the status quo in company cultures, and that’s an important thing to talk about. I do not recommend taking this angle in a performance review. Leave it in the implicit bias training.

Why? Because it’s a recipe to sour some grapes.

Picture this: an implicit bias training is (usually) a general information session where nobody is getting individually called out. The point is to discuss those things directly without putting someone on the defensive—and even so, implicit bias trainings sometimes do put people on the defensive.

Now, imagine if you took that angle while evaluating an individual employee. If you evaluate someone’s individual behavior on a metric that sounds to them like Are you racist? or Are you sexist?, you have no way to point out a growth area without insulting them. Any shortcoming you bring up will sound to them like ‘You ARE racist!’ ‘You ARE sexist!’ Maybe it’s true, but it’s probably not productive. It feels too much like a personal attack, which makes it super hard for your report to even accept the feedback, let alone grow.

So instead, we’re going with five skills that, when applied universally, make the workplace more inclusive for everyone. If your report applies these skills with some people and not others, then you can bring up those specific examples in a performance review while referring to the skills, rather than calling them racist or sexist.

To describe each of these skills, I have chosen a series of questions that you could use on a rubric to evaluate folks’ proficiency with these skills. These questions can help you give employees benchmarks to reach for in improving their inclusion literacy. They also demonstrate practices that your reports can use on a daily basis to build those skills. In each, I’ll link to additional material about that specific skill. Throughout, I will refer to the person you are evaluating with the pronoun ‘they.’

1. Moderation

• Can they give others in a meeting the opportunity to listen by protecting their opportunities to speak?
• Do they solicit the views of folks who haven’t spoken whose opinion is relevant to topic?
• Do they give the floor back to people it is taken from (by interruption)?
• Do they encourage points of view that disagree with them to speak up in meetings?

When leaders don’t know how to moderate, the leadership team leans toward caucus-style meetings, which are by default not inclusive meetings. That’s why moderation is such a critical skill—especially for leadership. For more on moderation, I recommend reading the moderation section in this post about solving the caucus problem.

2. Soliciting Opinions

A lot of important insight gets missed when your team only hears the insights of whomever is willing to yell their unsolicited opinions across the room.

• Can this person identify whose experience will be affected by a decision, and go ask them for their views on the decision?
• Can this person identify whose background qualifies them to influence a decision, and go ask them for their views on the decision?
• Does this person identify who isn’t going to agree with them on something, and go ask them for their views on that thing?
• Does this person identify who will have helpful (and probably not congratulatory) feedback on their performance, and go ask them for feedback?

For more on solicitation, I recommend the solicitation section (item 1) of this post about company culture.

3. Attribution

• Does this person remember, when they know something, who taught it to them?
• Do they think they are solely responsible for their success?
• Do they take credit for other people’s ideas?
• Do they repeat or rephrase other people’s ideas in meetings without attributing those ideas to their original providers?
• Do they make sure to give credit for projects and suggestions to other people?
• If someone else were alone in a room with them, would that person feel comfortable sharing a brilliant idea, with confidence that they would attribute credit properly for that idea?
• Do others feel overlooked, diminished, or ignored by this person? Or do they feel uplifted and recognized?

For more on attribution, I recommend the attribution section (item 2) of this post about company culture.

4. Most Advanced Assumption

• Does this person condescend to others in the workplace and give the impression that they think other people are less capable than they are?
• Do they lob unsolicited advice across the room, offer unhelpful advice without determining what kind of help a coworker needs, or make excessively basic suggestions to experienced coworkers?
• Do they assume, without information to the contrary, that they know more about any given topic than any given person? Or do they level-set in a conversation to make sure they’re not condescending to others?

That is, do they assume that the other person’s knowledge is as advanced as is reasonable, and then let that person ask them questions if they don’t understand something? Have they cultivated a level of approachability such that, in this situation, coworkers will ask this person these questions? When asked these questions, does this person answer those questions respectfully, without condescending to the asker?

For more on making assumptions about other people’s knowledge and answering questions, I recommend the section titled ‘Why shadowing/pair programming isn’t enough to orient a new team member’ in this post about adding members to your software team. The diagrams in that section explain why someone can be at an advanced level and not be familiar with what you consider to be a basic concept. The section goes on to provide some coaching about answering questions. This gives you a foundation for assuming people know things without later being surprised if they do not.

5. Capitalizing on Alternative Perspectives

• How does this person manage disagreement between members of the team?
• Does disagreement make them shut down and defer to authority, or double down and push their own perspective even harder? Or do they start by trying to find the part that everyone agrees on, then determine from there how people’s views differ and why?
• Do they couch their views in terms of rigid beliefs, or do they start from examples and experiences that explain their position?
• When everyone seems to agree on something, do they solicit opinions from those who might be keeping quiet because they think voicing their disagreement is gonna cause too much trouble?
• When there are multiple perspectives, does this person naively defer to a majority vote? Or do they consider everyone’s position and look for creative solutions that account for everyone’s contributions?

For more about capitalizing on alternate perspectives, I recommend the Substantive Disagreement section (item 3) of this post about company culture.

How do we set levels for these skills?

We have five skills that people can work on to raise their value as contributors to an inclusive culture.

How do we level-set on these skills? What’s a hireable skill level? What’s a promotable skill level? At what point would a lack of these skills justify not hiring, not promoting, or even sending people back the other way? I trust you to make the decisions on where those lines fall for your company.

That having been said, it can be a helpful exercise for your team to sit down together and consider how you all might set these levels based on your values. What does inadequate inclusion literacy look like for you? What’s a hireable amount? At what point do you want that person in leadership? Whatever you choose, you’re way ahead of the majority of tech companies that aren’t systematically evaluating anyone on any of this.

How do we collect data on this to evaluate employees?

This skill set can be tricky to evaluate for a new hire; you can ask the above questions directly, but candidates  try to tell you what they think you want to hear. Luckily (?) these types of skills are so rarely emphasized that people aren’t likely to be able to make up accurate-sounding answers without having genuinely worked on themselves in these areas.

Also, the questions above offer opportunities to set up case scenarios to work through with interview candidates. “When you’re in a meeting and everyone is trying to talk at once, what do you do?” “Everyone disagrees on this thing. How do you sort it out?” These cases give candidates an open-ended opportunity to share their experiences with these situations—plus, since they’re open-ended, they don’t lead the candidate to your preferred answer.

References can also help you gather information, though it’s worth noting that most candidates provide references who they think will speak highly of them. One option is to determine if you and the candidate have any common connections and ask those connections what it was like to work with them. From doing this, I have had conversations that influenced me to hire candidates (or, sometimes, to not hire a candidate). Admittedly, this is easy for me because the tech community in my city has some small-towny qualities. From my vantage point, it’s worth trying.

How about when you’re evaluating current employees? Let’s assume, for a moment, that you’re a manager. You know this person from more than their resume, so you may feel more equipped to evaluate them. That’s a false sense of confidence. Your personal experience with this person doesn’t say much about their inclusion literacy.

Why? Because you have authority over this person, so of course they will be inclusive of you personally. What you need to know is how they demonstrate these skills around their peers or their reports. So how do you get that information?

You’ll need to collect feedback from those peers and reports. Have they felt able to contribute to meetings where your report was present? Has your report solicited their opinions and feedback? Would they feel safe describing a brilliant idea to your report in private? Does your report describe 101-level things to mid level and senior peers during discussions, or does your report assume people understand things? Do people feel comfortable asking your report questions when they don’t understand things? When people have different perspectives, does your report balk at that, or do they capitalize on that? How do they do it?

When the people beside and below your report answer these questions for you, you’ll start to fill in a more complete picture of the way your report promotes (or prevents) an inclusive work environment. You can capitalize on these examples in your report’s performance review to explain any gaps between their behavior and what you would like or expect to see. That kind of specificity is invaluable for your report as they are planning and executing changes in their behavior to build their skills on your team.

Conclusion

Implicit bias training is fine, but we don’t convey its importance to employees when we don’t evaluate employees on their inclusion literacy. If we want employees to care about inclusion, we need to signal that we care about inclusion by evaluating employees for hiring and promotion based on their inclusion-related skills—exactly the same as we do for their technical skills.

We have five skills here that we can use to build and evaluate inclusion literacy: moderation, solicitation, attribution, most advanced assumption, and capitalizing on alternate perspectives. These skills help an employee make the workplace more inclusive for everyone—not just people from any particular demographic group. This makes the skills equally applicable regardless of team composition, but most importantly, it gives you a way to measure and evaluate someone without calling them racist or sexist—which usually isn’t a productive feedback tactic.

You’ll want to sit down with your team and decide what level you’re looking for in employees, managers, and other leaders for each of these skills. That conversation can help your team solidify its values, bond on a personal level, and develop a stronger, more unified understanding of what inclusion looks like for you.

You’ll want to test for these skills both when interviewing a candidate for hire as well as when considering a current employee for retention or promotion. In either case, the candidate will want to show you their best angle. Where possible, you need to get around that by finding out whether their peers and subordinates feel like they go out of their way to include everyone.

The practices described here might sound funny: indeed, they’re uncommon in tech. But inclusion is also uncommon in tech, so in order to have uncommon success with it, we have to pursue uncommon strategies. We’ll reap the benefits manyfold down the line—and plus, it’s the right thing to do.

If you liked this piece about evaluating employees on inclusion literacy, you might also like:

Why Your Efforts to Fix Your Pipeline Aren’t Fixing Your Pipeline

Anger and Sadness In the Workplace

‘Smart’ is Not a Hiring Criterion