How to quickly get engineers up to speed

Alexandra Sunderland: Hi everyone. Thanks for joining my talk today about onboarding engineers on your team. I hope you're all doing well and I know it's too bad we don't get to meet in San Francisco this year, but I'm pretty glad that I get to share this talk with all of you anyway, because of course a lot has changed in the world between the time that I submitted this talk around winter time and now. But people are still going to be starting new jobs right now, just mostly remotely. You can almost translate an in-person process directly to a virtual one. So I'm going to be taking the opportunity to talk a lot about a lot of different approaches for remote onboarding to address some of the nuances and give some tips on how to create a really good in-person experience and a very good remote one too. My name is Alexandra Sunland and I've been working as an engineer for almost the last decade, and now I'm an engineering manager for the ecosystem team at fellow 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.

So I created the onboarding process at Fellow, and before that I was at SurveyMonkey where I was a coordinator for the internship programme. So I built a lot of processes to onboard students and helped teams build their own processes out too. Onboarding is something that I have a lot of experience with and I've been collecting feedback on it for years because it's something that I think is really crucial to a team's long-term success. I think that one of the most important skills that you can have as an engineer and especially as a manager is empathy. So on your team, part of that empathy is towards people who are perhaps nervously joining and don't have any context on what tools you use, what processes you have and what your tech stack looks like.

Something that might seem super obvious to you might not be something that new hires even think of asking about, and it makes it harder to get up to speed as fast as we'd like and might make the person feel like they aren't doing a very good job or aren't smart enough. So creating a good process, make sure that people feel they have that psychological safety and that goes a long way towards being able to quickly scale up a team. I think that the reason that I feel a particular empathy for people starting a new job is because of how absolutely lost I felt when I started my own first programming job.

When I was really young in the summer before going to university, I was really lucky and got a job at a local startup and this startup did a lot of web programming. I didn't even know that web programming was a thing.

I didn't know about HTML or JavaScript. I pretty much just knew Visual Basic and Java, and I definitely did not know that you can make a web app as a business because this was around the time where you would download pretty much everything you want to use. So when I joined, I did a lot of weeks of Googling things like what is a web app? What is a web server? What is an API? What is a request?

All of this stuff, because I had no idea what was going on, I didn't know who to ask and I felt pretty lost and I thought I was supposed to have all the answers. And that experience has always stuck with me, and even though it was a great learning experience and I probably learned the most that summer out of any of them, it's not a very scalable experience if a lot of people on your team have to go through this process.

Since then, I've helped onboard a lot of people in a lot of different ways and I've also screwed up a lot in the process. So the first time that I onboarded someone was when I was still an intern returning for the summer and another brand new intern was brought on board and I was supposed to hand off the project that I'd been working on to him and pretty much what I did is I sat down with him and went on a line by line, walk through the whole code base and just told him everything that I knew and kind of thought that would be the whole onboarding process. But over the next few weeks I got a tonne of questions because I had not explained anything about why we built the product, who was using it, what the requirements were or any of the context like that that would help him come up with answers to his questions himself or figure out where to go to find those answers.

So information overload is not a good way of onboarding people. And then I've also been in a position where we've had a series of courses at companies that are taught to engineers as they join. So I taught an intro to Jinja course, which is a templating system used with Django, but every engineer who joined the team had to go through or joined the company, had to go through this course that I taught, and not every product and not every team actually used this technology and I would have to teach it to seniors and juniors alike.

And so a lot of people would come and learn this thing with me for half hour but then be very, very bored because they never ended up using it in their job, and I felt very sad that it was wasting their time. And so while you might not want to set up courses or some large structure to teach everyone everything you might think that they need to know, it's also very important to not skip over anything that might seem obvious to you and assume that the new person knows everything.

And this is true for technical things like maybe someone is a great Python programmer but just never got around to try and Kubernetes, so they need a quick intro or at least a heads up. That's something that they should be looking into. But it's also important for organisational and interpersonal things too. So it's important to be aware of people's backgrounds, like maybe everyone on your team has worked at a tech company before and they knows what a scrum is and they're on board with Agile and Waterfall and they get all that terminology. But it's also very possible that a new hire is joining the team from an agency where they didn't have those kinds of structures and they're smart and they know what they're doing, but they're going to be pretty lost if you don't take the time to walk them through work gets done on your team.

So a while ago I was onboarding someone and partway through the high level code base overview we were doing, they stopped me because they had not seen the product, they did not know the structure of the company and they incorrectly thought that I was their manager.

