Thoughts on Diversity, Inclusion and Belonging — a first rough draft


June 2018 Pride Parade in Kyiv, Ukraine
June 2018 Pride Parade in Kyiv, Ukraine

A 9-hour flight with no entertainment system is the perfect opportunity to put on paper some of my thoughts on a very complex topic.

For the last 2–3 years I’ve been watching the conversations around the topic of diversity unfold. As someone who views “live at let live” as a core principle I’m trying to live by, and social justice as a core value I believe in, I was often surprised by how excluded I felt from engaging on this topic. I feared that the curious/questioning/contrarian approach by which I make sense out of the world around me will be misinterpreted as “just another white dude who doesn’t get it”. But I will learn very little out of fear, so instead, I’d like to offer two ideas on how we might be able to advance the dialogue going forward based on observing and participating in many conversations on this topic over the past few years.

If there’s one thing that I know about my current point-of-view is that it is wrong. In the sense that I’m sure I’ll be embarrassed by its crudeness in a few months/years once I gain a more refined understanding of this topic. But that’s what learning is all about, and creating this snapshot in time will help accelerate the pace of learning.

1. Start with Inclusion rather than Diversity

To explain what that means, I found the following distinction between the terms helpful:

  • Diversity is a state in which multiple perspectives are present
  • Inclusion is a set of behaviors that enable these perspectives to manifest themselves and influence the course of business
  • Belonging is a feeling of being to be your full self as part of a group and be valued for that

While the definitions themselves are far from perfect, the critical distinction is between a state, behavior and feeling.

Many organizations start with diversity, specifically trying to change the mix of individuals that the organization consists of, as measured by a set of agreed-upon categories (gender, ethnicity, etc.) with the aim of eliminating, or at least reducing under-representation. At first glance, it seems like a compelling strategy because measuring progress seems easy (we’ll discuss a big caveat here later) and the change that’s required seems rather mechanical: tweak the recruiting process to reduce bias. And yet, even
organizations that have been at it for years now, struggle to deliver meaningful results, and for some of the ones who do, results seem to be short-lived.

Inclusion is a harder goal to start with, but one that is more likely to yield long-lasting results. The distinction at the beginning of this section helps explain the benefits of this approach:

  1. Focusing on changing the composition prevents us from doing more with the diversity that we already have in the existing members of our organization. This is important because diversity does not automatically translate to inclusion and belonging. Which leads to the 2nd point:
  2. Part of the challenge with obtaining long-lasting diversity results stems from the lack of inclusion. We can bring diversity in. But if these members don’t end up feeling like they belong — they will leave. By focusing
    on inclusive behaviors first, we may get improved diversity, almost as a by-product.

2. Re-frame the conversation: from “us vs. them” to “all of us”

Much of the dialogue today is centered around specific identity attributes (gender, sexual orientation, ethnicity). In addition to being incredibly reductionist in describing what makes us us, it forces us to have this conversation using an “us vs. them” language: minorities vs. majority, whites vs. non-whites, men vs. women, straight vs. gay, etc. It creates a false pretense that progress for one must come at the expense of the other and it alienates many in the “them” camp rather than enlists them in committing to the difficult behavior change that’s needed.

We’re more likely to achieve the outcome that we seek by focusing on what we have in common rather than on what sets us apart. So instead, we can shift the conversation to focus on the need to belong as a universal need. Regardless of how each of us self-identifies.

A little over a year ago, CultureAmp and Paradigm designed a Diversity, Inclusion and Belonging survey that we can glean some interesting
insights from. Even though the survey is no longer available on the CultureAmp website, it can be accessed using the WayBack machine here (hardly anything on the internet truly disappears)

The survey is organized around 7 dimensions: belonging, decisions, diversity, fairness, purpose, resources and voice; with 2–4 statements pertaining to each:

Belonging:

  • I can be my authentic self at work
  • Even when something bad happens, I don’t question whether or not I belong at my company
  • I feel respected at my company
  • I feel like I belong at my company

