Onboarding Is Hard (part 2)

Bryan Lott published on March 27, 2019

12 min, 2392 words

tl;dr: if you're joining a company, your first n days shouldn't be spent being productive, they should be spent building knowledge and connections so you can be productive.

After reading my last post, I've been stopping and starting the next one for close to a month. The previous one focused pretty hard on what the hiring company can do to onboard a new hire. Which is great and all, but that's only half of the story. The other half is focusing on what the new hire can do to be onboarded as quickly and painlessly as possible.

With that being said, this is potentially more a note to me than to anyone else!

Caveats

First, I'm focusing on a technical/engineering onboarding, mostly because that's my background and what I have experience with. Second, some of the advice may apply, some may not. It all depends on the particular situation you find yourself in. What works for one company or person may not work for the next.

Introverts unite! Separately! In your own homes!

Just a quick note, introversion/extroversion refers to how someone recharges their social energy. Introverts tend to recharge alone, extroverts in the company of others. Shy/outgoing refers to how comfortable someone is in a social situation. In my experience, being shy tends to correlate with being introverted, but it's not always the case so YMMV.

If you're outgoing, fantastic! You'll probably have an easier time integrating yourself into new company culture. The only caution I would provide is to temper your enthusiasm just a little. As a tech worker, you're probably interacting with more shy people than you are outgoing types. More than anything though, just be your friendly communicative self and you'll be just fine.

If you're shy like I am, well, this is gonna be a little rough. No real way to make it any better, it just is. You know those really good friendships you (hopefully!) made at your last company, well, you can do the exact same thing here, but just like that last company, it's going to take some time. Relationships, professional or not, are built over time via communicative trust. What I mean by this is the reason why people start talking about the weather or the company is that it's a safe topic psychologically. Can't just jump in and ask someone what they think about the universe and their place in it. That's a much deeper topic that probes at the depths of the psyche and you need to build trust before you can have those sorts of conversations.

So, what do you do? You reach out, maybe not in large groups as those awesome outgoing people can, but in small groups, within your team, maybe just one on one when you're asking questions. Up your "outgoingness" just a tad and you'll be okay. Don't get me wrong, it'll feel uncomfortable as hell, but you gotta do it and you'll be thankful that you did. It'll turn an environment with a bunch of strangers into one where you just might hang out with the same people for 40+ hours every week. If it helps, chances are the people on your team are just as shy as you are and are struggling just as much with meeting someone new. If you make a little more effort than what's comfortable, you're easing their experience and you'll form work-friendships much faster.

Now, to the introverts (extroverts, you already know what to do, go party!). Whenever you start a new job, make sure you reach out to the people close to you in your life, whether that's your partner, your friends, your therapist, or your family. Let them know what's going on and that you'll probably need a lot more time to recharge than you normally would, but that it's a temporary thing. I guarantee they'll understand. Everyone knows how stressful starting a new job can be and they'll support you.

One final caution, be yourself. If you're pretending to be someone you're not, it'll only backfire in the end and you'll have a much harder time integrating with the culture.

I'll admit, it's very hard going out to lunch with a bunch of new people. Usually, the restaurant is decently loud, it's hard to hear people, etc. There are a few things you can do to make this easier.

First off, the choice of the restaurant will probably be made for you. If you have any dietary restrictions, make sure whoever is making the reservation/choice knows whether you can eat there!

Second, whenever you all go out for food, make sure to walk/ride with someone else. It gives you a brief chance to have time with them beforehand and it'll also give you someone to sit next to that already has spent some time with you.

This next one is uncomfortable as hell, but put yourself in the middle as much as possible. The point of this outing is for the team to meet you, ask questions, and for you to do the same. This is much easier if you're sitting in the middle of the table where you can hear and be heard easily. It also means that you're less likely to be sidelined out of conversations.

If you drink alcohol and people order it, feel free, but only order one. After that switch to soda or water. Why? Sharing alcohol seems to help people form bonds quicker for whatever reason, but you don't want to go overboard. Your goal here isn't to get drunk, it's to make connections. If you don't drink, for whatever reason, order a non-alcoholic "specialty" drink. Think a strawberry lemonade instead of water or soda. Same reason. Most people don't realize it doesn't have alcohol in it and pretty much everyone likes the fancy drinks, whether they want to admit it or not!

Finally, try to ask open-ended questions. These are questions that can't be answered with a single word answer. They lead to a conversation instead of closing a conversation off.

Closed question: "How often do you guys do lunch here?" -> "About every other week." (end of the conversation)
Open question: "This is a great place, what other restaurants are good around here?" -> "Wow, well, there's a, and b, and c." (which naturally leads to more questions and conversation).

Headphones/Tuning Out

Believe me, I love my Bose QC35's more than most. It's sometimes the only way I can focus enough to debug code. But, remember, your job while you're getting up to speed isn't to be productive, debug the hardest problem, or write the cool thing. It's to gather enough knowledge and make personal relationships within the company so that you can do that. Think of this as a sprinter stretching before a race. If you don't stretch, limber up, warm up, you'll only hurt yourself.

