Onboarding: Making the most of joining a new team
Joining a project can be tough. Some things are the same, but there is so much to learn: the domain of the application, the architecture, the environment (usually I am working on a client site), the names of all the people interacting with your team. Oh and maybe finding your way around the code is pretty important too!
Working for ThoughtWorks for a few years, plus some time spent prior to this on a few shortish contracts I have had to get skilled at getting skilled! I believe that a new team member should take a large part of the responsibility for onboarding themselves, rather than leaving all of the effort to the team itself. I present a few tips that help you get through this process with minimal fuss, confusion and broken bones.
Be patient. I don’t think you can hit the ground running on your first day on a project and be as super-productive as you were on the way out from your last project. There will be critical production issues that you won’t be able to help out with. There will be meetings and discussions you cannot reasonably contribute to. There will be code and new technologies you have never used before. This can be particularly frustrating but it’s important to give yourself time to settle in and to learn. In the meantime…
Exploit your newness. A new person on the team is a considerable asset and you should exploit that in your first few weeks and months. As project incumbents, we tend to get very accustomed to the code and the status quo - however much we try not to (and we really try not to!). A new team member can shake this up. I try and use my first month or so on a project to assess what I am seeing and how things work. If you have ideas and suggestions for improvement in what you see, that can be really useful but remember…
Don’t be too critical too early. Sometimes when you arrive on a new project, there may be things that do not make a lot of sense: a choice of tool, technology or practice that no-one appears to question but to you as an outsider seems substandard. It’s worth just hanging back on that criticism just for a couple of weeks. Ask your team mates for back story and try and get their opinions too. It’s alway worth digging around for the reasons first. Then you might be in the position to change things and make a positive contribution to the team.
Write things down. I have sometimes found it useful to write a journal (usually on the bus on the way home). This would generally include some brief descriptions of who I talked to, what they told me and my thoughts about what I was observing. Spending some time at the end of the day fitting pieces of information together and writing it in your own words is a great way of remembering the vast quantity of information you will pick up in those initial weeks.
Spread yourself around. On some teams, the responsibility of onboarding new team members will fall to its lead. This is generally good as they are most likely the ones with the best overall knowledge. However, it is worth trying to spend time with all of your team (perhaps through pairing if that’s what you are about). The benefit is that you take the pressure of your lead who may be pretty busy, and you get to know the project from a few different perspectives. The last new person to join the team, particularly if they joined fairly recently, can also be a good source of information as he/she is likely to be going through the same exercise as you.
Learn T-shaped. I am on a fairly large and long running project. Over time, the domain and architecture have gotten pretty big and complex. I could never hope to understand it all at once. So my strategy was to try and figure out the big picture and understand one vertical slice at a time (hence the T-shape). In my first week in the project, our lead gave me a great overview of the architecture, pen and whiteboard style. He covered the high level blocks of the architecture: applications, integration points, persistence etc. and then ran through some of the key concepts of our domain model. It was just enough information for me to make a start pairing with my fellow developers - admittedly with them doing most of the driving. I would use the down time (pre commit builds mainly) to ask my pair questions about what we were looking at and take another look at the code. Gradually these T-shapes started to get wider and overlap.
Get great at reading code. The ability to read and understand even the nastiest bits of code is a skill that benefits beyond onboarding. But in the initial stages of a project, it’s yet another great information source alongside your colleagues, whiteboards and any official documentation. Chances are it’s better than the official documentation.
From the other side
Although this article mainly focuses on the experience of the onboardee, there is obviously some effort required on the part of the onboarder. Most importantly, you need to give them time to get up to speed. It goes without saying that this needs to be accommodated in any kind of capacity planning you might do.
Find time to explain the important parts of the application but avoid over-long ‘induction’ routines. Ideally, give them the briefest of introductions to the architecture and domain and get them started working with the team immediately. Go into more depth once they have had a chance to get their hands dirty.
You should be approachable when the new team member has questions but try and avoid explaining everything. I always find it much more valuable to be shown how to find something out rather than be told precisely the information I need.
If the new recruit is following the advice I laid out above then they will be doing most of the hard work in figuring things out, but there is a responsibility on the incumbents to tell the story of the project - the history of the team, why certain decisions were made and the battles that were won and lost.
Why should we bring on new team members?
Onboarding is a time-consuming and sometimes difficult activity. It might take many months before the new team member is completely up to speed.
But the benefits should be considered. Building a diverse team of people is a great way of exposing the project to a wide ranging set of viewpoints, contexts and methods. Just as diversity of background and perspective brings valuable dimensions to a team, so can diversity in project experience. Just as much as you need the old guard who have been around a while and know how things work and why decisions were made like that in the first place, having new people join your team with a fresh perspective can give an influx of new ideas and experience that the team might not have experienced before. This will ultimately be of great benefit to the team and project alike.