Decisions: 

  • I am included in decisions that affect my work
  • Perspectives like mine are included in the decision making at my company
  • I am satisfied with how decisions are made at my company

Diversity:

  • My company values diversity
  • My company builds teams that are diverse

Fairness:

  • I believe that my total compensation is fair, relative to similar roles at my company
  • My job performance is evaluated fairly
  • People from all backgrounds have equal opportunity to succeed at my company
  • Administrative tasks that don’t have a specific owner are fairly divided at my company

Purpose:

  • I understand how my work contributes to my company’s mission
  • The work that we do at my company is important

Resources:

  • When there are career opportunities at my company I am aware of them
  • I know where to find information to do my job well
  • My company believes that people can always greatly change their talents and abilities
  • My company enables me to balance work and personal life

Voice:

  • When I speak up, my opinion is valued
  • I can voice a contrary opinion without fear of negative consequences
  • At my company, there is open and honest two-way communication

I have some minor qualms with the relevance and phrasing of some of the statements but I find the overall dimensions to be rather compelling and comprehensive.

A few observations on the universality of these statements looking at the survey design and results:

  1.  They use an “all of us” language that makes it a lot easier to rally behind working collectively to improve them in the organization
  2. Some of the lowest rated statements are issues for EVERYONE. Awareness of career opportunities is a good example
  3. The differences across statements are significantly larger than the differences within statements (at least when sliced by gender). There’s a 55% difference between the highest and lowest rated statement, and only a 15% difference between men and women on the most polarizing statement.

Would these two ideas solve the challenge of making progress on diversity, inclusion and belonging? I think that’s rather unlikely. But I believe they might allow us to advance the conversation that will lead to the progress we all seek.

Advertisements
Thoughts on Diversity, Inclusion and Belonging — a first rough draft

Tribalism and Intractable Conflicts [Ripley et al]

Like many, I’ve been closely watching what seems to be like a growing divide in US culture, which has been growing at an accelerated pace since the 2016 Presidential Election.

I’ve been meaning to write a post about it, because it’s a topic that permeates the membrane-like boundaries between organizations and “the rest of society”, and I believe that organizations, and specifically the dialogue that takes place inside organizations, can be a big force for good tackling these loaded topics.

The first insight in unpacking this topic was using the term “tribalism” to emphasize with and describe the behavior that all parties seem to exhibit. Simply put, it refers to engaging in the dialogue with a deeply entrenched “us vs. them” mentality. Listening to the other side’s arguments and experiences, looking for flaws in their logic and reasons for why your point of view is right. And letting your confirmation bias run wild, rather than evaluate new information based on fact and logic.

The first two essays that I read on this topic in late 2017, “The Dying Art of Disagreement” by Bret Stephens, and “Can our Democracy Survive Tribalism?” by Andrew Sullivan, painted a beautiful, balanced and depressing picture of the core role that tribalism plays in the current state of affairs.

I first considered writing this post after reading these but stopped short because while they paint a very nuanced picture of the current situation, they haven’t done much in terms of clarifying what the path forward should look like.

More recently, I read “Tribal World” by Amy Chua which provides a more historical perspective on major international affairs and US political events through the lens of tribalism. Chua argues that:

In seeking to explain global politics, U.S. analysts and policymakers usually focus on the role of ideology and economics and tend to see nation-states as the most important units of organization. In doing so, they underestimate the role that group identification plays in shaping human behavior. They also overlook the fact that, in many places, the identities that matter most — the ones people will lay down their lives for — are not national but ethnic, regional, religious, sectarian, or clan-based. A recurring failure to grasp this truth has contributed to some of the worst debacles of U.S. foreign policy in the past 50 years: most obviously in Afghanistan and Iraq, but also in Vietnam.

While I hoped that she’d continue this arc and offer some advice on how to better integrate the acknowledgment that tribalism exists into future policy-making, her parting thoughts focused instead ways to reduce tribalism through increasing economic stability and upward mobility. Hopeful, but not very actionable. The biggest insight for me was starting to view tribalism not as something to be eliminated but as something to be acknowledged and design for when considering interventions. The reason-based, see-the-other-side interventions fail to do that. And understanding that is actually progress 🙂

