The onboarding of a new DevOps engineer defines how fast an engineer becomes productive, can collaborate with the right people, and find their social place in the organization. An additional reason to invest in a great onboarding journey is retention. A bad experience can easily scare away engineers in their first months. Engineer retention starts on day 1.

The quality of the onboarding journey can vary widely among organizations. Fortunately, you can gain so much by just spending a little attention and effort upfront. This guide can help you improve your company's onboarding journey at any company size. I created this guide as the first draft for the onboarding of PostNL engineers.

First, the guide covers all the usual things in place but radically changes how they are done. Second, it provides insight into often neglected parts that should be included in the onboarding journey. This guide is applicable to onboarding engineers with any focus: development, testing, and operations.

Goal of onboarding

Most organizations focus their onboarding journey only on getting a new engineer to be productive in the technical dimension. But there are two additional dimensions that you should include in your onboarding journey. You want to onboard someone in three key dimensions:

• Technical
• Organizational
• Social

The onboarding in these three dimensions determines how quickly somebody stops being the rookie and becomes a team member. Because being a team member is more than being able to contribute to the code. It is equally about building up trust with the team and finding a place within the organization. David Marquet beautifully sums up the purpose of onboarding in the following video. Again, the goal is to move the new hire to a team member.

Now that the purpose is clear for onboarding, we can differentiate different phases during the onboarding. In each phase, you should take care of several matters and events. The phases this guide identifies:

• Before Day 1
• Day 1
• Week 1
• Month 1

Before Day 1

The onboarding experience starts taking shape before their first day. You can have huge payoffs on their first day by putting in a little work before they arrive. The benefit is that the new employee gets more excited and looks forward to their first day joining your organization. On the actual day, the engineer begins, you want to have a smooth and enjoyable experience. The result should be that they come home and say: "I had a fantastic first day!". The work you do before day 1 is to get this result and welcome the beginner as a new team member.

The first thing to arrange is access to all digital systems. The new engineer should not spend their first-day getting access to all systems because that would be an incredibly dull experience. Second, nothing causes more a feeling of being an outsider than sitting alone trying to get access while the team continues their regular work. You want to avoid this feeling the whole first day. Preferably, this is managed through Single Sign-On(SSO) with groups. Additionally, there is often some peripheral shadow IT, like a team shared calendar that you should also set up.

Now that the digital environment has been taken care of, you need to arrange for the physical things. This is mostly applicable to larger organizations that provide more to their employees. First, the company laptop and a badge for access to the office. Second, you should prepare their home office. While most first days are still in the office, remote days already often occur in the first week. So you should inform them how they can use home office compensations. Taking care of this before the first day is a widely different experience and shows caring for the new hire instead of hearing about compensation months after starting to work.

Onboarding buddies can be extremely helpful to the joiner. The onboarding buddy is responsible for smoothing over the onboarding experience and guiding the new individual. So you should appoint one. The best person to do this, in my opinion, is the most recently onboarded team member, regardless of their skill level. They have been in the same position and remember the solutions to solve the problems in onboarding quickly. An objection often heard is that they cannot explain everything yet, but this is a secondary advantage. Explaining is the best way to find what they themselves do not yet understand. It becomes a collective learning experience. So now you upskill your whole team. It is a great way to reduce tribal knowledge and is an excellent opportunity for a more junior engineer to take the lead in something. It creates a culture that everyone leads. Choosing the most knowledgeable person ensures that they stay the most knowledgeable. Ensure the onboarding buddy does not have a lot of personal time off in the first week. If so, pick someone else.

Onboarding a new team member takes a lot of work. Onboarding is a team's responsibility, not solely for the joiner or onboarding buddy. A team's best way to visualize and track work is usually to have it be part of the backlog. Therefore add an onboarding ticket on someone's first day. That way, it signals to the team that part of what they should be working on is spending time with the new person. If you do not use a backlog, find another way to emphasise the importance of bringing on the the new team member. Finally, ensure all events for day one and week one are planned ahead of time and blocked off in all team members' agendas.

The last thing to take care of is to share what the starter can expect on their first day. Before their first day, you should send an e-mail to their personal e-mail address that includes where to meet, who will pick them up, and how to reach them if anything comes up. In your e-mail, have an itinerary of the first day so that the new arrival knows what they can expect, including lunch options. Lastly, include if there is any (implicit) dress code or indeed no dress code. Informing the starter helps to reduce apprehension.

Day 1

The first day is to help get the new engineer a mental model of the team, both technical and businesswise, start the social connection with the team members, and start understanding the organization. The goal is to give the new employee a fantastic first day to talk about with enthusiasm at home.

