Onboarding New Engineers My Recipe

Onboarding new people to the team is a challenge. Making sure they have a good experience and are set up for success can be quite a hurdle.

If you think about it for a second, being a new engineer on a team (any team), is such a challenge. There are so many things to need to learn, systems to read about, culture to fit into, intimidating right?

Over the years, I found a way to deal with this that works for me (and my teams). I thought it’s worth a post.

First 30 days

No pressure 30 days

The first onboarding conversation I have with a new employee, I specifically mention a no-pressure 30 days. There is a lot of pressure to “prove yourself” in the first few weeks, this can lead to rush in learning. There is no need for that.

When we hire, we hire for the long run, we don’t hire for 3-4 months, there’s no need to rush into it.

I find this approach useful. It takes the pressure off and allows the person to focus on learning, focus on the style of coding, focus on reading docs, etc.

No question is stupid, no question is off-limits

We have an open culture. New people tend to ask a lot of WHY questions. “Why do we do X?”, “Why do we need Y?”.

Internally, in the team, I make sure people don’t feel attacked by these questions, there’s no personal attack, even if we’ve been doing something for a long time or this was your original design, there’s no harm in these questions (If they are asked in a respectful way).

We have an internal channel on Slack, in there you can feel safe to ask any question about any subject. We find that these questions are the ones where we learn the most about the way we do things and fix a lot

Offer alternatives

The person is encouraged to offer alternatives, if the alternative is actionable, they are also encouraged to work on it right away.

low-hanging-fruit

In our Jira we have a label called low-hanging-fruit. Those are tickets that are easy to pick up start to finish.

Those tickets only touch a single service or a simple integration between two services. The description is detailed enough to not raise a lot of questions.

We assign a few tickets in the first week, across multiple parts of our stack. This allows you as a new engineer to get familiar and comfortable with parts of the system without the risk of over-reaching.

The spreadsheet

For your first 30 days, we have a self-tracking onboarding spreadsheet. This is something that was implemented by our HR and it is useful for the new engineer and other people on the team.

The spreadsheet is simple, it tracks goals, actions and responsible parties.

For example:

• Goal: Familiarize yourself with the deployment pipeline
• Action: CI overview
• Responsible party: SRE manager.

The sheet is divided into weeks (4 in total), the new engineer is responsible to tracking the goals and reaching out to the parties. Everyone is aware that this is the structure so you’re not surprised when they reach out to you.

30/60/90

Your career is my job

After the first 30 days, we plan 30/60/90.

The reason I chose to do it this way is that in the first 30 days, you find what is the person good at, what they want to work on, and so on.

We then plan the next 30,60, and 90 days. With clear goals, improvements, things to work on. We track it in every 1:1.

The sentence in the title here is something I repeat a lot. Your career is my job. My goal is to make sure you are always advancing, always developing, making sure you learn what you want to learn and work on your growth.

Summarizing

For teams like mine, I find the method described above works well. Especially if the people next to the new engineer truly care and participate in the process.