Luckily, my next discovery was a seminal piece called “Complicating the Narratives” by Amanda Ripley. Of all the pieces referenced here, this is the one I’d encourage you most to read. Ripley looks at the role that media and journalism have played in amplifying the tribal dynamics but she also boldly goes where no one had gone before: ascribing some key counter-intuitive guidelines for how journalists (and others) can help improve the dialogue going forward.

Ripley’s piece draws from many sources, but most heavily from the work of Peter Coleman (which is now on my reading queue…). Coleman’s research focused on “Intractable Conflicts” which he defines as:

[conflicts that] are intense, deadlocked, and resistant to de-escalation or resolution. They tend to persist over time, with alternating periods of greater and lesser intensity. Intractable conflicts come to focus on needs or values that are of fundamental importance to the parties. The conflict pervades all aspects of the parties’ lives, and they see no way to end it short of utterly destroying the other side. Each party’s dominant motive is to harm the other. Such conflicts resist common resolution techniques, such as negotiation, mediation, or diplomacy.

As someone who grew up in Israel until my late 20s, that definition deeply resonated. Not just for the obvious example of the Israeli-Palestinian conflict, but also for some of the less globally known conflicts within Israeli society such as the one around the relationship between state and religion.

Building on the work of Coleman and others, the gist of Ripley’s counter-intuitive advice is the following:

The lesson for journalists (or anyone) working amidst intractable conflict: complicate the narrative. First, complexity leads to a fuller, more accurate story. Secondly, it boosts the odds that your work will matter — particularly if it is about a polarizing issue. When people encounter complexity, they become more curious and less closed off to new information. They listen, in other words.

Ripley breaks down this advice into 6 distinct strategies, which she covers in detail in the piece:

  1. Amplify contradictions
  2. Widen the lens
  3. Ask questions that get to people’s motivations
  4. Listen more, and better
  5. Expose people to the other tribe
  6. Counter confirmation bias (carefully)

I am confident that it’s one of the pieces that I’ll find myself reading over and over again, discovering new insights every time I do so.

Tribalism and Intractable Conflicts [Ripley et al]

Live in Greatness protocols [McCarthy]

Human interaction is hardly ever easy, and often times just a bit of pre-defined structure can go along way in helping us get our needs met.

Almost a decade ago Jim and Michele McCarthy developed a set of such structures, which they branded as:

The Core Protocols

The core protocols are a set of conversations structures, or scaffolding, aimed at helping us get on the right foot in having some of the most important and frequent personal interactions in our teams:

  • Check in (begin meetings)
  • Check out (end meetings)
  • Pass (declining to participate in something)
  • Ask for help
  • Protocol check
  • Intention check
  • Decider
  • Resolution
  • Perfection game (iterating on a proposal/idea)
  • Personal alignment (self-reflection)
  • Investigate (understanding someone else’s behavior)

They are incredibly helpful starting points for some of our most common interactions.

Live in Greatness protocols [McCarthy]

In-context technical interviews

Last week I recapped Dave Snowden’s somewhat abstract “7 principles” of knowledge management, hinting that they may have some valuable applicability for recruiting interviews in particular. This week, I want to further flesh out this idea.

The whole purpose of recruiting interviews is to enable candidates to demonstrate the relevant skills and knowledge relevant to the role that they’re interviewing for. Yet the default mode in which many interviews are conducted in is an out-of-context one: discussing a hypothetical problem, that the candidate has never encountered before, in the abstract or in a way that’s very difficult than the way they’d tackle it on the job. This approach is particularly pervasive in technical interviews and much has been written on their adversarial nature and various other challenges.

So what would an in-context technical interview experience look like? 

