As with all workplaces, there are hurdles when joining a new project or team.
Luckily, these hurdles almost always have the same root cause! In IT, these can include: ‘How do I know when I’m finished?‘ and ‘Who decides what work is being taken?’, or more technical questions such as ‘What code conventions are we using?’ and ‘How does feature documenting work?’. Sometimes there are unwritten and unspoken rules which only time can make clear to a new recruitee, but at Codit we make sure that the ‘onboarding’ process is thorough. Here are some tips:
Document Technical and Social Conventions
There’s a lot happening within a project, both technically and socially. People talk and debate, and everyone has a different way of working. One way we eliminate any misconceptions and misunderstandings at Codit is to document social conventions. These could seem obvious, but document them anyway! For example, I was recently in charge of introducing new people to the Arcus team. We had several ‘unwritten rules’, including: “Compliment each other on pull requests”, “Speak in terms of ‘we’ on public issues”, and “Assign both owners on external pull requests“. These are both social and technical conventions that are usually mentioned in chats or face-to-face in projects, but can sometimes get lost. Therefore, we documented them in a separate repository to which everyone has access. These ‘rules’ are maintained the same way as our code: together. Everything is up for discussion, but when someone new starts with us, we can direct them to this repository and get them up to speed in no time.
Have Your Own Secret Language
Being in a team is great. You get to decide how you work together and you often form a way of communicating with one another. This is an extension of the above discussion, as the way people talk in a team can be obscure. For outsiders – even for technical people – the way the domain model and technical implementations are shortened, the abbreviations, etc., all feels like code-talk. This is normal, but make sure that your language is also documented in your information repository. Remember, everyone is part of the team!
Imposter Syndrome
It can be daunting entering a new team, and we at Codit do everything we can to make recruitees and new starters feel comfortable. ‘Imposter syndrome’ – the feeling that you don’t have the skills to do your job – is very common amongst people working at such a high technical level, and the first days and initial impressions are critical. To tackle this, the onboarding process could give new members access to an information repository, as mentioned above. Just as important however, is safeguarding making sure that new members feel that their efforts are valuable. Naming the problem is already part of the solution! Team members could even factor in extra time into their planning to guide new members. It’s important to remember that in this situation, there is no quick ‘knowledge transfer’: start with something small to which a new member can contribute, and slowly work together to build on that.
This is what we did on the Arcus team. We first tackled the smaller issues, such as discovering the code and fixing little things. These first steps are very important, because they make new team members feel that they are contributing to the project as a whole. Take your time and be patient!
Teamwork
Building on this, remember that there is always someone smarter in the room on any one thing and any one subject. Software evolves and is not carved in stone. In software development, you have the luxury of changing the fundamentals of our codebase often, which means that nobody is up-to-date with everything. Remember that you’re all on the same team. Everyone wants the project to succeed and it’s good that things are questioned from time to time. Do not create an emotional bond with your code – only then can software evolve into something great. Software by itself doesn’t represent the concrete implementations of your own ideas, but the combination of many different diverse viewpoints.
Conclusion
I could talk about this topic all day, but this small list of ideas is a good first step and place to start. On top of this, remember to talk about it. Ask your teammates how they feel and what they think of the onboarding process. Remember that they may have to do the onboarding next time!
In short: document, explain, and be warm toward each other because teamwork makes dream-work.
Thanks for reading,
Stijn