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.
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.
Welcome Starfleet graduate! You've been assigned to the Transporter team! "Dream to Beam!"
Week 1:
✅ Get desk, comms badge, quarters
✅ Meet your onboarding guide (Scotty)
⬜ Join all team mailing lists
⬜ Take the "Teleportation basics" training
Month 1:
⬜ Complete first pair transport (inanimate objects)
⬜ Complete first solo transport (sentient life forms)
⬜ Join duty rotation (shadow your guide)
Quarter 1:
⬜ Complete first multi-party transport
⬜ Join duty rotation (solo)
⬜ You're onboarded!
@mekkaokereke Part of the reason I left academia years ago is my "onboarding" process for the first few months of my first post-Ph. D. job looked like this:
Week 1:
[X] Get desk, university ID card, keys to the lab, and stuff like that
[X] Start learning in more detail about projects the lab does
Month 1:
[X] Pick a project.
[X] Attend group meetings.
[X] Learn how to use some of the lab's instrumentation.
Quarter 1:
[] Be familiar with all lab instrumentation including the ones with no manuals
[] You’re still asking other people for help with this? Cut it out. You should know how to do all of this by now.
[] Be able to undo previous people's experiments before doing your own, without fscking them up
[] You’re still asking other people how to avoid screwing up their stuff when you set up your work? See above about knowing how to do all that by now.
[] Have enough data on your chosen project to start presenting meaningfully in group meetings
[X] Project not working? Sucks to be you. Find another one to get more data from.
Half-year 1:
[] You have lots and lots of good data, right?
[X] OK, observe your PI kick collaborating prof out of collaboration and saying we're going to go our own way
[X] ...Including managing all the supplies, lab protocols, etc., that the collaborating team was the expert on, not you
Year 1:
[] Start writing first paper.
[] Congratulations, you're onboarded!
[X] Oh, no useful data? Pull trigger on "leave not just job but career and ponder something less stressful, like software development at a small company that wants all things web, right now"
By comparison, onboarding as a software developer/engineer has been much less painful.
mekka okereke 
David Nash