The first hint comes from Lou Adler (whose book I covered at length here) who recommends using an interview structure he calls “anchor and visualize”, at a high-level it’s a 2-questions interview where the first question focuses on work that the candidate had already done, and the second question focuses on a hypothetical future looking question. Both questions can then be explored further and elaborated upon using a set of follow-up questions (“SMARTe”). Looked at through the lens of staying in context, it’s easy to see why the first question is a good starting point — it is keeping candidates “in context” by asking them to talk about work they’ve already done. The second question, if applied verbatim, still suffers from being out-of-context. But if we take its intent, of seeing how the candidate deals with a new situation, and try to accomplish the same result by adding complexity/modifying some of the details of the initial situation — now we have something interesting in our hands!

The second hint comes from the folks at Stripe, who knowingly or not, sketched out a technical interviewing experience that’s mostly in-context, and best captured in this Quora post. In Stripe’s interview day no coding is done on a whiteboard. The various assignments are done on the candidate’s laptop in their own environment (again, staying in context).

Based on those two things I’d propose the following for an almost-fully in-context technical interview experience:

Take-home assignment: consisting of two parts:

  1. A short coding exercise in which the candidate needs to create working code from scratch — laying the groundwork for assessing the candidate’s design and implementation skills.
  2. A non-coding exercise asking a few comprehension questions based on a larger, existing code-base — laying the groundwork for exercises that will require a bigger code-base, enabling the candidate to become familiar with it (stay in-context) without creating an unreasonably long assignment that’d require them to write it on their own.

On-site: 

Candidates should be using their own laptops and environments throughout the day. I like Stipe’s overall structure for the day as a strong starting point that can then be modified/adapted to fit the unique needs of the company or the role:

  1. Design and implementation (90–120mins) — starting with a code review of the first part of the take-home assignment. Going deeper and adding complications and modifications from there.
  2. Bug squashing (45–60mins) — the code-base shared in the 2nd part of the take-home assignment should contain a failed test. In this session, the candidate will be asked to find the bug and fix it.
  3. Refactoring (45–60mins) — the code-base shared in the 2nd part of the take-home assignment should contain a poorly implemented section. In this session, the candidate will be asked to refactor that section.

There is one important caveat, captured in the Stripe Quora post and is worth mentioning here: There are some aspects of working out-of-context that are expected as part of the job. For example, developers are often required to maintain/support/interact with code they haven’t written themselves. I can see why some companies may choose to take a more extreme approach than using the 2nd part of the take-home assignment to assess that and will want to introduce a never-seen-before code into the interview day. I think that’s ok, but my advice would be to keep it to the one interview that’s focused on evaluating that skill and keep the rest of the day as in-context as possible.

We have a long way to go as an industry to get to this ideal, present company included, but losing out on good engineers is a luxury none of us should be willing to afford.

In-context technical interviews

Rendering Knowledge [Snowden]

I’ve been thinking a lot about knowledge and context recently. Specifically, when it comes to job interviews. We’re trying to create an experience that enables candidates to demonstrate their knowledge and therefore their fit for a certain role. And yet, it is easier said than done.

I first came across this issue, watching a talk by Jabe Bloom. In the five years since it was given, I must have watched it close to a dozen times, which is extremely unusual in my case. It’s probably one of the most knowledge-packed talks that I’ve ever watched and I’m still unpacking bits and pieces of it.

In his talk, Jabe references Dave Snowden’s work around knowledge management, which I was able to trace back to this short post that’s now a decade old:

Rendering Knowledge

Based on a more detailed paper, which I wasn’t able to find (yet), Dave lays out his 7 principles of knowledge management:

  1. Knowledge can only be volunteered it cannot be conscripted
  2. We only know what we know when we need to know it
  3. In the context of real need few people will withhold their knowledge
  4. Everything is fragmented
  5. Tolerated failure imprints learning better than success 
  6. The way we know things is not the way we report we know things
  7. We always know more than we can say, and we will always say more than we can write down

See more detailed descriptions in the original piece, but I find these to be quite profound. #2 and #7 are particularly interesting in the context of interviews…

Rendering Knowledge [Snowden]

Deciding how to decide


Decision-making was and will likely continue to be a major challenge in every collaborative effort.

