Our Approach to Onboarding New DevOps Hires
by Yuval Oren, Co-Founder / CEO
It wasn't easy, but you managed to find and hire a new DevOps engineer to join your team.
They will be starting in a couple of weeks, which shifted your focus from recruiting to onboarding - What's the best way to onboard a DevOps engineer to the team?
You want them to succeed and be productive. Fast. But from previous experience, you know these are not effective:
- Send them a PPT file with a welcome presentation.
- Send them a link to Confluence to "Read".
- Hand them all the annoying Jira tasks no one wants to touch.
In my experience, none of these work.
Instead, you can make a big difference by using a hands-on approach to speed up learning, which will also familiarize them with how the company works.
The best way to onboard DevOps Engineers
You know how we DevOps folks expect developers to write Kubernetes and Terraform manifests? Well, it goes both ways.
The first thing a DevOps engineer should do when they start is to check out a real repository and release a feature to production.
It could be something very trivial. The idea is to get them to learn how developers (the users) work and the challenges they face:
- Setting up a computer with a development environment (sometimes takes days to reach that point).
- Handling dependencies.
- Testing the code.
- Deploying it.
- Making sure it didn't break production.
I can already hear your objections:
- They are not developers.
- They are not familiar with the framework.
But you can help them. And what better way to understand the build process, package management, testing, and deploying than to go through it yourself?
It's a structured and non-theoretical way of understanding the architecture.
I bet it will be eye opening for you as well.
The real benefits of this process
One of the biggest issues we've seen with DevOps teams is the lack of understanding of the customer - the developers.
Like with any product (or service), you have to understand your customers' jobs and how they go about their day. What are their goals, what are the challenges, and what motivates them.
We've seen too many solutions shoved down the engineering team's throat just because "that's how we did it when I worked at Google".
While this approach will not solve the problem, it will introduce some understanding and, hopefully, empathy.