It is essential to ensure that the new engineer does not get overwhelmed during the first day. Be watchful of this and regularly ask how the engineer is doing. Additionally, emphasize that anyone can call for a break at any time. My recommendation is to use a top-down approach for the best learning experience because it starts at an abstract level with little detail and gradually introduces extra information. During the onboarding, you should ensure psychological safety because the new hire can feel unsafe due to having to admit repeatedly that they do not understand things. So when you want to check if something is clear, ask if YOU should explain more instead of if they understand everything. You should also introduce any acronyms before you use them. These are just two examples of how you can ensure safety.

The first step would be to show the outline of the onboarding process and the goals of the different phases. This helps to give perspective on what the next couple of days and weeks will look like. Several events described below should now take place with ample breaks between them.

The most important lesson should be to take the time to clarify the mission of the team. A good grasp of the mission is a basis for any good decisions. Subsequently, explain to the new engineer the team's problem domain and what value the team is pursuing. The following step is to discuss how the mission leads to the team's roadmap. Once the engineer has a long-term view, you can take a step deeper into shorter-term goals: current epic or quarter. The last step would be to discuss current work in progress or sprint backlog. This event ensures the engineer is up to speed using a top-down approach to what the team is trying to achieve. Typically the Product Owner would clarify this, but in smaller startups this is often the founder themselves.

The following learning event is to take the engineer through the software and infrastructure developed by the team. Again, you want to do this with a top-down approach and the C4 Model is an excellent approach with architecture diagrams to support this event. First, you want to paint how a service fits the bigger picture by showing interaction with other systems. After that, you can take a step deeper into how the solution architecture is designed. Code doesn't have to be introduced just yet. This is best left later.

A tip to have long-lasting benefits for the team is to have this event be documentation-based. For example, if you are drawing many whiteboard models, it means these diagrams are lacking in your documentation. If you need it to clarify details in your current documentation, you should improve it. That way, you improve your documentation long-term and use it in other sessions.

Next up is introducing the team's workflow as the first step in introducing the entire organization. This event explains all the different phases a team included in the workflow. For example, a team can identify backlog, refinement, in sprint, in progress, test, and deploy phase. In every stage, explain what particular work a team will do and what the quality level should be before it can pass to the next one. Additionally, introduce and explain the purpose of every team-level event. Typically the Scrum Master would do this in a Scrum environment, but often there is a person responsible for the process in smaller organizations that can do this.

Lunch is a time slot where team members usually go off and do their own thing. If the clock strikes 12 o'clock, everyone storms out to hit their lunch buddy and do their lunch routine. It can be eating out of the office, eating in the company canteen, or eating their own lunch in a communal area. But a new hire does not yet have lunch buddies with their routine or know the eating options. They are left to fend for themselves.

Instead, you should go for a team lunch with everyone! With how much we spent finding someone, a big team lunch is only a tiny drop in the bucket while having a great benefit. Often during lunch, they have only been introduced to some members and spent the most time with their onboarding buddy. So this first lunch is a great time to go and have a lovely team lunch. It is time for the team to gather, connect with the person, and CELEBRATE!

Suppose lunch is not a good option because you are remote or extremely other pressing reason. Then, make sure you include another social activity where the whole team participates. Full participation of the team is essential! But do not choose an activity that makes the new person the center point.

At the end of the day, the onboarding buddy should reach out and see how the first day went. Then, after talking through the day, you can give a small social cue that it is OK to leave for home. Everyone feels the anxiety to head out on their first day. It helps to signal that there is a healthy boundary for work. For example: "I will see you tomorrow if you are heading out, but you are free to relax around and talk to some people.".

Week 1

The first week's goal is to continue strengthening the new engineer in the three dimensions. They should become more technically proficient by adding their first bit of value; finding their place in the larger organization; build stronger relationships with the team members.

Everyone learns in their own way. Ask what works best for them, either high-touch or low-touch. High touch is visual learning through joined sessions, while low-touch is self-guided learning through documentation. Both are equally fine. It would be best if you catered for this. Additionally, you want to start putting the new hire in charge of their onboarding. While this guide can help you orchestrate behind the scenes, the new hire should start taking their responsibility to plan and do the next steps in the guide

The main goal for improving the technical dimension should be to add a tiny bit of value. A tip is to pair-program their first ticket into production with the new engineer[2]. Ensure that the new engineer is the driver and does most of the work. Understanding of the code can significantly be increased by making an actual contribution. That is why it is fine not to introduce code on the first day. After the coding work has finished, you can explain the coding standard and the review process. The goal should be to show all steps in the workflow. Preferably, this would be deploying to production or collaborating with operations to deploy. The engineer should see every step in the circle of control of the team needed to add. Additionally, the engineer should spend time building all services locally, reducing the barrier to picking up any ticket in the following weeks.