A big complication that often gets in the way of making good decisions is deciding how to decide. Meaning, what decision-making process one should follow. Deciding how to decide is difficult because there is no one-size-fits-all decision-making process. Picking the right one depends on the situation.

It’s a topic that I’ve been grappling with for quite a while and shared some interim insights and structures here:

It’s always fun to be able to document how my thinking is evolving and the trigger to actually putting pen to paper on this one was a good post by the folks at Coinbase:

However, the real breakthrough in my thinking was due to a cool micro-site that was put together by the folks at NOBL called “How Do We Decide”. In it, they’ve identified 8 different types of decision-making processes and about a dozen situational factors that will lead you to favor one type over the other.

Source: howdowedecide.com

Overwhelmed by the number of different processes and potential situational permutations, I tried to come up with a simpler heuristic to match a certain situation to its optimal decision-making process.

As part of my search, I decided to re-read a McKinsey whitepaper I came across a while back called “Untangling Your Organization’s Decision-Making”. While their suggested set of decision-making processes didn’t quite land with me, the taxonomy they’ve used to classify the various types of situations rang true:

Source: McKinsey

Which led me to my big a-ha moment:

Decision-making processes consist of two core stages (and a few additional ones at the beginning and end): 

  1. Identifying and exploring various options
  2. Making the decision (choosing between the options) 

The optimal process for each of the core stages depends on different attributes of the situation at hand

At the end of the day, decision-making processes differ from one another in how collaborative they are. Other attributes of the process, such as the speed in which the decision gets made or the amount of buy-in that’s achieved are a byproduct of that.

Finding the right decision-making process seems tricky when we force ourselves to couple the level of collaboration in both of the core stages. Since the optimal process is driven by different attributes, a certain level of collaboration may be a good fit for one stage but not the other. We can be more collaborative in identifying and exploring options, and less collaborative in making the decision (the “consult” option in my original post), do exactly the opposite, or be just as collaborative in both, depending on the situation.

The less familiar we are with the situation, the more collaborative we should be in identifying and exploring options

To assess our level of familiarity we should ask ourselves:

  1. Is this a decision that we’re making frequently? (more frequent = more familiar)
  2. How clear are the options? (clearer = more familiar)
  3. How available is the information required for identifying/exploring the options? (more available = more familiar)
  4. How distributed is the expertise required for identifying/exploring the options? (less distributed = more familiar)

The higher the impact of the outcome, the more collaborative we should be in making the decision

I’m hoping to improve this part of the framework, but for the time being, to assess the level of impact we should ask ourselves:

  1. What would be the breadth of the outcome? (more people impact = more impact)
  2. What would be the depth of the outcome? (more profound impact = more impact)
  3. How reversible would the outcome be? (less reversible = more impact)

As the impact increases, we should opt for a more collaborative decision-making process: from a single decision-maker, through consent and democratic, to consensus.


I found applying different levels of collaboration to the two stages extremely liberating. It provides me with a more nuanced way to tailor the decision-making process to the situation and a stronger sense of certainty that I’m using a process that fits the situation. However, it’s by no means a silver bullet. The challenge is and will continue to be in assessing the levels of familiarity and impact and picking the appropriate transition points from one process to the other.

Deciding how to decide

The XY Problem [Chen]

Distinctions are a powerful concept. Labeling a pattern makes it easier to identify it and respond to it. And that’s exactly what Lily Chen did for me with

The most common problem I’ve seen in product/engineering process

In this short piece, Lily gave a label to a common pattern that I’ve seen time and time again, in much broader scope than the product development one that Lily’s piece is focused on.

The XY Problem — is asking about your attempted solution rather than the actual problem. You are trying to solve problem X, and you think solution Y would work, but instead of asking about X when you run into trouble, you ask aboutY

The best way to avoid the XY Problem, other than simply being aware of it, is to get into a habit of asking “why”. As Lily suggests, “behind every what there’s a why”. In any problem-solving collaboration, don’t start looking for solutions before you’ve moved from the default starting spot in the What Stack an everyone understands at least a couple of “whys” up the stack.

The XY Problem [Chen]