Alexandra Sunderland – How To Successfully Onboard Engineers

I'm thrilled to welcome Alexandra Sunderland, Engineering Manager at Fellow. This session is entitled How to Successfully Onboard Engineers. Whether you're a manager, a lead or developer eager to help out, you'll learn how to create your own exceptional onboarding process and hear about Alexandra's onboarding failures and eventual success.

Alexandra, thanks so much for joining us. Take it away. Hi everyone, thanks for joining my talk today about onboarding engineers onto your team.

I'm excited that I get to talk about this with you today, because even with the world being what it is right now, people are still starting new jobs and a lot of those people are starting them remotely when that wasn't necessarily what they or their teams were expecting. It's not always easy to translate in person onboarding process into a remote one or even easy to create one from scratch but onboarding is such an important part of bringing in a new team member so I wanted to tell you today about how we fill our process at Fellow and give you some tips on how you can create your own tool. I'm Alexandra Sunderland, and I've been working as an engineer for almost the last decade, and right now I'm an engineering manager at Fellow, which is based in Ottawa, in Canada.

I've spent a lot of time putting together onboarding processes and helping engineers get set up on new teams throughout my career. I created the onboarding process at Fellow, and before that I was at SurveyMonkey, where I was a coordinator for the internship program, where I built processes to onboard students and also help teams create their own onboarding processes too. I've been working in this hybrid remote set up for the last four years and actually my first day of being full time, the office was supposed to be a week after the whole city transitions to work from home back in March.

So kind of too bad but I have all this experience from working remote and also in this hybrid situation and now and also from working in person. So this is definitely help me with setting up a lot of processes to be inclusive of different situations. Onboarding is crucial to a team's long term success because it sets the stage for your team and demonstrates what the real values are, if you don't focus on actively showing things like clear communication, onboarding, which is very important, it's a lot less likely that after getting caught up to speed, everyone is going to magically start communicating efficiently to creating a good onboarding process, really make sure that people feel that they have psychological safety.

And it goes a long way towards being able to quickly scale up a team where everyone can trust each other, everyone can be vulnerable and everyone can feel OK helping. Everyone can feel OK, asking for help and learning. I've always had a particular empathy for people starting a new job, and I think it's because of how absolutely lost I felt when I started my first programming job, when I was really young, I got super lucky and I got an internship over the summer before starting university, a local startup.

And I pretty much only knew Visual Basic and some Java. So the stuff they teach you in school and I had never heard of Web programming. I didn't even know you could have Web apps as a business because this was back when you download the software you wanted to use.

So long story short, I spent weeks Googling things like what is an API, what is a Web hook, what is a request, what is a server and how do you log in to server and all this stuff? Because I had no idea what I was doing. I did not know who to ask and it felt like I was kind of assumed it felt like it was assumed that I was supposed to have all the answers already.

There is no onboarding process, so I felt kind of lost in that experience, really always stuck with me. It was the best learning experience I've ever had out of any of my summers. I learnt a ton that's not scalable when you're trying to build a whole team out.

Since then, I've helped on board a lot of people and a lot of different ways, and I've also screwed up in the process. The first time I onboarded someone, I walked them through the entire code base, which was thousands and thousands of lines of code. And I explained every single little bit of code to them without providing any context on what the application did, who was using it, why it was built and all this stuff.

And it was awful because they had no idea how to go about answering their own questions and there was no way for them to remember everything that I said. I also taught a class for a specific technology and my last job for all new incoming engineers, but only a handful of them ever needed to use it. And it ended up being a very boring waste of time for everyone.

I've also done things like assumed people know way more about the organization than they do. So I've accidentally had someone believe for a whole week I was their manager when I was not their manager. So I've made a lot of mistakes.

But that also means that I learned a ton and adapted from those. And every single time I make mistakes, the process gets a lot better. Now it's important to go into onboarding, assuming that the person you've hired has skills and the abilities to perform the job they were hired to do.

It doesn't yet have any of the contacts necessary. So eventually, after making a lot more mistakes with a lot more people, I narrowed down a framework for onboarding people that we now use at Fellow and about half the company has been through. The process together over time as we've collected feedback and this framework is what I would like to share with you today so that you can also create your own onboarding process to help get engineers on your team up to speed quickly and effectively.

Before we get started, it's important to frame everything you do and every process that you set up through the eyes of the new hire. So think back to when you first started and all the questions that you had and the difficulties you encountered. And remember that when they start, they likely won't know anyone or any of the internal process or traditions and will probably be feeling a little bit out of place when they try to get up to speed.

It's important to focus this whole process building around empathy towards people. And right now, it's especially important to have an even deeper sense of empathy, whether or not they were hired to work remotely, the current situation is not normal in remote work. If they were hired expecting to come into an office, they might not have a proper office set up at home or they might not have fast Internet or they might be looking after kids or they might just not overall have the ideal work from home set up.

Whatever their situation, it's important to be patient and understanding and to reassure them that you're there for them and that you also understand that this won't be a totally normal working environment for a while. Step one, focus on relationships, the most important part of onboarding is setting up the right relationships early on. By making those connections early, it'll be a lot easier for the person to start talking with others and ask any questions that they need to get up to speed faster.