So I made this assumption that people had a baseline understanding of what was going on and I was pretty wrong. The downside is that it can feel awkward for people to ask what seems like basic questions when they're still new because if you're acting very confident, it can seem like they should know the answers already and they might be afraid to bring it up. So it's important to go into onboarding assuming that the person has the skills and the abilities to perform the job they were hired to do but doesn't have any of the context yet.

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 actually been through. No matter what process you come up with, one of the most important steps is to ask for feedback so that you can figure out what parts need improving, which parts aren't helpful at all and what parts are valuable and should really stick around for the next people. I send out the same feedback survey to every new hire at the end of their first week on the job so that I can get a good idea of what needs to change. And it's brought a lot of great insights and it's shaped our process for the better. Everyone always has at least one point to make it better, and so everyone always gets the new improved onboarding process.

So this framework is what I like to share with you today so that you can also create your own onboarding process to effectively get engineers up to speed on your team. 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, and you need so much empathy to be able to do this. So if you think back to when you first started and all the questions you had and the difficulties that you encountered, remember that when they start, they likely won't know anyone or any of the internal processes or traditions and are probably going to be feeling a little bit out of place while they try to get up to speed. And right now, it's especially important to have an even deeper sense of empathy because whether or not they were hired to work remotely, the current situation is not normal remote work.

If they were hired expecting to come into an office, they might not have a proper office space set up at home or they might not have fast internet or they might be looking after kids or parents or just overall they probably might not have the ideal work from home setup. So whatever their situation is, it's really important to be patient and understanding and to often be reassuring them that you're there for them and that you also understand that this is not going to be a totally normal working environment for a while. So 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 start talking with others and to ask any questions that they'll need answers to get up to speed faster. It can be awkward coming in somewhere and not knowing who's in charge of what or what to ask or who to ask certain things from or not knowing whether people even realise that you exist.

Some of the most important interactions that you can start setting up right away though are your one-on-ones. So you should make sure 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 that they have a time and a space to talk to you about their career goals and their ideas and their concerns and whatever it is that they have to say, this is also 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. And this isn't something that should just be done for new hires. This is something that ideally you have set up with all of your team members already introducing them to team members is important, but it's actually sometimes forgotten.

So you should always make sure that your team knows well in advance that someone is joining and let them know to welcome them when they're there. And you probably also want to introduce them to the people on other teams.

They'll be working with the designers or product people or sales because having those lines of communication open can make collaboration a lot easier later on. And very importantly, it's very important to set them up with a buddy because it can feel kind of awkward going to people over and over asking questions, especially in the start when you're supposed to be asking a lot of questions and having a dedicated buddy and making it known that that is the person they can go to for any question. It'll make it a lot easier for them to feel comfortable bringing up questions and talking to them on a regular basis.

When you're working remotely though this relationship step is super important, but it has to be done in a very deliberate way because the hallway talk, like when you run into someone by the coffee machine and just introduce yourself is not going to happen as naturally and it still is possible. You can run into people in a Slack channel or just discover each other, but it's not something that those of us who are used to working in an office are really used to. So relationships need to be almost kind of forced in a way. So I like to send a Slack message or have the new hire send a Slack message in the company-wide channel to introduce themselves, which is kind of nice because everyone knows who they are and they can react with emojis and start a thread and really make them feel welcome right away.

But setting them up with a buddy here is also super important because when you can't visually see whether or not someone's getting annoyed with your questions, you're a lot less likely to ask them.

And this is a point in time where it's critical to ask as many questions as possible and instead of sending emails to introduce people, it's also much nicer to schedule video calls where you you're involved. So a three-way video call, four-Way video call with whoever it is that you're talking to them because getting to interact with someone in person is a great way to get a feel for how the other people communicate. So there have been mix ups sometimes where someone's written communication is maybe a bit sarcastic, but when you don't know the person that can feel maybe like they're being a bit mean, but having that initial video call talk makes it kind of clear what is going on with the communications style there.

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. So if there's ever any issue that someone on the team encounters and says, oh yeah, that happened to be last week I did this to solve it, you should write that kind of thing down. Or if there's an announcement at a team meeting about a new way of doing things or a new linter to instal or whatever, that's also the kind of thing to write down. And this doesn't have to look like API documentation or anything very, very structured and specific, but it should still cover the things that are very specific to your team, and it's not just going to help out new hires either.

It's also going to end up helping out your team.

I've had to go back to our own dev docs a tonne of times to figure out how to rerun certain tests because I just forget this should be a collaborative effort though it's not just for the manager of the team to do. It should be a living and breathing document that every team member contributes to, and it's something that the new hires can contribute to when they realise that there's some information that would've been useful that was not included in that documentation. Step three, create a frequently asked questions document. So similar to the code-based documentation, you should also have a team and company FAQ because there are a lot of non code things that are just known with a team too, like how to properly create a pull request or how to request time off, what Jira process you should use, how to hand off tickets to QA and everything like this is very, you can figure it out over time just by living within the company, but it's going to reduce stress if you have a lot of answers to those questions upfront.

