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:
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!
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!
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.
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,