Transparency, diversity, and psychological safety

This hadn’t been the post I planned next, but I’m preoccupied with current political & social upheaval. So: today I’m posting about the leverage companies have to both improve their developer teams and society as a whole.

I’ll just lay out my current mental model — if this is useful to you, excellent. If you see flaws or can offer refinements, even better. Note on context: I’ve only ever worked in smallish companies; some dynamics change in larger orgs.

My basic thesis:

• By default, most developer teams will tend towards poor diversity & biased people decisions, even with effort to do better — and even if they are (somehow) bias-free, it will still LOOK like there’s a problem. That sabotages the team image for potential hires (plus you simply lose out on the well-studied benefits of a diverse team).
• Once a startup has grown into a medium-sized company that took the default, not-great path, it’s expensive & difficult to correct the trajectory.
• But the crucial corrections will make any team more effective; so even if you feel that a startup can’t spare focus to work on diversity, keep reading.

Super-short, skip-to-the-ending version of a better approach:

1. Convert your processes to be concrete, transparent & data-driven
2. Share them (internally, then publicly)
3. Result: you’ll drive both real diversity, equity & inclusion
4. …and take huge steps to foster team psychological safety

More details & specific guidance: read on.

Wait — why would our people decisions be biased by default?

We all grow up in societies with deep biases built in… plus our brains simply take shortcuts that will always trip us up, even if negative stereotypes & discrimination vanished tomorrow. Discussions on this topic seem to derail into politics, but I can offer two quick comments:

• I’ve been reading “It’s the Manager”, by Jim Clifton & Jim Harter. The book focuses on much more than this subject, but their discussion of bias is solidly factual & practical.
• Personally, I’ve acknowledged enough flaws & blind spots in my thinking & instincts over the years that it’s hard to pretend there aren’t always more to find (…it can’t hurt that I married someone who’s brown, outspoken & extremely articulate).

And… bias affecting our decisions isn’t the only thing making it difficult to build a diverse team:

• The best hiring is via referral; this is really true! Most people’s professional networks are not very diverse, though, so this works against a diverse team.
• There’s a pipeline problem for software engineers, especially experienced ones. A startup often needs a core of mid-level / senior devs at the heart of a new team. All of the women & minorities who abandoned frustrating software careers vanish from the pool of experienced candidates.
• There’s a social support problem: it’s cheaper (short-term) for a company to skip/lose team members who need more flexibility or support — developers with disabilities; developers caring for children or elderly family members… or to e.g. offer minimal paternity leave (even though this forcibly blocks fathers from doing their share of parenting)
• You advertise in a style that appeals to you, aiming to attract serious, skilled devs, on the hiring platforms you’re familiar with. This works against you — your pitch will attract people like you, and you’ll remain unaware of how other groups interpret it. Sure, you know enough to avoid listing beer pong competition Fridays and booth babes in your benefits, but still, you will be making mistakes.

All of these factors mean that: until you have a diverse group (who can be involved in your processes & choices, plus prove to applicants that you’re not just “greenwashing” diversity), you will, by default and even with no ill intention of your own, reduce the diversity of your team over time. I’ve done this myself, even while wondering with frustration what I was doing wrong, and actively trying to fix problems.

Let’s invert our problem, and work backwards from the goal.

What does a equitable team look like?

It’s one where any two people with equal skills & qualifications for the work will get an equivalent offering of a career in the company. They should have similar confidence that their application process will be the alike, and they will be judged the same; that they’ll get the same salary & role offer, same feedback, guidance, mentoring & support (including extra support to offset e.g. a disability or being a parent), access to the same promotions for the same growth, & same exit pathways.

This is not as easy as you might think.

Imagine you’re applying for a junior developer role.

You’re white, male, heterosexual, able-bodied & 22 years old. (As usual. Or: surprise!)

You look at the job spec, and the hiring process (what hints you can find), and once you’ve applied and been invited to interview, you see who’ll interview you. And you look at the company – the dev team is mostly guys like you, the senior devs & team leads are, likewise (but a bit older), and there aren’t obvious bad signs, either: it’s not all white men, the company meet-up photos don’t include drunken revelry, the interviewer seemed fairly nice & said some good things about on-boarding & mentoring; and one of the team leads went to your school! Great; that’ll help you get to know people.

