Welcome to the Course

The hardest part of leading inclusively isn't the big policy moment, it's the hundred small calls you make in a week: who gets the stretch assignment, whose miss gets a generous read, whose idea gets the airtime. Those calls compound into the culture you actually have, regardless of the one you describe in your skip-level reviews. This course gives you the tools to surface those patterns, interrupt them, and run the conversations that follow.

By the end of this course, you'll be able to:

  • Identify the cognitive biases shaping your hiring, feedback, and delegation calls
  • Audit your people decisions for hidden patterns in airtime, access, and benefit of the doubt
  • Reset team meeting norms so dissent shows up and follow-through sticks
  • Apply structured criteria to make fair, defensible talent decisions
  • Run an inclusion check-in that owns system change without putting the fix on one person
  • Recommend team-level adjustments that improve belonging at scale

This first unit starts where every other move depends on: spotting the biases riding along in decisions you already think you've made on the merits.

Naming the Biases That Run Your Day

Five biases do most of the damage in manager decisions. Affinity bias is the pull toward people who remind you of you, similar background, similar style, similar communication cadence. It usually shows up as "I just click with Jake" when what you mean is "Jake processes ideas the way I do." Confirmation bias is the search for evidence that confirms your first read of someone; once you've called an IC "high potential" in your head, you start noticing every data point that supports it and discounting the ones that don't.

Halo/Horns lets one trait (the polished demo, the missed deadline) color the whole picture. Recency bias lets the last data point dominate; the strong quarter gets overwritten by the rough Friday.

Attribution bias is the asymmetry in how you explain success and failure: when an in-group report ships, it's skill; when an out-group report ships, it's lucky timing or a strong team around them. You won't catch any of these in the moment without a prompt. The point is to recognize the texture, the feeling of "obviously it should be X" is almost always the signal to slow down.

  • Nova: Quick gut check, the client readout slot is open. Jake or Ryan?
  • Victoria: Ryan. He nailed the dashboard demo last week.
  • Nova: And Jake's been steady the whole quarter, right?
  • Victoria: ...yeah. I just gave you a one-week answer to a six-month question.
  • Nova: Worth pulling the whole quarter before you lock it in?

Notice the move. The bias didn't disappear because you named it; it just stopped driving the call.

Auditing the Decision You Already Made

Once you can name biases, you can audit for them. The Bias-Interruption Checklist gives you the structure: Pause, Define criteria, Name assumptions, Seek disconfirming evidence, Broaden input, Document rationale. You can run it before a decision (slow it down) or after (audit it). For this unit, you're running it as an audit.

Point it at three lenses. First, airtime: pull up your last four staff meetings and ask who actually spoke, for how long, and whose points got built on. Second, access: who got the visible projects, the client-facing slots, the exec readouts last quarter? Third, benefit of the doubt: when two reports both missed something, whose miss did you read as "circumstance" and whose as "capability"? When a pattern surfaces, your job is to name the most likely bias behind it with evidence, not to flagellate yourself in the abstract. "Affinity" is a useful label only if you can point to the specific call where it tipped the scale.

The audit fails when it stays general. "I should be more inclusive" is performative. "I gave Ryan the last three client-facing slots because his communication style matches mine, that's affinity, and the cost is that Priya hasn't had a visible moment in two quarters" is usable.

Talking About It With Someone Who Noticed

Here's the part most managers fumble: a direct report books time and tells you they've noticed a pattern. The instinct is to defend ("it's really about bandwidth"), to minimize ("I don't think it's that uneven"), or to over-correct on the spot ("you'll get the next one"). All three rebuild the problem in a new shape. The last one is the worst: handing someone a stretch role as a guilt fix just makes the next round of allocations more political, not less.

What actually works: validate the observation with specifics, share what your own audit surfaced (including the biases you named), and co-create a structural change rather than an individual promise. A rotating exec readout, written stretch-assignment criteria, a quarterly access audit you publish to the team. The fix has to live in the system, not in one person's next opportunity.

The takeaway for this unit is sharp: bias is not a character flaw to confess, it's a decision pattern to interrupt, and the interruption is structural. Three practices sit ahead of you. First, a quick pattern-spotting drill to make sure you can name which bias is driving common hiring, feedback, and delegation moves. Then, a written audit of your own last quarter that your director would actually find credible. Finally, the live conversation, where a direct report has already noticed the pattern and you have to discuss it without flinching or fixing too fast.

Sign up
Join the 1M+ learners on CodeSignal
Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal