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 Can you provide an example of a "process that shouldn't exist in the first place" ? I don't know what process that would look like?

@francois

@mekkaokereke

Replace "ask Bob for an a/c on the VCS repo" with "just have sso everywhere."

@JuliaRez @francois

This!

The provocative question is:

"Engineers, could a principal engineer from say Microsoft, join your team, and without talking to anyone, just by reading docs, fix a trivial bug in your system?

And push it to production?

On their first day?

Not saying this should always be possible. Just baselining onboarding."

When we think of the reasons why this might be "no," it usually comes down to things like ACLs, permissions, non-documented knowledge, lack of CI/CD, etc.

@mekkaokereke @JuliaRez @francois damn, that’s a great standard to aim for. I’ve been pushing for these kinds of changes at my company (and working on them) but mostly from the cyber security angle of we should have sso and 2fa etc. This angle feels more clear to try and sell to leadership