26
So, you’re the new one … – integrating new people in your project
No comments · Posted by patrick.c in Talk posts
This blog post deals with the mistakes and opportunities you might encounter when you’re trying to integrate new people in the project. The problems range from a too high entrance barrier to overly caring project leads that suffocate new members…
So you attracted a new member…
Especially when you’re team is small, then it’s a big deal when new people join it. You are eager to integrate them, but there are many things you can do wrong and drive them away from your project. It’s not an easy task if you are not used to it to get someone involved. And you always have to take care that you don’t ask too much of the new member or bore him to death. In short: when you have a new member, try to keep him interested but protect him from “information overload”.
“Here read this comprehensive guide…”
There are projects like debian for example, that have a pretty rigid recruiting process. You have to prove worthy for a long period before you gain the rights to really participate. There are other projects out there that also follow this principle, which basically is based on mistrust on new developers. That is understandable for projects that are as big and popular as the debian project for example, but this approach has several disadvantages that you should keep in mind. Your project has the possibility to keep only the “best” developers and discard the ones you don’t like in the process before they can do harm. This sounds good in the first place, but you also discourage many good people from trying to get involved because they don’t like to be treated in this way. And even the people that survived the selection process may turn out as “malicious” in the long run. Long story short: think about the negative implications before setting up a rigid process.
“He joined and was never seen since… :-(“
One thing that you’ll notice very soon is, that people are very excited about your project, do everything to join it and maybe even start some tasks and suddenly they keep a low profile. You’re trying to contact them and receive no answer on your mails, IM messages etc. Many people think that they have done something wrong and repelled the new member. But the truth is that this happens a lot. Sometimes the people will write back a few months later and apologize but most of the times they play dead after they realize that they should have contacted you because they are embarrassed. When something like this happens, think if you might have done something wrong, If you find nothing obvious, you can be pretty sure that it’s not your fault. Long story short: people sometimes disappear because of personal reasons – this is pretty normal, get over it.
“OMG he killed our source code repository…”
When you’re project is very small and new people join, then it’s not unlikely that you want to integrate them as soon as possible into the project. So you’re giving them administrator rights at sourceforge and the password to the webserver to keep them busy and give them the freedom to help in any way they like. This sounds silly if it’s written down in compressed form, but this happens and sometimes this has negative consequences. The new member might damage parts of the infrastructure either intentionally or by accident. This is not unlikely, because especially non-linux/-unix people have often problems with shell access, ftp, file permissions etc. In short: Take care that only people you trust and who know what they are doing get unlimited access to the core infrastructure of your project!
“He is so lazy and always asks dumb questions…”
Some people expect that new members have from the start a complete understanding of the sourcecode and the underlying infrastructure, of course they also should know all the tools they need. If they don’t then it’s their duty to learn it before they ask dumb questions… Another variant of this behavioral pattern could be described as “fire and forget”. You introduce the new member and then he is on his own, without help and guidance. Sadly quite a few projects act like that and many new members get disappointed and leave the project soon. It doesn’t have to be this way and even when this is a spare time project, the “old wise members” should take some time and help the new members. Just because they don’t know everything yet doesn’t mean that they won’t be helpful members after they got properly introduced in the projects technologies and procedures. To summarize it: there are no dumb questions, only dumb answers! Take your time with the newbies it’s worth it!
“I do my very best to help him…”
The direct opposite of the mistake above is that the project is too protective and too “kind”. The new member is bombarded with good advices, links and help offerings. This may as well drive people away. It looks desperate and may drive the new members crazy. Offering too much help introduces a feeling of pressure, even if it’s not meant this way. In short: Don’t exaggerate with help offerings, try to balance between negligence and over caring.
Setting up a process helps
To avoid the problems I have mentioned above, you should think about introducing processes. This might sound boring and you don’t like it, because it reminds you on your work, but clear guidelines help new people to fit in the group and learn the processes that exist anyway, no matter if they are written down or not. Thinking about the processes helps to improve them. Consider for example check-in or code style rules. Every project needs some kind of common understanding in theses areas and new people need to learn these. Without written down rules, they have to do trial & error which can be pretty frustrating. Even harder are social rules like who is responsible for what and who decides when there are conflicts. You should consider if it’s possible to assign a mentor to the new member, so the new one has one dedicated person to ask questions. But the mentor needs to be motivated and willing to help. Otherwise it will do more harm then help. Long story short: By formalizing the internal rules and roles you make it a lot easier for new people to blend in.
Knowing their motivation
Everybody who joins a project expects something in return. Some people like to participate in publicly highly visible projects to get reputation in a field, others just like to code and practice their profession or hobby. Of course there are much more different aspects why someone joins a project, but as a project lead you should try to find out what the motivation is and help the members to get the most joy out of their involvement. You can do this by giving the right tasks to the right people, giving credit to the team or even assigning roles to people, so they can do what they like most.This way you can maintain a healthy project with satisfied members. As a summary: Knowing the motivation of your fellow team members and acting to fit their needs will greatly benefit our project.
Comprehension
There are many ways to drive people away from your project, but there are also many ways to attract them if you do it right. Take your time to introduce new people, maybe select mentors that help the newbies in the first few months. Be clear what you expect from people and where you help them to shape their expectations and prevent them from being disappointed.
communication · early-phase · introduction · social-skills · talk
