Writing a thread on onboarding here, because I don't want to write it in the other place.

Context:
Good engineer onboarding *is* DEI. Teams that have great onboarding, tend to be more diverse and inclusive. Teams that have poor onboarding, tend to be more homogeneous and less diverse.

That's because poor onboarding makes life harder for junior employees and remote employees. Underrepresented groups benefit disproportionately from remote work options. Junior employees are a more diverse group.

Poor onboarding leads to more "beginner questions" for longer. Underrepresented groups experience higher social threat. So if 3 employees start working at Tech Corp on the same day, and they are:

* A white man
* A white woman
* A Black man

And they all have the same beginner questions 6 months after their start date, then the Black man and white woman are more likely to be perceived as "slow ramp up" people, and face career consequences as a result.

https://xkcd.com/385/

How it Works

xkcd

Imposter syndrome isn't real. Imposter phenomenon is very real.

Imposter phenomenon is the combination of two things:
1) the belief that I know less things than others around me.

2) the belief that if this is found out, that I will experience harm from it.

In short, it's about psychological safety. It's a rational response based on the lived experience of the person feeling it, and their observation of how others are treated, it's not a shortcoming of the person experiencing it.

There are lots of things that we can do to minimize the imposter phenomenon. Better, more consistent, and deterministic ramp up experience, is one of these things. 👍🏿

This doesn't just mean documentation. This also means removing processes that shouldn't exist in the first place.

But in terms of documentation, one thing that really helps, is having a verifiable definition of being ramped up and onboarded.

@mekkaokereke I think two things that can make all difference are (1) to start them with a small project that is "theirs." For an engineer, that would mean not a bug fix, not adding a basic ending to an API, etc. It would look more like adding a small, discrete feature or writing a tool. Something they can finish in a few days but gives them ownership and something they can point to. And (2) give them an onboarding buddy who will be really available to help answer questions or get them unstuck.

@fuzzykb

💯 That's a powerful tool that I've used in the past to combat the imposter phenomenon.

This addresses the "I don't know so many things that other people know!" If a junior SWE becomes the person at the company that knows the most about [feature X], and they see *very* senior SWEs from other teams, come to them and ask them questions, their thinking becomes:

"Yes, they know things that I don't know. Facts. But I know things that they don't know! No one knows it all! This is normal!"