I’ve recently had the opportunity to both be the new person on a team and to integrate new team members onto a team that I had been a part of for a long time. Having seen it from both sides, I have some thoughts on how to join a new team without driving everyone crazy. It doesn’t matter how you became a member of the new team, everybody starts in the same place, which is to say, not really knowing the code base or the culture of the team. Learning to mesh well with the culture of a new team is almost certainly more difficult than learning to work in a new code base.

The first thing you have to do when you join a new team is check your ego at the door. It doesn’t matter how experienced you are or how many great ideas you have. At the beginning, your job is to be a sponge and learn as much as you possibly can. Just shut up and listen. Read anything you can get ahold of. Eavesdrop when other people are talking about the project. At the beginning, think of yourself as a spy — gathering as much information as you can without drawing too much attention to yourself. I even try to make it a point to try to figure out the answers to questions myself before I ask someone. The digging involved can be very educational, and showing some level of self-sufficiency will garner respect, at least until you make a big mistake that could have been avoided by asking a few simple questions.

One question I try to avoid until I get to the point of saying “our code” rather than “your code” is “Why?” Figuring out why things are done a certain way is important, but “Why?” is a question that can very easily come across as critical, especially when it comes from someone who’s not really trusted. The truth is that the stuff that makes you want to ask why often really is worthy of criticism. Just let it go until fixing it is as much your responsibility as it is anyone else’s.

The second important thing is to immerse yourself in the code style and coding habits of the team you’ve joined. Everybody who’s been programming for more than a month has their own opinion on whether to put spaces inside parentheses (doing so is crazy) or whether braces go at the end of the line or on the beginning of the next line. The team almost certainly has a policy on whether to use tabs or spaces when indenting. Beyond that, the team probably already has its own answers to more substantive questions about how their code is organized and how they deal with separation of concerns. At the beginning, do it all their way. If you have some ideas for improvement, propose them to the entire team once you’ve shown that you’re a team player. Coming in the door and writing code in your style rather than the team’s style is likely to infuriate at least one other member of the team. Furthermore, immersing yourself in the native culture is the best way to learn. People often have very good reasons for doing things the way that they do, and if you’re busy trying to impose your brilliant ideas on the team, you’ll never learn what those reasons are.

The third thing is to focus on service. Look for opportunities to be helpful wherever possible. The biggest mistake I ever made at a job was listening when the director of the group led us to believe that stuff other groups wanted from us was not as important as the things we were building for him. In the end, we had an unpleasantly dysfunctional workplace, and I found myself looking for another job.

The stakes are high. There are two ways things can play out, depending on the team dynamics. A new person who stomps all over the existing culture of the team will tend to be marginalized by the current members and will face a much tougher climb to build credibility. If the team feels confident in complaining to management about the new guy, they’ll in all likelihood try to get them disciplined or fired. If there’s something about the new guy that makes them seem untouchable (the usual scenario is that they were hired due to a prior relationship with the manager), then the current members of the team will leave. In the end, it all comes down to respect and you gain the respect of the team by treating the team with respect.