Onboarding

May 1, 2019 · 11 min read
#people #recruitment #management #process

My aim with this blog is to document how I like to run my teams, and note the various things I’ve seen during my career. When meeting new people, there is a tendency to cover old ground (I’m skilled at this), which is useful in the sense you have a common understanding, but it can be time consuming. A few times recently I’ve wanted to provide substantial opinions, but the communication format doesn’t lend itself well to that style. With this in mind, I’m writing my thoughts down, so folks can read in an async manner, comfortable to them.

This post is going to focus around onboarding a new colleague into your software engineering team. It’s aimed at Tech Leads/Engineering Managers (potentially the same depending on your org).

Recruitment done, now what

I am going to detour around the recruitment aspect, for now, and consider the “what next”.

So, recruiting into your team was probably hard work (unless you have brand appeal, or your business is in a niche market). It was probably a lot of reading resumes, lots of meetings with recruitment teams (in house or agency), and ultimately lots of technical tests and/or face to face chats with candidates.

I’m tired just thinking about all the work involved before you can send the contract out to your new team member.

In this post, the successful candidate for your team was Louise. Louise has a 6 week notice period at her current gig, but is really looking forward to starting her new role with you. She has the passion to help drive the team and really focus on quality. She’s a star.

Great, however, the clock is now ticking against the big machine of corporate IT, and Property Services, and, and, and…

We need to sort the following:

If you do not deliver on the above in six weeks, you have failed. To me, this is your key role now. Fail on the above, and Louise’s first impression of you will be of failure. Failure to deliver. If you fail to deliver the above, what else will be missed (pay reviews, promotions, training budget, etc).

Work area

Clean the desk. No discussion. When Louise starts, the desk should be inviting to her. It should not be 2 old PCs, that no one “knows” about, some old books no one can decide if they are allowed to throw away [1].

You, personally, clean it. You set the standard for the team.

The desk should be spotless. The chair should be clean, not stained, or dusty, or god knows what else.

This is on you.

Equipment

This is a pet peeve for me, so you are forewarned here. This seems alien to companies (maybe not in the US), but ask Louise what kit she would like (you’re in touch with Louise right).

Sidebar - Are you in touch with Louise? Right now, her current employer are in the war room, disaster mode. They have lost their star, the project will fail. They need her. Money, perks, package, projects, whatever is required. They are trying to convince her to stay where she is.. Be aware of this.

Back to equipment. Ask, ask, ask. I am fully aware that there will be company policies etc, but hopefully a developer has some choice of Windows, Linux, Mac. If you hire me as a developer, and give me a Windows machine I am going to struggle (honestly). I’ve not used one in over a decade. I’m not going to be as productive.

Here comes my pet peeve - the form factor. I’m not kidding. I do not want a 15 inch MacBook Pro. This is a personal thing, and that is why you engage with your new colleague.

I’m on the train a lot, and I work in several different offices and at home. A 13 inch MacBook Pro is the perfect form factor for me. It fits onto a train table, easily. It easily fits on my lap if I don’t have a desk at the office. It does not weigh as much as the 15 inch. My current gig, when I work over in head office, is a 25 minute walk up a hill, lovely scenery, but the hill! That extra 2 inch of laptop would pain me. That extra 2 inch of screen is not worth it either. In reality you’re likely to have extra monitors at the office or home.

I once started a job, and I was presented with two laptops. Both 15 inch. A Dell, and a MacBook Pro. I have no idea what I was suppose to do with the Dell. None whatsoever.

People

Teams eh. Full of people. Full of personalities. It’s a tricky rope walk. Take some time to ponder where Louise is going to sit. Is it the “replacement” spot. Is it isolated. Is there some weird office joke about the desk (don’t ask, it’s a real thing).

Would Louise pair well with Rachel, or Ross?

Was Ross going for the same role that Louise was just offered, hmm, that may need some thought.

First day

This is it. You asked Louise to get there a little later, so you had a little time to get in and double check all was just so. You check one last time that the desk is clean from rubbish, the equipment is ready for her to unbox, and that it reflects positively on your team.

And, you are there, first and foremost. Not delegated to Rachel or Ross, because of $reasons.

The first day is overwhelming anyway, which can often be compounded with 100 new faces, corridor meet and greets, meetings (why would you do this), hand shakes etc. I personally would not remember all that, so it would be wasteful on everyone’s time.

Again, at this point, it’s worth re-iterating that Louise is an Individual Contributor in the team. If you are onboarding different levels within the org, the details would be different, to some extent.

It’s about the individual, not the process.

Since you need to focus on the individual in all of this, below is the perfect first day for me if I was an Individual Contributor in your team.

Remember everyone will differ, and the process needs to flex. But don’t pack everything into the first day is the key takeaway. If you are in a position to get an engineer to deploy something in their first day, try. It doesn’t have to be of any importance, maybe you have a humans.txt file or something.

It’s not about testing the individual either, it’s about re-enforcing to Louise and the team your principles. Engineers generally want to get hands on, this is a good way to do that.

At the end of the day, having deployed something to a system is more rewarding than meeting Joel in HR, and Elena in the Machine Learning team. That’s not to say these meetings should not happen, they should, but not on day one.

Introductions should be gradual and relevant to the expanding universe your new team member finds herself in. Maybe Louise is going to need to work with Elena in Q3, but it’s Q1, and Louise doesn’t need to know that yet, don’t overwhelm.

This is where the manager earns their money in my opinion. It’s a constant balance of knowing the individual and whether you need to hand hold or back off. It’s hard, very hard (or it has been for me, in the past). You need to fundamentally show that you are available, and approachable, but not micro managing.

First week

Louise comes back for day 2, that’s good. Now we start to ease into all the other stuff folks normally cram into day one.

So, team culture.

Is it documented in some form of process (I’ve recently heard it called “habits” to lesson the chagrin of developers hearing the word “process”). Can Louise go and read it somewhere, or is it more symbiotic. This is likely going to depend on the team and company, but Louise needs to know that.

Hopefully your team is using some form of communication tool. Let’s say it’s Slack. You need to curate some channels Louise needs to know about. I’d recommend inviting her to team channels, and then sign posting some other channels Louise may be interested in, but let Louise choose. Your job is to curate the list (again this depends on the org, maybe you have 1000 slack channels etc). It will be interesting to know what she chooses, and helps provide you knowledge of interests.

So, Louise fixed and deployed something yesterday, that’s awesome. Now provide context to all of that. Where Louise and the team sit in the larger business unit. A little backstory of the team. Be mindful of how in depth this backstory is, it’s largely irrelevant and more about you.

Now we need to start talking about terminology that Louise needs to know. Acronyms for example, it’s probably an alien language, or could be. Does the team use a certain emoji for certain situations in Slack, to acknowledge or block something. All that kind of stuff may be in your process/habits wiki, it may not. Again, curate this knowledge and sign post to where Louise can get more. These are the things that make teams stick together, but it can also be intimating to incomers, be aware of this.

Summary

The best experiences I’ve had in this space, is when it didn’t feel planned, yet everything happens in a smooth/effective manner. It felt like I naturally ended up at a given situation at a designated time, that my boss was waiting for, but they didn’t actually seem to be waiting.

Now it’s simply a matter of retaining Louise so she can make the difference you know she’s capable of.

Good luck.

Footnotes

See also

Content

Social

Recent