On-boarding as a New Remote Engineer
Think about your on-boarding process. I don’t mean the part where HR or an office manager gives out paperwork. I mean the part where the new hire does actual engineering work. Do you have a fellow engineer pairing with the new hire through the process? Do you have a checklist to let the new hire know the scope of on-boarding and when they are finished? Do you ask the new hire to join in on the conversation to continuously improve the on-boarding process afterward? Do you set expectations for the first few weeks? If you didn’t answer positively to all of those questions, your on-boarding process can be improved.
After working for a few different startups over the years, and working in two more completely different industries, I have been through a wide variety of on-boarding processes. Some were intricate. Some were non-existent. But all were about me getting up to speed on my own. I could ask for help with things here and there at each place. However, the general vibe was that you needed to be up to speed as fast as possible for the sake of the company.
The First Day
Things are different at NoRedInk. My on-boarding experience has been less focused on what I personally need to do to get up to speed. It has been more focused on what we do as a whole and how I contribute to this process.
Rather than telling me what to do and seeing if I can do it, the first day was all pairing with another engineer. We ran through the administrative work of setting up accounts for services and credentials together. Doing the administrative work together was great because I had the chance to ask questions about what the different services did. More importantly, we had a chance to discuss why we chose each service and how we generally use them in day to day engineering.
We did actual engineering work next. My pair walked me through the steps of choosing an available issue, style conventions, and how to finish up on github. All of this information is overwhelming to take in on the first day if you are by yourself. To help alleviate some of this cognitive load, we have to talk about one of the most amazing things about being at NoRedInk: wikis!
Wikis!
We have just about everything documented somewhere in a wiki. Imagine your employee handbook but better. There are five main wikis: Engineering, BizOps, Sales, Product, and Non-Technical. If you are curious about how sales does their demos, you can find an entry that details the whole process. If you want to know how content gets created on the site, there is an entry in the Non-Technical wiki. Practically anything you can think of is in a wiki somewhere! But wikis are worthless if the information becomes stagnant. So we constantly update entries and make changes to keep the information current.
Let’s focus on the engineering wiki. The first thing to know is that even though it is an engineering wiki, the information is mostly about process rather than algorithms. Some examples are: “The Best Practices for Discussions”, “The Communication Policy for Email, Github, Slack”, and “The Engineer Onboarding Checklist”. Yep, we keep the checklist of things to do during on-boarding in our wiki! To keep the checklist current, the last item is to update the checklist with any information that might have changed.
Our technical stuff is more like what you would expect in an engineering wiki: best practices for front-end, style guides, domain information. With the information in the wiki and out of the heads of individuals, it is much easier to ensure everyone understands what the process currently is. We also can ensure we are following an up to date process. If we decide to make a slight change to our pull request process, it can happen in the wiki and everyone can be aware of it.
The biggest benefit I get from having so much information written down is being able to understand it at my own pace. There are some familiar bits that I get the first time around. Then there are some unfamiliar bits that I need to read multiple times to really understand. In day to day work, it means that I don’t have to bother someone else when I have a simple question. I can find the information in the wiki and answer my own question. As a remote worker, it is a great feeling to know that you can get most of the information you need at any time.
Remote Culture
The pairing doesn’t stop with on-boarding. Every day that I have been at work, I have paired with someone on something engineering related. About 80% of the time it is technical work, but sometimes we do pair on non-technical work. Pairing can be a quick 15 minute session to work through a bug, or it can be a full 8 hours if you (and your pair) want. I have paired with people in the office and my fellow remote workers.
One of the big issues with working remote is losing the connection with your co-workers. NoRedInk is the most remote friendly place I have worked. Co-located people will often ask remote people if they would like to pair, and vice versa. If a discussion happens in-office that concerns multiple people, it will usually move to email, github, or slack. The purpose is to keep everybody in the loop, whether they are working in-office or remotely.
Much of our engineering process is centered around asynchronous communication. This is a huge win for working remotely! The slack channels are always abuzz with information and ideas. But there are times when a face-to-face call makes more sense than typing. In these cases, we will throw up a quick five minute hangout, fire-up screenhero or even use a regular old telephone. Once we hash out the details, we report back in the channel on what the conclusion is. There’s no sense in forcing asynchronous communication if a synchronous call is more effective. Again, the focus is on communicating effectively and keeping everyone connected.
To make sure the different teams stay connected, we have a weekly team lunch. The in-office folk gather in a hangout with the remote folk and someone presents on a topic. There is a projector in office (as most offices might have) so people don’t have to crowd on a single screen. We have presented on what the engineering team is doing, how the process is changing within the product team, what is going on with sales, and less company related stuff like OSX productivity tips.
We have expanded so much as a team lately that during our weekly lunches the external in-office microphone couldn’t keep up. We had so many people around the lunch table that it was hard for the remote people to hear the conversation. To make audio better for us joining remotely, a second external microphone was bought. We can hear much better now when someone talks at the far end of the table. Little things like adding an additional microphone go a long way to making remote people feel like they are part of the office.
One of Us
There is quite a bit more that is great about working at NoRedInk. Rather than reading more in this blog post, you should come experience it for yourself. We are always looking for great people to join and help us make the team even better. Check out the jobs page to see if something fits. Or if you have tips on where we can improve our process, I’d love to hear about it. Send me a tweet at @st58 with your suggestions.