It can be kind of awkward coming in somewhere and not knowing who is in charge of what or who you're supposed to ask for certain things from or not even knowing whether people even realize you exist. Some of the most important interactions that you can start setting up on your one on ones, make sure that you set up your first one on one with your new direct report, early on and keep it going on a regular cycle so that they know they have a time and space to talk to you about their career goals, their ideas, their concerns and whatever they have to say. This is a great time for you to get a good pulse check on how they're doing and talk about things that they might not want to bring up in team meetings.

Introducing them to team members is important, are also sometimes forgotten to make sure that your team knows in advance that someone is joining and let them know to welcome them when they're there. You'll also probably want to introduce them to people in other teams they'll be working with like designers or product or sales because knowing each other early on can make collaboration easier later. And very importantly, set them up with a buddy, it will be easier for them to ask questions if they know they have a dedicated person to go to who is expecting to be bombarded with a lot of questions for the first little while.

When you're working remotely, this relationship stuff is especially important and has to be done in a very deliberate way since the chance of hallway talk is a bit lower and kind of difficult for people who aren't really used to doing that remotely. I like to use a slack message or an email to have the new hire introduce themselves to the company. And Slack is really great because if they post a message in a general channel for everyone to see and the whole company can start adding, adding happy emojis and replying in threads and getting to know people right away, it not really makes it feel more inclusive.

Setting them up with a buddy here is extremely important because when you can't really see whether or not someone is getting annoyed with your questions, you're going to be less likely to ask them. And this is a point in time where it is critical to ask as many questions as possible. If they're set up with a dedicated question answer, they're not going to feel bad about it.

Instead of sending emails to insure them to the people they'll be working with, set up individual video calls so they can get a feel for how the person communicates, getting indication for things like sarcasm, level and speech can be really important information and avoid some pretty bad mix ups later on. Don't schedule them all back to back, though, because video call fatigue is very real. And if you're new hire is an introvert, that would be an extremely exhausting step of an already very stressful time for them.

Step two, write knowledge down, there is so much knowledge that your team has, which is just known, stuff that any outsider would not be able to figure out for themselves without asking. Every single team has this and it creates a bottleneck. You should figure out what that information is and write it down.

So if there's ever an issue that comes up in the team and someone says, oh, yeah, that happened to me last week and I did, this is all that you should write down. Or if there's an announcement of a team meeting about a new way of doing things or a new lender to install or something like that, you should write that down. And this doesn't have to look like the type of documentation you'd expect from a third party library where we can hire something but it should still cover the things that are very specific to your teams.

And that's not just going to help out the new hires. It'll end up paying off for the people within the team, too. I've gone back to our own Web docs so many times just because I keep forgetting how to run specific tests.

And this should be a collaborative effort from everyone on the team and should be a living document that's changing almost every day. You can set up this knowledge base in an online collaboration tool. So we host our own internal docs site on the read the Docs, because it's very familiar to us as Python developers.

But I've also seen GitLab does this by hosting talks on their own GitLab platform, which is kind of cool, and it's just trying that out. Step three create a frequently asked questions similar to your code bases, documentation, you should create a team and company, frequently asked questions document. There are so many not in code things that are just known within the team, like how to properly create a request or request time off or what the jury process is, or how to hand off tickets to QA, where is the Wi-Fi info stored, meeting etiquette and just anything kind of like that.

There's a ton and it can all figure it can all be figured out by someone by just living within the team for a while. It'll also reduce a lot of stress by having answers to some of those questions. This is also something that everyone on the team can contribute to and should be something that new hires add questions to when they're discovering that they wish they knew something.

Both for for this and a code based documentation, they're very helpful for people working remotely because they won't have that in-person context available. For example, we had a Friday meeting booked on our calendar, which was actually a meeting, and people kept getting confused about it, but they were in person in the office. They got to see that we were we were all standing up to go to this meeting and eventually figured out for themselves that context is not there when remote.

And so it is very good to write these kinds of things down. Step four: set goals and milestones, one of the biggest stress inducing parts of joining a new team is not knowing what you're expected to accomplish. And by one, that's pretty common to see people going overboard, trying to do as much as they possibly can in the shortest amount of time or working overtime in the first few months while pretending that they aren't just to make it seem like they have it all together.

I've definitely done this. It can really be like you're supposed to be as good as the existing team members when you join. And that's impossible because you aren't used to the code base and you don't have all this knowledge that they've acquired over potentially years.

So to avoid that, you should set out a realistic timeline for different goals for them to accomplish. For example, break down the Dev setup process into small chunks like getting localhost running at thirty third party integrations, running or whatever it is, and that might stand a day and then set out a goal for completing a particular ticket or creating request and whatever little units of work you can do in one week on your team. It should be easily doable so that the new hire feels like they're on track when they get to check everything.

And then set up goals for them to track their progress throughout the next three months. They should have a clear understanding of what knowledge they're expected to have and what pace they should be working at by that point. So by defining exactly what you're looking for, they're not going to burn themselves out.