This is also something that everyone on the team can start contributing to both this frequently asked questions and the codes based documentation are especially helpful for people working remotely where they won't have that in-person context available or won't have people around that they can just quickly ask. So it can also point them towards questions that they maybe should be asking. Step number four, set goals and milestones.

One of the biggest stress inducing parts of joining a team is not knowing what you're expected to accomplish and by when. So it'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 over time in the first few months while pretending that they aren't just to make it seem like they have it all together. And it can really feel like you're supposed to be as good as the existing team members when you join, and that's impossible to achieve because they've been there for maybe years and they have all of this institutional knowledge that you just haven't acquired yet.

To avoid that, you should set out a realistic timeline for different goals for them to accomplish. For example, break down the dev setup into the dev setup process into small chunks or set aside a couple tickets and kind of outline what should be doable within the first day, what should be doable within the first week, and where they should be at three months from now so that they know what they have to do by when and they can pace themselves without burning out already. When you're remote, you should celebrate the goals and milestones that they achieve on a team Slack channel, which is something that we like to do. It's not easy for them to just swivel around in their chair and happily announce to their desk neighbour that they've created their first pull request. So you should 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 very welcome to the team, it was when my manager commented on my first pull request saying that I did a great job and congratulations. And so that is something that I've continued doing with the new teams at fellow step number five. This might seem obvious, but actually I've seen it be forgotten before, but you should make sure that you have a computer and any required hardware for people well in advance of their anticipated start date. I've seen some teams scramble to clear off the storage desk so that someone has somewhere to sit on their first day. And when people are working remotely, you'll have to take this a step further and figure out how to get that stuff to the person at home. You might be lucky and have it taking care of this for you or hr, but if you're a startup, this is something you should kind of think about when you hire someone.

And people who are working from home right now might not have been expecting to work this way, so their houses might not be, or their homes might not be set up to properly accommodate them. So you should figure out whether your company can allocate a budget for them to outfit their office or if there's any equipment that can be loaned to them short term, like a monitor and a keyboard or desk and a chair can make a really big difference in how they work.

For a while in university, I didn't have a desk or a chair or anything like that, and so I was sitting on the couch for months on end and I ended up having to go to physio to fix my back. So you want to avoid people who are working for your company having to go through that right now. Stop number six, ask for feedback.

So asking for feedback is something that doesn't come naturally, especially if it's about you or something you've made are proud of. But it's a pretty crucial step in the process because if you don't do this, 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 their first week on the team, which I send within Fellows feedback tool, and I ask them some star rating questions so that I can track metrics over time. But I also have some open-ended questions, what worked really well and what didn't, and I ask for ideas on what would've made their first week easier if they could go over it again. It's played a huge part in shaping the process for onboarding here at Fellow, and we've also made it very easy for people to contribute their feedback directly into the process.

So the FAQs and the team documentation are editable by anyone, and everyone's encouraged to correct anything that isn't valid anymore or pull requests to make sure that we're keeping all of our information up to date and these little contributions that they can do right off the bat, make them feel more a part of the team as well. So that's a lot of stuff, and it might be kind of hard to visualise this as an actual process. So I'm going to show you how we do this at Fellow. This is an example 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 different sections that cover each of the steps. So resources includes links to documentation and handbooks that will have a lot of the answers people need.

And the three sections at the bottom have the goals and milestones I outlined where they can check things off and feel like they're doing some progress. And outside of this, we set up a bunch of different meetings like sales demos and team lunches and other little social things like that with these six steps as a baseline.

So relationships, knowledge, FAQ, goals, space, and feedback. You'll have a pretty good foundation to create a repeatable onboarding process for your team. And these are 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 because you never want to leave this all to chance and just hope that the person ends up befriending someone who wants to talk them through everything or happens to be extroverted enough to figure things out for themselves.

And while some of these steps might seem like things to tackle later when you have your next hire, there are some things that you can start doing today to get ready for them, like writing things down, creating that frequently asked questions document and asking your team for feedback. Because a lot of people who have joined your team probably remember their first week and have some good ideas about what would've made the process easier for them. So this process will take a while to build. It's not something that you can just build up in one day, but it is also important to remember that there is such a thing as too much process. So 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 lot of structure.

So you should start small and build up as needed based on feedback, because you still want to give people flexibility in how they start their new job. I hope they have given you some ideas on how to create your own first onboarding programme or change up what you have now to make it more remote friendly. If you have any, I'd love to hear about any unique ways that you're onboarding people or if you have any success with what I've talked about today, you can get in touch with me through my Twitter handle at Alexandra s Dev. Thank you.