The first week is an excellent time to dive deeper into the team's product. Any product is built with a specific goal, so you also need to explain the revenue model or performance indicators that you strive for and the significant costs required by the business to deliver the service. Of course, the best understanding comes from the product's actual use, so set up the product for personal use.

During this week, you should plan more 1-on-1 social time with every team member individually. These sessions help build the social relationship between every team member. During these get-to-know-each-others, you should not talk much about work, but mostly about life outside work and hobbies.

Next to building relationships, you should spend more time explaining the team culture. This topic includes addressing informal communications like how people use e-mail, group chat channels in slack, and direct messaging. Additionally, it would help clarify expectations about implicit work times that you are available for meetings, how the organization looks at asynchronous and synchronous communication, and remote working versus on-site. The latter should only be finetuned and already be agreed upon before contract signing.

The new engineer can be productive from week one if you shift their perspective from how well they are adding value to the immediate backlog team to improving the onboarding flow for the next candidate. The engineer's goal should be to document and automate wherever they can during onboarding. That way, they immediately start adding value for the long term, coming up with suggestions right away, and having their own thing to work on.

Month 1

The first month's goal is to become an independent value adder, step beyond the team to start interacting with the larger organization beyond the team, while the team strengthens the social dimension with regular activities.

Any service should be maintainable by everyone to ensure the quality is futureproof. So during the first month, any tickets involving services that the new team member is not or less familiar with should preferably be done by them. Again pair programming is an excellent method to spread knowledge. Picking up the ticket includes deploying to production for the reasons mentioned before.

In a DevOps environment, you want to start preparing to be on-call. The new team member begins by being on-call during the day. That way, they can ask at any time for support from the team. Being on-call can often be overlooked, especially with more junior members, but it is vital to be a real team member by doing your share of the on-call rotation. Again, this is an excellent opportunity to upskill members in being proactive and taking the lead. Showing commitment to place the new team member to be responsible for on-call helps build trust. Depending on the complexity of the services, the team should add the new team member to the on-call shift within the next three months.

You want to make sure the new team member meets with everyone relevant to the team in your first month. In a small startup, this can be everyone working in the company. In midsize corporates this is some key figures. But in a large corporate this is often just the key figures of a department and some supporting people from other departments. You benefit from having met someone socially if you need to later work with them.

Most larger companies have additional gatherings of professionals to exchange experiences and learn from each other. There are many names for these: guilds, chapters, communities. The groups can be for specific roles or interests. They can be groups to improve the company in one particular area. Otherwise, the group is centered around people with a certain hobby. Be sure to introduce the new person to these groups and the larger community.

Building the social connection should continue but is primarily overtaken by the regular social activities. In any team, social activity builds a trust platform where you can work upon. Social connection and trust are so important that enforcing them never stops. You should keep having regular buddy meetings to allow for scheduled time to help with anything, explain anything, and most important recap anything that was not properly explained.

At the end of the month, you probably have spent a lot of time talking to the new team member and explaining everything about everything. Now it is time to shut up and listen. Your new team member at this point is a great asset. They understand your environment but are not yet shaped by your own mental models and perhaps imaginary constraints. So it is a great time to ask, whatever seniority level, what should the team do differently, what is peculiar, what is unnecessary. You want to see if the new team member has any improvements in the same three dimensions you trained them in: technical, organization, social.

Wrap up

I was personally motivated to write this guide. As a freelance consultant, I have been onboarded many times over the last few years. I don't put much significance in an onboarding experience as an outsider. But some experiences would undoubtedly put a new employee on a bad foot. Additionally, I also have seen onboarding experiences going wrong with coworkers. These experiences have made me vow to do my best onboarding developers in the teams I work with and save them from the same experiences.

Onboarding experiences can be awesome as well as I have seen myself. This guide also is heavily influenced by the guides written by GitLab especially thinking about three dimensions.

I hope this onboarding guide helps you to improve your onboarding journey. The key is to invest in the three dimensions. It is as much introducing the technical dimension as building the social connection and showing the organization.  The work for onboarding is as important as other work. Onboarding, after all, is a team effort.

Let me know what you think, particularly any ideas or experiences that you have, by connecting to me on Twitter. If you need any help implementing DevOps or AWS in your organization, feel free to contact me!

Below is the full checklist.