I had heard stories about brutal onboarding processes at high tech companies where basically they throw you in the deep end and see if you can swim or not. They place a really high value on self-sufficiency. About the worst thing you could have a peer say is “sure, let me google that for you.” A real no hand-holding around here approach. Man-up, let’s see whatcha got. It sounded horrible and I hoped I never had to experience it. I came pretty close to missing it, but not quite.

In the 1990’s and 2000’s I managed a team of tools engineers and we had the opposite approach. We trained new hires on the tools and sometimes the class size was 1. We did it anyway. One of the biggest compliments I received (and it was from multiple people over the years) was how much they appreciated the time we took up front to familiarize them with the tools, processes and answer their noob questions. The company (Tektronix) got it. They gave me a $1M budget for my team and said “make sure my developers are happy campers.” They gave me some general direction, enough budget to be successful, and then got out of my way.

So in the twilight of my career I ended up doing a contracting stint at Venmo to be their “interrupts” engineer. I had a good idea I’d be on a short leash most of the day and that was fine, I didn’t mind that part of it as long as there were no on-call expectations. I wondered how the onboarding process would go and was disappointed to learn it was more of a throw ’em in the deep end approach.

Venmo has a rotating shift of on-call Site Reliability Engineers and my outlets for outreach were 1) contact the SRE on-call and 2) Hit up the “SRE Team” Slack channel with my questions.

There were several problems with this. First, there are a ton of things to learn starting out and the Confluence Documentation wasn’t a reliable resource for most of my questions so I didn’t have the ability to self-service the vast majority of them. Second, not all of the on-call rotation engineers were 1) available or 2) very adept at mentoring new-hires. Some were extreme introverts who seemed put out at having to answer my questions. Third, having to ask the volume of questions I had on a daily basis to the team slack channel really sucked. Having to expose one’s ignorance publicly that often is not ideal. And more often than they might care to admit, the response was crickets.

What really saved me was a few people who didn’t seem to mind being bothered with questions that I could reach out to 1/1. I tried not to over-use that chip because I didn’t want to wear out my welcome and burn other teammates out, but I had to find someone.

I can see both sides of the issue. On one hand you don’t want to set the expectation coming in that this is going to be a real hand-holding experience every time you get stumped. The other side of it is, having no help all at leads to high stress, discouragement, and the feeling that this is not a team with good collaboration skills.

So if I were managing teams again I think I’d assign each new hire a single mentor to coach them through the first few weeks. That person would be available for questions or pointers to where they could find the info, but they would be responsible for bringing a new hire up to speed. The mentor could also gage whether too many of the questions were google-able themselves and coach the new hire in that direction too if there wasn’t enough effort going into self research before asking others. But in general, some hand-holding would be available early-on.