6 Techniques to Successfully Onboard and Keep New Developers
Onboarding a new developer, especially someone with less experience can require some hand-holding, and that's ok. It won't always be needed, and in the long-term the investment upfront in time will yield benefits like loyalty, heightened collaboration, and a stronger team. Active communication and mentoring mean that any gaps in knowledge are filled, and this opens up communication to ensure that any new addition to your team gets everything they need to make it on your team.
In our first post, we looked at how mentoring can ease the challenges of moving to a career in software development. Now we will look at why it is so important to give someone individual attention through mentorship, while acclimating them to a new team. Then, we'll go into some steps and guidelines to put a repeatable process in place for bringing new developers onto a software team, and how that raises the chances of success for the individual and for the whole team.
In particular, we'll talk about using:
- a strong, conscious, onboarding process to help the relationship start off on the right foot.
- regular check-ins (not just stand-ups) that keep two-way communication open.
- periodic, constructive feedback that documents progress (three things you like, one to two things that can be improved, open questions).
- smaller tasks that take less time, that build into larger tasks, that ease someone into how the team works.
- front-loaded pair programming to give and get direct feedback on coding style and standards.
- mentorship training for senior developers, tech leads, and managers to develop soft-skills for everyone's benefit.
The "Soft" in Software
Building software is a tricky business. We spend a lot of time behind a screen looking at other people's code and our own wondering why it doesn't just work. This frustration can seem amplified for new software developers.
What often gets neglected, while we focus on the code and hard skills, are the soft skills that are needed to work on a team. As hard-skills like language mastery, design patterns, refactoring, and application architecture usually take priority over soft skills like working well with others, we have to make sure the collaborative aspect isn't left behind.
A few weeks ago, after a pitch at a Founders Live event, I had a conversation with a business owner who had recently hired and let go a code school graduate, and as a result, had been turned off to the idea of hiring more because of this experience. I wasn't there, but from what I gathered and what I've seen in the past, it went something like this:
- The developer was interviewed and hired for the job and joined the team, receiving a laptop, a link to the code on Github, and a "good luck".
- A week went by and at the end of the sprint, when everyone had some code to demo, this person did not have anything because she had been struggling, apparently, with getting the code installed and working on her local machine, and with the first few tasks which were assigned to her.
- She was given a talk or two about expectations, with no real solution to fix the root of the problem.
- Nothing changed, the plane they were all on continued to nose-dive, and the woman was fired within a few weeks of being hired.
Imagine now, a world where this person could have succeeded in this, or any software development job, if the leadership on the team had taken a different approach. There was obviously a reason why they took a chance on her to begin with, but why did it go south so quickly?
Happiness Comes When Expectations Meet Reality
My first guess is there were some "holes" in her knowledge in how to work on the team, that the team probably expected her to know before she got there. They no doubt asked her technical questions, which she probably answered well from her time studying, and working on code school and personal projects. It's totally possible that technical knowledge was not the root cause of it not working out.
More likely, she didn't know how to ask for help or understand that she could lean on her teammates, if needed. Like where to find answers to technical questions she had not encountered before, setting a time limit on trying to figure something out yourself before asking someone else, who on the team might be good resources for certain areas of the code, and what areas to focus on. These aren't problems that can be wished away. As with most things in leadership, you can expect what you inspect. If you expect that these problem-solving techniques are in place, you have to follow up to make sure they are in place. If you don't, you've wasted everyone's time, including that of the interviewers, the developers on your team, the new developer, and your own.
Waiting for the "Click"
I haven't done this (honest), but in movies, when someone is cracking a safe, they usually have a stethoscope on, and they are listening to the machinery inside of the safe they are cracking for a distinct "click" to know when the tumblers have fallen in place. Similarly, when someone is getting used to a team, or a situation, at some point, everything will just start making sense, and they can then become largely self-sufficient. This happens at a different point for everyone, and once it happens, the team harmonizes to a point where they are really working together as a team and hitting on all cylinders.
Setting Time Boundaries
"Wait, but shouldn't there be a time limit for this 'click' to happen"? Absolutely. No team should have to spend massive amounts of time waiting for this to happen, just like anything else that needs an investment in order to receive some kind of return. However, if you are having problems with onboarding, the way to live without regrets is to do everything you can to support the person.
Usually though, with the right amount of upfront attention, this click can happen before you might expect it, and when it does, productivity starts to take off for the new developer. All you have to do, then, is trust your initial decision to hire, but set a time limit of two or three months, at least, before deciding it isn't a good fit. A few weeks, with no attention at all except verbal admonishment, is a recipe for failure. Again, we can avoid any potential regrets by creating a good set of healthy, onboarding practices bring on a new developer successfully and help the team gel. With these, or similar practices, you can create an environment where the developers on your team can actually succeed, and which strengthens the team, for greater growth, and teamwork.
What follows is a good set of areas to look at when you make a new hire, as well as some specific practices you can include in your onboarding and daily processes to ensure no one is left behind, so your team and morale continue to grow.
1. Conscious Onboarding
When you start at a company, the process is called "onboarding" and some companies have a very formal process for this, while others have something more fluid, or even non-existent. Just having a laptop handed to you, and a README to install the app you'll be working on, is usually not enough, especially in software. This approach immediately sets the expectation that the new hire is on their own.
A better way is something that is popular in the military when you move to a new base or duty station. You are usually assigned a sponsor that makes sure you have everything you need to be successful at your new duty station. On good software teams, I've seen this usually be a senior developer or technical lead that is available to answer questions, so that no one is left behind, and expectations are clearly communicated to the new developer.
What is very important in this process of sponsoring is a belief that the sponsor is there to serve, not the other way around. This instills an attitude of servant leadership, that whatever the developer needs to succeed at their job will be provided, in the way of material resources, or information that will help them succeed. That positivity is infectious, and will pay dividends far beyond the amount of time spent in onboarding.
2. Regular Check-ins
If you aren't doing this already, I would start this practice right away. Yes, we all have code to push, but if you establish with a developer, especially a junior developer, that the door is always open to bring up and address potential problems, you can get ahead of them before they become too big to handle. The most important thing is to adopt an attitude of listening before preaching. All too often, interactions on a software team, mostly pull requests, become a one-way endeavor normally ending with a "just do it this way" from senior to junior. You'll have plenty of opportunities to provide constructive feedback, so just make sure you take time to listen as well. That being said, you also want to provide ...
3. Periodic Feedback
During check-ins, I would take the opportunity to provide direct feedback that shows you're paying attention. This helps the developer feel like they aren't on an island. It doesn't have to be anything too fancy, but some examples might be:
- "I really liked your last pull request. It looks like you're starting to get the hang of the team's code style, and put it into practice in your own PR's."
- "A few PR's ago, I noticed you getting a little defensive when Joe asked you to change a line of code. Remember that PR comments are not meant to be personal attacks. Rather, they are meant to keep a handle on establishing and maintaining a standard of code and though what you had is fine, we are looking to step up our code quality, especially in that area. Here's a blog post that explains why we want that to use that particular pattern instead of the one you chose."
- "I really appreciate that you took some extra time to work with Jim in QA on testing that large feature-set you worked on. That kind of thing really builds trust between our teams, and you really have shown what is possible as far as how we can collaborate."
4. Build Up Momentum
Especially with junior devs, start by handing out smaller tasks, string changes, and bug fixes before handing out a larger task like "re-write the authentication mechanism". Small refactorings, also are fine, and can give them an opportunity to improve their own code, as they look at different ways to solve the same problem. Just make sure you communicate what the problem is, both verbally and in writing, as there is nothing more frustrating than looking at a feature or improvement write-up and not understanding what the problem is that's meant to be fixed.
5. Pair Programming at the Beginning
Pair, pair, pair, in the beginning. As someone who personally likes to go off in a corner and code, I have to really fight the tendency to be a coding lone-wolf, and spend time working on the code with others. The greatest benefit is that it is directly imparting knowledge, especially from senior to junior, but sometimes, going the other way as well. There are plenty of great resources on how to pair effectively such as this post by Jeff Dickey. I'm not a full-time pairing advocate, but if you aren't seeing a lot of improvement and cross-training on your team, this may be a good place to start.
While you do pair, make sure you dial up the patience, and allow the other developer to drive at least a third of the time. Nothing results in learning as fast as getting your hands dirty, so make sure the other developer has plenty to wash off at the end of the day. Nothing results in depleted morale faster than one developer getting impatient with another because they are not typing fast enough, or not knowing as much as the other. If you've deliberately hired for the right attitude, and not just coding skills, you should be in good shape here.
6. Develop your Senior Developers
So, if you didn't hire a team full of soft-skill-expert Fred Rogers', then you will want to focus some time developing them as leaders. All of the above techniques work with senior developers as well, as developing soft skills in them will reap dividends as that behavior is reinforced and replicated down the food chain. Encouraging growth in your senior developer's soft-skills can't be overlooked, and you never want to wait until a "blow-up" happens where tempers flare and egos get bruised. At that point, it might be too late, so it is best to put practices in place to develop and improve interpersonal dynamics between team members as early as possible. I like to say that we, as software developers like to think we are Vulcan, emotionless beings when it comes to our "logic", and our code, but there is so much of what we determine as the best approach, that really comes down to personal preferences. We are certainly emotional just like everyone else.
If you take these tips and try them out, I guarantee you will change the culture of your team for the better, fostering an environment where technical and collaborative growth can actually happen. I would try two or three of them, and stick to the ones that work for you and your team. A good opportunity to try them out is when you get a new developer, which again, can start that hiring relationship off on the right foot.