If you do find yourself needing some focus time, make sure people know that you're still available. In my case, that means keeping only one headphone on so I can listen to the office around me. It gives the perception that I'm not in do-not-disturb mode. Collaboration is easily more important than deep work in the early days at a company, and some would argue that it's always more important. I'm not sure that I 100% agree with the last bit of that statement, but I wholeheartedly believe the first.

You'll also want to observe the people around you. Do they spend most of their day collaborating, chatting, etc? Or, do they spend their day grumpily downing coffee while jamming to psytrance? Either way, it's very useful information as you acculturate into your new home.

Learning the Tech

This is sometimes the easiest and sometimes the hardest part of coming up to speed at a new place. Sometimes in the same hour! Hopefully, you have a good understanding of the technology being used at your new company even if you may not understand how it's being implemented.

Know what's being used

In theory, this should be pretty easy. The first time you got a taste of this information was in the job posting. If they were looking for an Oracle DBA, there's a good chance they're using an Oracle Database. Make a list of everything they were asking for and figure out why they were asking for that thing.

Once you've got that list, catalog all the primary technology choices you'll be working with on a daily basis. Are there any you are weak on? Great! Focus on learning those every chance you get a free moment, which can be surprisingly often as a company tries to figure out how to use their new investment! The advantage of doing this is you're making their investment seem more attractive every day. You're showing initiative, and you're furthering your own knowledge.

Know how it's being used

This is the more important topic at hand. How is it being used here? The key to getting up to speed on this is usually understanding the history of how it got to now. Not just the facts, but the reasons behind it. Sometimes those reasons are very logical, sometimes it's "because a guy that no longer works here did it that way". Either way, you know more than you did before. If there are logical reasons for it, what assumptions were made that underpin the logic? If it was rando-guy, can you tease out what assumptions he was making that lead him down that path? Are they still valid? Where are the pain points in the current system? Needless to say, your first n days of spending time with the tech is going to generate a lot of questions. Don't be afraid to ask the questions, write down the answers, and create documentation from that information.

Seriously, that's the biggest way you can contribute in your first few days. Writing documentation. It may be imperfect or incomplete but it's probably more documentation than there was before, otherwise, you wouldn't have needed to ask the questions in the first place! Plus, everyone loves it when someone writes documentation, as long as "someone" isn't them. This is an easy way to get a quick win and learn something at the same time.

Do a teach-back of the stack (or at least your portion of it)

If a meeting where you teach back to someone what you've learned about the stack, the technology, etc hasn't been scheduled, put one on the calendar. Preferably with your team lead, manager, or someone who knows your area of the stack really well. This is a fantastic chance to find the holes in your knowledge and get them filled right away. It also reinforces the idea that you're a member of a team and not just a "code in a cave" stereotype.

Make a PR

Pretty simple stuff, once you've pulled down the code, made a branch, and made your first commit, create a work-in-progress PR. This instantly makes your work visible, which can be a very uncomfortable thing, but it also lets people point out issues with what you're writing that you may not have the knowledge to avoid. This also lets you be humble about your knowledge.

Essentially, this is all about shortening the feedback loop. The shorter the feedback loop, the quicker you'll learn and the faster you'll be an effective contributor. No matter how or what someone comments on your code, never take it personally, but especially in your first few months. You are not your code.

Joining On-call

Even if your new company isn't going to have you join the on-call rotation, shadowing someone in your first few months can give you an idea of where the instabilities in the system are and where some of the pain points are. This is invaluable knowledge as it gives you insight into where you can potentially make some nice wins. While making wins shouldn't be a goal into and of itself, it's a great way to keep up your own confidence and start to show the company and your coworkers what a great person they picked!

Before you take your first on-call shift, reach out to your teammates and let them know that you'll try your best but you may need some help. Gather who you should contact if you can't solve a problem and why/when/how to contact that person. Sometimes you can leave an issue until the next day and pair with someone on it but that's not always clear from the incident notification. The best thing you can do is try to triage it. If it's truly a critical issue, wake people up. At worst, it won't actually be a critical issue and there's a flaw in the documentation or notification that's found and corrected. This makes everyone's lives better!

When You're Stuck

So, you're stuck. Do you ask for help or spend time researching/learning it yourself. For me this really boils down to one question:

Is this lack of knowledge something specific to the company or is it a lack of knowledge of something general? I.e., can you google the answer?

For example, "How does your build system kick off this Jenkins job?" is a very different question than "How do I configure Jenkins to push to an EC2 image?" The first one is specific to how the company has configured its build pipeline. The second is more general.

I'd spend a lot more time researching the general question than I would the specific one. If I'm still not making any progress, then I'll start asking around to see if anyone's run into a similar issue. I.e., if you can google the solution, you should probably at least try that first.

Closing Thoughts

No one said meeting a bunch of new people, especially people that can impact your ability to have a job, was easy. In fact, I'm saying it's the complete opposite. It's damn hard. But the thing is, it's worth it and the margin for error is pretty large. You can screw up most of it and still be successful.

So, don't be too hard on yourself. Present yourself as authentically as possible and you'll do just fine :)