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!
The other thing about intentional, verifiable ramp-up plans, is that they make the person ramping up less nervous about their own progress.🤯
Without the plan:
"I've been here 20 days, and I haven't even transported a living thing yet! Not even a Tribble! I was top of my class at Starfleet, and I thought my paper on "Subspace tunneling to safely beam matter through singularities" impressed them! Do they not trust me? Am I messing up in other ways? Is... is it because I'm half Romulan?!"
One other thing we've noticed that makes a huge difference, having a deliberate "Onboarding buddy" someone that the new hire can ask questions. Even better if they're not a manager (less concern about looking dumb).
Not knowing who to ask can be paralyzing for some. Having someone senior they can ask and know they're not bothering, removes lots of barriers. Plus, it's good experience for the senior person.
Did @danhon write this onboarding checklist?
heh, kinda happy that the onboarding template looks an awful lot like this.
I cleaned it up for public use. Not sure if it actually is useful, but yeah, making things easier for anyone to onboard is A HUGE WIN.
https://drive.google.com/file/d/1hWEgOYrH07-t_w-hPOYjEp-ooj1mxogv/view?usp=sharing
(Don't make new folk suffer like you did. They don't need to earn anything. You hired them to help free up your work.)
In the flip side, I offered comments for ours and was met with "we've been doing it this way for 25 years, it's fine" 😂😒
Apologies for a billion notifications -- something about my keyboard went nuts.
Re the "get reading!"... is there a navigation path through the voluminous (right?) docs? A prioritized reading list or something?
@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 
Lauren Weinstein
jr conlin —〰—
jonathanpeterson
Aviva Gary
Alexander Kknli
Jeremy Kahn
Dan Hon
0xC0DEC0DE07EA
Remco van Bree
birdpoof
John Lusk
David Nash
Sasha Göbbels 🐿️