And we'll know how to plan out their work to meet the goals. It gives them something to work towards. And if they surpass expectations and they'll get a chance to be proud and getting that boost their productivity in return to.

When you're remote, you should celebrate the goals and milestones achieved on a team. It's not really easy for them to swivel around in their chair and announce to their desk neighbour that they've created their first request. So look out for those moments and call them out so that the team can celebrate with them.

Even when I was in the office in person, one of the ways that I felt extremely welcome to the team was when my manager commented on my first requesting that I did a great job and congratulations, maybe very happy. Step five set up their physical space. This might seem obvious that it's actually sometimes forgotten to make sure that you have a computer and any other required hardware for people well in advance of their start date.

I've seen a lot of people scramble to clear off the storage desk so that they have somewhere to sit on their first day. And when people are working remotely, you'll have to take the step a step further and figure out how to get the hardware right to the person's home. So people who are working from home right now might not have been expecting to be working that way and their homes might not have a set up with a proper office space or any of the equipment.

So you should figure out whether your company can allocate a budget to outfit their home office or if there's any equipment that can be loaned them. Having things like a desk, a chair and a monitor can make a big difference compared to sitting on the couch looking at a laptop for a few weeks or months. I did this for a few months in university and I had to go to physio just to fix my back because I was straining it, looking down on my laptop so much it's not a good idea.

It's also a good idea to make sure that they have a fast, unlimited Internet because otherwise doing things like having video calls or installing software or uploading a new version of the app might be kind of worrisome for them. Step six, ask for feedback, asking for feedback is something that does not come naturally, especially if it's about you or something you mean you're proud of. It's a really important step in this process, because if you don't do it, you're going to be missing out on key insights about things that aren't working.

I have a feedback survey that I send to every new engineer after the first week on the team, which I send within Fellows feedback request tool. I ask them some things like start reading questions so that I can track metrics over time, but then also some open ended questions about what worked really well and what didn't work well and any ideas they have on what could make their first week easier if they could go over it again. It's played a huge part in how we perceive the process.

And every single time I send out this feedback survey, we get really great responses that make it even easier for the next person joining the team. We also make it easy for people to contribute their feedback directly into the process, the FAQ and the team documentation is editable by anyone and they're encouraged to correct anything that's not valid and make poor requests to make sure that we're keeping all of the information up to date. These little contributions are also good because they help them feel more a part of the team already because they're already contributing back.

So that's a lot of stuff, it might be kind of hard to visualize it as an actual process. So I'm going to show you how we've put this together at Fellow. This is an example template of a note that we use for people joining the team so it gets attached to the all day event marking their first day on the calendar, and it's divided up into sections that cover each of the steps of the process.

The resources section includes links to documentation and handbooks that have most of the answers people need. And the three that and the three sections at the bottom will contain a bunch of action items with set up process for the first day accounts to sign up for and a bunch of goals for them to achieve over the next week. So this this works for the first day, first week for the start of the onboarding process, but then outside of this, we also set up a bunch of different meetings, like we have sales demos that engineers get to sit on.

We have team lunches now, teams doing calls and a lot of different things like that. GitLab also has a very similar set of templates that guide people through their first few days and sets them up with accounts and lets them know what's the common what's expected of them. So very similar.

This is a screenshot of just part of one entire company handbook is available online for free, including the remote onboarding templates. So if you search for GitLab remote onboarding online, it'll come up. And I highly recommend this as a resource to base the start of your process off of.

With these six steps, the baseline to relationships, knowledge, FAQs, goals, space and feedback, you'll have a great foundation to create a repeatable onboarding process for your team. Is it really the bare bones that you need in order to level the playing field and make sure that everyone joining gets an equal footing in their first few weeks? And you never want to leave this all the chance and just hope that the person ends up befriending someone who walks them through everything or is extroverted enough to figure things out for themselves.

And while some of those might seem like things to tackle later on when you have your next hire, there are some things that you can start doing today to get ready for them no matter what your role is on the team. You can start by creating a set of documentation for your base with things like obscure knowledge that you just happen to know, like how to set up a testing environment of the billing system or who has the right tokens to rerecord API test cassettes. And this doesn't have to be a line-by-line walk through the code base.

You can also create a team effort, you for non code things like which meetings are actually meetings and what you don't have to go to. And lastly, you can ask your team for feedback. Even if you didn't have any kind of official process.

Everyone on your team started at some point and they probably have some thoughts on what could have made it easier to ask them or send out a survey and use that as a base point to figure out what changes you can start making right away to your onboarding process. This process will take some time to build up from scratch, and you probably want to start basic before ramping up to anything too complicated. Eventually, you can start experimenting with things like classes or official meet and greet sessions and things like that.

But remember that there is such a thing as too much process. If you have a company with 10 people, you probably don't need to have a week long process with classes and instructors and a bunch of structure like that. But you should still start small and build up as needed because you want to give people some flexibility in how they start the new job.

I hope that I've given you some ideas on how you can create your own first onboarding program or change up what you have now to make it more remote friendly. I'd love to hear about any unique ways your onboarding people or if you've had any success with that. I've talked about today, you can get in touch with me through my Twitter handle @Alexandras_dev, thank you.