You can conclude: there may be some irritating managers or whatever, but generally, if you present yourself well in the interview (better than enough other applicants), you’ll be hired; if you work hard, you’ll be taken seriously and advance accordingly; and as the company grows (and you do the same), it’s straightforward to see working here as a good choice for your career.

That sums up this team’s career offering to you.

Now press the magic button again, and pop! You are (pick a few): not white / not male / not cisgendered / not heterosexual / not able-bodied / not free from child or parent-care responsibilities / not 22 (maybe not even 42), though your skills and relevant experience are exactly the same as they were above.

Is the team’s offering still the same? Not even close.

Even though the company says it runs a fair, merit-based team, unless you’re unusually naïve, you see the red flags waving:

• No one (or nearly no one) like you has thus far succeeded in being hired & promoted in this team.
• It’s safe to assume that decisions about you & your career will be made in secret, using an mostly unknown (likely largely instinct-based) process, which means choices will reflect managers’ biases.
• The specific people in this team, statistically-speaking, do have biases that are likely to harm your career & experience of work.

You cross your fingers and apply anyway! As before, the interviewers & managers are fairly nice, though possibly a bit… uncomfortable with you, and mentoring sounds useful …but will you get the same mentoring as another new joiner who “looks” like a rising star more than you do?

So there’s some distance in the interviews, but you get an offer, and you worry if it’s the same salary as the other juniors, but how can you check? You can’t. You just worry.

When you start, it’s awkward that you’re the only person like you, and one of the other junior devs seems to have become instant friends with the team lead — same university, or something like that. You do not become instant friends with anyone, though another team member seems inclined to ask you awkward personal questions. There’s a gaming group meeting after work, but you won’t be free then, so you won’t be joining. Is your manager getting concerned that you’re sadly not a great fit, here? Maybe; but there’s little you can do (try to smile more?), even if they do bring this up in an awkward conversation. You’re welcome to worry about it.

A team that’s just as welcoming as our first example, to everyone, is simply not possible, because your peers, managers, leaders, etc. can’t be majority more than one group. There’s no way a range of diverse candidates can all apply and confidently say “most people already here are a lot like me, they think like me, and I can rely on them to evaluate me well.”

A better ideal looks more like this:

1. The team and company are already diverse, both team members, managers & leaders
2. An applicant can see plenty of evidence that the team is navigating diversity & inclusion successfully, people decisions are made equitably, and that the company is committed to supporting everyone & avoiding the usual bias traps.

Okay; now how can we get there?

One option is to just try (…hope) to hire in diversity, and tell people to respectfully figure it out as they go.

There’s a fundamental flaw with “respectfully figure it out as you go”, though.

“Assume good intentions” vs. “trust but verify”

It’s common advice: ask employees to “assume good intentions” when they’re concerned about possible bias or discrimination. This sounds fine, until you imagine navigating a conversation with your new boss, starting with “I’m sure it’s not intentional, but I’ve seen some signs that you are treating me differently just because I’m ____”… while hiding feelings of frustration & anger.

How likely is it, that your crucial relationship with your boss will survive this encounter intact?

The expression “trust but verify” captures the need better. For a team member to really be able to trust in good intentions, they need enough transparency to verify the decisions about them, without any need to upset anyone by asking awkward and delicate questions.

Here, also, lies the difference between effective change and “diversity greenwashing” — which costs real time & effort, but accomplishes only (maybe) good PR.

To be transparent, you need to build processes that are data-driven and actually written out. This isn’t instant, but it’s also not necessary (or wise) to sit someone down for 2 weeks to write out an exhaustive manual.

Rework your decisions in a loop

For the processes I’ve worked on in the past, iterating is more effective than attempting to get anything right the first (or second, or third) time through.

Let’s say you have a vaguely-defined, ad-hoc decision process for hiring decisions — “the 3 of us will interview her; you both focus on technical topics, I’ll try to cover culture fit & overall attitude, and we’ll all vote yes or no at the end”).

