Onboarding for Software Engineers

There has probably never been a better time to be a software engineer than right now. Most businesses and organizations across the world make use of technology for their day-to-day operations. For some of these companies, their whole product and business are engrained in their technology usage. Moreover, technology keeps advancing as new technologies and frameworks get released often. Businesses need to keep their technology up to date to remain relevant. Every person with internet access, which eventually will be the whole world, uses lots of apps and websites every day. All this has resulted in a massive demand for people with the skills to build software — the software engineers.

The supply and demand curve for software engineers is not balanced. As it stands, demand is much higher than supply as a truly valuable developer is one of the hardest things to find for companies. If you are involved in recruitment you’ll know what I am talking about: the competition is fierce and qualified candidates are baited from one company to another with promises of free gadgets, gym memberships, equity, remote contract work, loads of time off, and some of the best salaries in the world.

Companies spend a lot of time and money in the hiring process for software engineers. If we step back and consider the reason you want to hire a software engineer at your company — ideally once you hire that person, you want them to provide value to your company. You want a new software engineer to be as productive as soon as possible and to remain productive for the long term.

There’s nothing worse than feeling you are wasting your time. Imagine putting all your time, energy, and resources into hiring someone and then they never become productive, or worse, they quit within a few months. The cost of replacing a recently hired employee is 30-50% of their salary. Companies lose 25% of their employees in the first year, and all too often due to faulty employee onboarding processes. It is a waste of time and money and reflects poorly on your company if an employee leaves early on. Skilled software engineers are so high in demand that they can afford the luxury of switching jobs as often as they like, which takes the importance of onboarding and retention to a whole new level.

When I looked at what would make great onboarding for software engineers, I thought about what traits I believe make a successful all-around software engineer. I then thought about how I could help someone develop those traits. I came up with three key areas to focus on once a new software engineer joins a company:

1. Tools / Technologies
2. Domain Knowledge
3. Soft Skills

I will elaborate on each of these three areas, explain what they are and how to provide the ideal training environment for your new software engineer to succeed in them.

Tools / Technologies

When looking at tools and technologies, I am referring to the following:

• What programming languages do you use at your company? 
  • Examples could be Ruby, C# or Python and many more.
• What frameworks do you use at your company?
  • Examples could be Ruby on Rails, Django or ASP.NET, and many more.
• How is the architecture of your systems structured?
  • Do you have one monolith application or is your system split into multiple services.
  • If your system is split into multiple services, how do they communicate with each other?
• What source control tool do you use?
  • What are your workflows when using that tool?
• How is your infrastructure set up?
  • Where is your code hosted?
  • Is this all done in an automated way or is it manual?
• What build and continuous integration tools do you use?
  • Where does code go to once a developer pushes it up?
  • What runs the unit and integration tests?
  • How does the code eventually get to production?
• What coding standards and preferred practices do you have in place at your company?
  • A software engineer may join your company having used similar technologies at a previous company, but they will still need to understand your coding standards and preferred practices within those technologies.

What are some of the things you can do to ensure a new software engineer gets up to speed with the things listed above?

Make Real Changes to the Codebase

In the early days of a software engineer joining your company, give them a chance to make a real change to the codebase that gets pushed to production. Even if the change is really small, such as a text change to the viewer, it will still be valuable. Making any change to the production codebase means the new software engineer has to check out the codebase, thereby exposing them to the source control tools. Additionally, by making the change and running the tests, they are exposed to the structure of the codebase and how to run the tests. When they push up the code and run the tests on a build server and finally deploy the change to production, they learn how the build and integration services work to ship changes to production. Any small change to the codebase allows a new software engineer to understand the full workflow of how something comes from being a requirement to being live on production. So give your new software engineer a chance to make a production change as early as possible.

Pair Programming

In the early days of a software engineer joining your company, they should pair program on most tasks with a software engineer who has been at the company for much longer. Pair programming will allow the new software engineer to learn about your company’s systems, as they will have someone experienced to answer any questions they have and show them how things work. Pair programming will also allow the new software engineer to build confidence as they gain a sense of involvement in the tasks they are working on. Ideally, you want the new software engineer to pair program with different team members so they get to know all their colleagues and also learn from a diverse set of people. The key takeaway point is to never isolate a new software engineer and leave them to solve problems by themselves, as this can lead to frustration and burnout.

Onboarding Documentation

If your company has any onboarding documentation that could be useful to a new starter, you will want to share that documentation with them in the early days. It may be documentation that was specifically prepared to help new starters get up to speed, or it can be general documentation that is also useful to existing team members, such as current architecture diagrams. The important thing here is that any useful documentation is shared early on after someone has joined so they can consume it when they are eager to learn and get up to speed. An important thing to remember about any documentation is that it must be kept up to date else it may give outdated information. If your new software engineers identify any missing or outdated information in your documentation, use it as an opportunity to update the documentation before the next person starts.

Learning Resources List and Training Budget

