I am sure many of you have had some experience with new team members, be it good or bad. Onboarding new developers and teaching them how to become productive, impactful, and confident in their role can be tricky and stressful.

As of this article, a new developer will join my team. I personally have little to no experience in the matter, since I only recently was given the full responsibility to manage my team. However, I have seen good and bad onboardings and am aware of the pros and cons. But I also wanted to dive deeper into this topic and also the literature surrounding it, to ensure a more streamlined, optimized, and overall successful onboarding process for future newcomers.

This article will cover past mistakes and discuss future strategies that I will personally implement.

Mindset

Let's start with more of a paradigm discussion about company culture and what it takes to build an environment that is friendly and collaborative, instead of stressful and fiercely competitive.

Hierarchies

Hierarchies are an important part, not only of human nature but rather of the entire animal kingdom. Therefore, disregarding hierarchies would be foolish. However, they can be controlled and calculated. Yes, there have to be leaders[^1], people "at the top", people who steer the ship, and followers, for businesses to function (and society as a whole really), but that does not mean that leaders are in any way superior human beings compared to followers.

Therefore, I strongly believe that hierarchies should be vaguely implied but not fully enforced. This levels the playing field for discussion, which has perks such as creating an environment where asking questions is the norm, criticism, and feedback are considered and power is distributed amongst the team, just to name a few. Taking the "we are all human beings" approach can greatly benefit teams, since certain social barriers, that are usually attributed to strict hierarchies, are removed.[^1]

Nobody is perfect

Patience is key. Especially with new hires, losing patience can lead to lowered team spirit. You must therefore understand that characteristics such as work ethic, motivation, speed of grasping new concepts, the ability to learn, and many other performance metrics, vary heavily depending on the individual and should be adjusted for, instead of criticized or even punished. You can have complete control over how these characteristics are dealt with, which in turn also puts the responsibility on you, should business relationships fail.

Now, I am not stating that every business relationship has to work, there are certainly times when things are not meant to work out, but I would suggest that putting the responsibility on yourself has a positive impact at least trying your best at building and maintaining good business relationships.

Don't throw them into the cold water

I understand that investing resources into a process that might not work out, because of reasons outside of your control, might seem like a lost cause. However, the average time a new employee requires to become productive is eight months(source), which is even more costly for your company than investing in a proper onboarding process.

Drop your ego

In the context of company culture, ego can certainly become problematic. For example, when Executives refuse to interact with employees "below them", or more experienced employees are met with criticism by new hires and in turn act defensive and out of self-preservation. These and many more scenarios are a result of one's ego being either inflated or hurt. Behavior like this can certainly lead to a competitive, almost narcissistic environment, that will become unsustainable and increasingly toxic.[^1]

If you are met with situations where you are wrong, or someone knows more than you, or you receive feedback, those situations offer the greatest opportunity to grow professionally but most importantly as a person. See these situations as an asset. Especially, when people know more than you, learn from them, utilize their knowledge and teach them things you have learned. Collaboration, like this, instead of competition will over the long term create a stronger, more productive, and most importantly healthier team.[^1]

What went wrong in the past

As already mentioned in the beginning, I have had some sub-optimal experiences with new team members. In this section I will dissect, a few mistakes I have seen in the past, so you can avoid them.

Awkward schedules

I once had a new developer join whose schedule was quite literally in another time zone. This in turn disconnected them from the rest of the team and, as I can imagine, probably felt like a one-man-show most of the time. Of course, there is little you can do about this, but you can certainly try your hardest to find ways to integrate the new team member into the ins and outs of the team.

Inappropriate first tasks

The company I work for provides rather complex business software. Earlier team members were told to first explore said software. Unfortunately, the tasks were not really focused on thinking like a developer about the software and were rather something another department usually handles. New developers, from day one, were delegated the task of building a very complex setup of our software for a very high-level client. In my opinion, this perhaps led to frustration and a lack of confidence for the new team members.

My start at the company, on the other hand, was quite straightforward, therefore I started coding on the first day. I did not start working on the main product, but rather on side projects that had less priority but did provide a lot of value, which in turn built up my confidence in the team.

Being bored or overwhelmed can be detrimental to one's motivation and confidence. As a result, it is important to always check in with new team members to get an idea about how they feel, about the tasks you have given them.

Too much criticism

Although I have nothing against giving peers honest feedback, it does more harm than good for someone new to the team. I remember how the only comments I left on pull requests of new team members were negative and sometimes insignificant nitpicks. This was horribly wrong and had a lot to do with my ego back then. Nothing will crush someone's confidence faster than never receiving any positive feedback. In that case, it is only natural to feel not good enough or even resentful towards the team. In the early stages, stick to praise and only sprinkle a little bit of criticism, in case something really needs change.

Strategies I will give a try

Welcoming new developers

Give new developers a warm welcome and introduce them to the team. If you are responsible for the new member, talk with them and explain your company structure, what tools you use, talk about coding standards and get a feel for their technical competency.

Weekly 1-on-1s

You should plan a short meeting with new team members once a week at least to ask them how they are doing and whether or not they are stuck and need help. Furthermore, you can shower them with praise for things they have accomplished. Most importantly, ask them for feedback.

Give them a feeling of the company culture

New team members should have an idea about what is socially acceptable and "normal" in your working environment, to avoid awkward situations that could make a bad impression.

Strong social bonds

Greatly encourage new team members to socialize with team members and other employees from other departments. Having social bonds early on can have a profound impact on a novice's motivation and productivity.

Talk about expectations