• Attempt to write down the factors you are considering (e.g. a list of 5 factors you’ll weigh) — how do you expect this person to work and communicate during a normal workday? What are the best signs you can get that they’ll do it well?
• Use your new (simple) process & evaluation criteria
• But also watch how the process works; take notes. What were you still unsure about, at the end? Did you notice something your assessment didn’t capture, but should have? Are there criteria that actually aren’t so important? Did you get a positive/negative gut feeling that doesn’t match the process output? Talk it through, and update the process.
• Go back and apply the updated criteria to previous candidates (if you can) — plus re-review when you have more data (e.g. 6 months of hiring with our new process: how effective is it? How good are the people we selected?)

If you have a vague feeling that doesn’t match the process results, but you really can’t explain where it’s coming from — ignore it. Best case, you’ll see that negative feeling vanish as you get to know the person better. Worst case, if that hire doesn’t work out, you’ll have much better data about how they didn’t work out, and that’s far more useful for correcting your process.

Once you’ve looped a couple of times, your process will stabilize, and you can share it (internally, then publicly).

Are you familiar with Daniel Kahnemann’s “Fast & Slow Thinking”? He documents two systems of thinking — simple people decisions mix both systems. My goal here is to convert these to System 2 — slow, logical, calculated — and expose them to both self-eval (“it’s what I felt… but after I wrote it down, I realized I wasn’t applying this rule to anyone else”), and also to review by the people involved, to quickly find gaps & correct them.

Before I move on, a few links to go further:

• The #KnowYourData campaign
• Smart analytics, AI & support for inclusive people ops:
  • https://www.pipelineequity.com/
  • https://www.gapsquare.com/
• Low-bias hiring, leveraging beapplied.com

How does management transparency make the team & company more effective?

Fostering psychological safety on the team is the single most important factor in its efficacy.

Making these decisions transparent helps in two major ways:

1. This is a profound way for a manager or leader to model the elements of psychological safety, personally.

• Taking interpersonal risks: yep, you have to trust that your team won’t attack you if there’s a flaw in the process you’re sharing — they will help you improve it.
• Embracing curiosity: are any gaps or blind spots in the process you’re using, and how you’re applying it? Show your work, and find out.
• Adapting your ideas to reality (not trying to force reality to match your ideas): your processes will definitely need to be refined as you figure out how team members provide value in different ways. Do this work openly so that everyone learns & shares their insights as you go.

It definitely feels unsafe to share the details of management decisions. That’s exactly right; it feels just like this when a junior programmer asks for code review on their first major attempted code change. “Have I made some glaring, obvious error? Will the others tell me to throw it out and start again? Will they think I’m a fake?”

The solution is exactly the same for a manager with similar doubts.

Take this risk, be open about possible mistakes, fix them immediately (when they happen), and build a trusting, trustworthy team. This is exactly what psychological safety enables.

It’s powerful to admit, at the start, that you’re working with limited input. E.g. in an evaluation: explain what you’ve reviewed, what you’ve seen, and then check if there is more you should know before you move forward.

If you just present a final decision, it’s much more awkward to find out that you’ve overlooked something important… if you are collaborating to build an accurate view, then it’s normal to miss something, you can fill in the gaps together, and there’s little backtracking.

2. Team members know their pathway to flourish in the team (and company) is not primarily “make sure my manager likes me”

A good relationship remains valuable, of course, but only because it helps them to work effectively in the team, and meet the actual, known goals to advance to the next level in their career. If they are having trouble building a good working relationship with their manager, it’s now also easy to point to how they are meeting their goals, just running into a personality mismatch.

Wrapping up

This is only part of a broad discussion:

• Will people take advantage of “known” evaluation processes to cheat?
• What happens if we publish a process with embarrassing oversights?
• What if team members are angry & upset when they realize how they’re being evaluated?

Actually, these first questions are easy: yes, transparency may expose crucial flaws in your processes. Fix them and move on. In a secret process, you’d keep those flaws.

Harder questions:

• If some team members want to advance faster & contribute more by e.g. working 70+ hour weeks… should we let them?
• For an individual contributor, it’s not so hard to support e.g. part-time work for a parent of young children. But can someone advance in management while working flexible and/or reduced hours?
• How much effort & money does real equity & inclusion involve? Should each company be fully responsible for social good costs (like long parental leave when a baby is born or adopted), or should government cover the difference?

Feel free to share your insights on Twitter. 😊