A new software engineer may join your company having used different tools and technologies at their previous company. You will need to help them with extra learning material for them to get up to speed with your tools and technologies. Your company should keep a list of known effective learning resources a new software engineer can use to get up speed with your company’s tools and technologies. These learning resources could be a list of books to read or online tutorials to view and learn from. People have different preferred learning styles so find out from your new software engineer how they prefer to learn and point them towards the correct resources. Ideally, your company will have a training budget for its employees, which allows the software engineer to spend some of that training budget to buy the aforementioned books and online tutorials. Invest in training your employees and it will pay off when they become productive.

Domain Knowledge

If you successfully introduce a new software engineer to your tools and technologies, you will have an engineer who is confident they understand all your technologies and can write code using the prioritized programming languages. However, software engineering is not just about writing code; it is more involved than that. The code that a software engineer writes must align with a problem their company is trying to solve and actually solve that problem once it is deployed to production. So every software engineer needs to have a good understanding of the business domain they are working in. When a new software engineer joins your company, you need to educate them on what your company does, why your company exists, and what your company goals are.

Induction Training

Educating your new software engineer about the business should happen through some sort of business induction training. How this happens in practice will differ with each company, depending on company size, the complexity of the business domain, and which people in your company hold most of the knowledge. In some companies, it may be enough for the new software engineer to go through the business domain with another more experienced engineer who understands it well or the team product owner who may have more knowledge about how the business operates. In slightly bigger companies, you can have more formalised induction training in place, where each company department hosts a session and explains how they work and what their purpose is. The goal here is to ensure your new software engineer has a full understanding of the business so they may properly code solutions to the company's problem, suggest ideas that will help the business grow, or question requirements when they are asked to build features. You can only do all these things if you have a good understanding of the business and its requirements.

Soft Skills

If you have successfully onboarded a software engineer on relevant tools and technologies and domain knowledge, then you are almost done! You are left with one more area to cover. In a majority of companies these days, people work in teams rather than in isolation. When a new software engineer joins your company, they are likely to be placed in a team where they will be working with other engineers, quality assurance engineers, a product owner, and perhaps a scrum master if you are applying Scrum. Furthermore, your new software engineer is definitely going to interact with other employees from other company departments or the direct users of the software they build. This means every engineer needs to communicate and interact with other humans as they get their work done. This communication and interaction with other people is normally classified as soft skills. The last pillar of onboarding a new software engineer properly is to ensure you help them with their soft skills. This is usually the area most neglected by people in the software industry, but arguably it is the most important. So how do you do help a new software engineer develop their soft skills?

Let Them Lead Team Reviews and Company-wide Demos

Once a new software engineer has settled down at your company, give them the opportunity to present the work they have been doing to other people. This can happen in the regular team review sessions or a company-wide demo of the work their team has been doing. Allowing someone to present their work gives them the opportunity to grow their presentation skills and communication skills. A key skill every software engineer should master is being able to explain a feature they have built to a non-technical person without including any jargon in the explanation. Allowing someone to present their work also gives them the opportunity to show they understand the business and why they built the work they are presenting. Finally, giving someone an opportunity to present to a wider business audience gives them visibility across the company; people will now know who they are and they can approach them later to chat about the work they presented.

Team Building

To help a new software engineer settle into your company and build relationships with their new colleagues, you must organize some team-building activities. Arrange activities that take the team outside of the normal day-to-day work grind. The idea here is that people are able to know each other outside of just solving work problems all the time. Your team can unplug, relax and chat about their lives and general interests outside of work. The actual team building activity is up to you and your team. It could be just a post-work social dinner and drinks event, or an actual booked fun activity such as go-karting. Whatever activity you choose, the idea is to allow people some time off work to get to know each other and build relationships, as this will likely translate to them working better together for your company. For a new software engineer, it allows them to get to know their new team members.

Pair Programming

I’ve mentioned pair programming again here even though I listed it earlier in the tools and technologies section. I believe pair programming also helps one grow their soft skills as it involves communicating and interacting with another software engineer. Coming up with a solution to a problem together and aligning with another engineer despite differing starting opinions helps cultivate good team relationships.

Workplace Culture

Every company has a workplace culture they try to live by. I have listed this here as it is important for new software engineers to have good examples of how to act and behave according to your culture. In the early days, a new software engineer will be watching and learning from existing employees. How you behave as existing employees influences a new software engineer’s future behavior. So all existing employees must be great examples of the culture you have set for your company.

At this point you will have successfully onboarded a new software engineer with tools and technologies, domain knowledge, and soft skills. You have given them a big chance to bring value to your company and be productive as soon as possible and for the long term.

Conclusion

In summary, the goal is for your new software engineer to write code, learn about the company, and get to know their colleagues.

Extra things to note:

• Senior engineers need to be onboarded too. Onboarding well does not only apply to junior engineers.
• The average employee takes upwards of six months to become fully competent in their role. Don’t overwhelm people, check in early and often, and set the right expectations when someone new starts at your company.
• Every person has their own learning styles so onboarding practices will be slightly different for each individual. However, the principles will remain the same.

Thank you for reading, and I hope you found this useful. If you have any questions, find me on Twitter and ask me anything.