There should be a vague idea of what productivity you expect from a new team member. If your team has implemented some kind of project management framework, this will be much easier, since you have a clear overview of individual and team performance. New members will also have a better picture of how they are doing in the team, but should never feel pressured to perform on the same level or even outperform other team members. Make this especially clear to them.

Also, some people are not productive naturally. What I mean by this is, that they require some kind of plan, schedule, or any other kind of structured process to get going. As already mentioned, preferably adjust for someone's needs in the team, and avoid criticism and punishment.

Have development plans laid out

As mentioned in the section above, people are different, so some team members might require a predefined path to get learning continuously. Lay out development plans that will bring guaranteed value to your team. Most importantly, praise team members, who do sharpen their skills, greatly. You can expect to see a compounding effect when your team invests time into research.

What tasks do you give them?

The most important trait you want to strengthen in your new team member is confidence. This means that the best tasks to assign to your new developer are tasks that guarantee success and have a clear impact. However, there should also be tasks that allow for failure and teach your new team members that failing is okay and that asking other team members for help is preferable. Also, identify their strengths and weaknesses to assign tasks that suit them in the future. In short, build systems that increase the confidence of new developers.

Additionally, elaborate on the impact of the task they are doing, explain to them how and what they are contributing exactly, also define how the task will contribute to their progression in the new position. Lastly, make sure they grasp the requirements.

The onion model[^3]

This strategy is predominantly used in open source software projects but can be utilized for regular software projects as well. In essence, junior developers start with minor bug fixes, documentation, and other small contributions to the projects and steadily get promoted to do more complex tasks. There was a case study about Microsoft's software engineering teams that outlined a similar concept called "Simple-Complex"[^2], which works the same way. This "progressive overload" approach (like in weight lifting) might take longer but can offer greater sustainability and long-term success.

Praise, praise, praise

If your new team member creates their first pull request or achieves something else, praise them greatly for it. They will quickly begin feeling a sense of belonging and being appreciated by the team. Criticism certainly has its place in a working environment, but in the case of new developers, should be avoided as much as possible, since generally people better respond to positive feedback.[^4]

Have a beginner-friendly wiki ready

Now, this is something I myself need to invest a lot of time into and I certainly understand that building a wiki if you have never bothered to do so, will be quite tedious, but if your new developer has some kind of anchor to go with, such as documentation, they will most likely have more confidence working on their own.[^2]

Have documentation about coding standards, processes around coding, some business processes, the product, and the source code itself. Also, have a list of all team members, potentially even with personal touches such as hobbies and interests.

If you do not have a wiki yet allocate resources to steadily add to the wiki so it will be done eventually and start with things that every developer must know, then discuss less important concepts, such as advanced source code documentation.

Have mentors ready for them

Mentors can be incredibly useful for onboarding new developers. They provide a safe space for asking questions and transferring knowledge effortlessly. Some of your team members should be prepared to take on the role of mentor for a new member. Furthermore, the whole team should be able to assist new hires to some extent or at least know who could help them out in the team. This will provide valuable social interactions for the recently joined team member.[^2]

What if they get stuck

As already mentioned, have tasks ready that guarantee success and make it abundantly clear that the team is ready to answer any question the new team member has. Also, set their expectations, about being productive in the team and contributing consistently, straight. It will take some time for them to get going, but that is completely fine, make them aware of that.

Drop their ego

In the same way, you have to drop your ego sometimes, and encourage them to do the same, getting stuck somewhere especially if you feel like you shouldn't be stuck at something "so simple" can feel embarrassing and hurt your ego, drive the point home that asking questions regardless of how trivial they seem to them is better than piling up questions in their head and never giving the team a feeling for how they are doing, this can lead to improper workloads that are demotivating for the team member in question.

What to do if they are afraid of asking questions

In general, if you want other people to do something, show initiative yourself. Ask the new team member questions about a technical concept they are talking about, even if you know about it. Additionally, you can ask them simple questions, such as what a term they are using means, etc. This will show them that you are not afraid of asking them questions and since human beings are empathic animals, they in turn will also be less afraid of asking you questions. This relates to the "drop your ego" section in the "Mindset" section, if they know something you don't know, ask them about it even if you are a senior developer, this will expand your knowledge. You will only reach a collaborative environment and all its perks when nobody is afraid of asking questions, as some leaders or more experienced employees, mostly out of pride and self-preservation, often would be. Asking questions will benefit everybody!

Conclusion

Onboarding new team members can be challenging, but certainly one of the most important skills you have to master to effectively expand your team. A good onboarding process will raise the likelihood of keeping new developers long-term. Fortunately, there are a plethora of strategies you can utilize to improve your developer onboarding experience.

Discussion

The "Mindset" section contains a lot of statements about leadership and company culture that are inspired by the works of Simon Sinek. I would be interested in your opinion on these principles and whether or not you agree with them. Also, have you already implemented some of the listed strategies, if yes, what were your experiences with them? Feel free to start a discussion in the comments section of this blog post.

References

[^1]: Sinek, Simon. 2017. Leaders Eat Last. London, England: Portfolio Penguin.

[^2]: A. Ju, H. Sajnani, S. Kelly and K. Herzig, "A Case Study of Onboarding in Software Teams: Tasks and Strategies," 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE), 2021, pp. 613-623, DOI: 10.1109/ICSE43902.2021.00063.

[^3]: Casey Casalnuovo, Bogdan Vasilescu, Premkumar Devanbu, and Vladimir Filkov. 2015. Developer onboarding in GitHub: the role of prior social links and language experience. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). Association for Computing Machinery, New York, NY, USA, 817–828. doi.org/10.1145/2786805.2786854

[^4]: MLA. Carnegie, Dale, 1888-1955. How to Win Friends and Influence People. New York: Simon & Schuster, 2009