developer productivityproject managmentUncategorized

Hey, We’ve Got a New Team Member!

I guess you all know the situation. One day or another, you realize that you’ve got more work than you can manage. So your boss adds a new team member to your team. It goes without saying that you embrace them full-heartedly and teach them their new job with all the respect and empathy they deserve. In virtually no time, they are just as productive as everyone else, and they become a valuable part of your team.

Or not.

It’s the “or not” part this article is about. As to my experience, many people are badly prepared for onboarding new team member. Software developers are no exception. Quite the contrary: many software developers are more interested in tech than in people, which doesn’t help to embrace new team members.

By the way, this article concentrates on software developers, but that’s mostly because I don’t want this article to be overly abstract. It’s easy to rewrite this article for almost every other job.

The good news is that almost everybody manages to wiggle their way into an existing team nonetheless. But it could be a much more pleasant experience if given more thought. And it’s simple to do it right!

What does it feel like to be a new team member?

Empathy is the word of the day. Once you start asking yourself how the new team member feels, you’ll automatically do it right. Thing is, more often than not, we’re too absent-minded to even try. Mind you, the new team member has been hired for a reason: your workload is too high to cope. Everyone has started to get edgy, and increasing the workforce is the only solution.

Here’s the catch: increasing the team size reduces the team’s productivity. If you’re lucky, that’s only a phase, but in the meantime, everybody gets beyond edgy. I’ve seen thing getting nasty at this point more than once.

Switching perspectives

You can avoid most of the trouble by switching perspectives. What does it feel like to be a new team member? Well, they enter an established team playing by rules unknown to the newbies. They don’t know much about your business. They don’t know how the established team tackles problems. Maybe they even have to learn a new programming language, a new IDE, a new framework, or whatever. More generally speaking (because it’s a problem common to every branch, not only software development): the new team members have to learn both new people and the rules of a new game. Sometimes that’s easy. Sometimes it’s quite a challenge.


Some strategies to teach a new team member work better than others. Having them read the manual usually does not work. Telling them to browse through the wiki doesn’t work, either. It’s better to reserve three days exclusively for the rookies and to explain everything from scratch. Often it’s also a good idea to do pair programming. That, in turn, depends on the mentee. Many good developers don’t want to do pair programming. Pair programming is a skill that has to be learned, and it’s not attractive to everybody. But if you meet someone who likes the idea, do it. It’s one of the most efficient ways to bring rookies to speed. Even better: you’ll learn a lot, too.

Another good strategy is to assign bug tickets to the newbies. Solving bugs is a relatively straightforward job, but it gives them the opportunity to see many parts of the program, and to understand how everything’s glued together. After a couple of weeks assign more complex tasks to the rookie, such as developing new features. In any case, give them clear guidelines. When everything is new, it’s possible to stray off in many directions. Try to make sure that they follow the right trails instead of getting lost.

Expecting too much

Sometimes a new team member fails, and that can be quite a surprise. Even an experienced Java programmer can run into problems when joining a new team. There are many different strategies to programming. Some people prefer to test using the UI, while others prefer to write unit tests, sometimes ignoring the UI completely. Most people love their debugger, while other prefer the mainframe-style of debugging (i.e. adding log statements). Some people prefer an interactive programming style, while others prefer to start their program outside the IDE from Maven. The first group needs hot code replacement and a powerful IDE, while the latter group won’t even miss it. If you’ve learned to embrace a certain strategy and join a team using the other strategy, it’s hard to get productive. The problem is that embracing one of the strategies often makes it impossible to use the other strategy. For instance, in my former project, we couldn’t embrace the interactive programming style because hot code replacement was broken due to the project setup. Other projects can’t use the UI centric approach because their application server takes too long to start. The worst thing I’ve ever heard was an application server taking one or two hours to start the program.

So you’d rather be prepared for nasty surprises. Even experts and ace programmers run into problems every once in a while. Listen to their complaints, and try to detect warning signs as early as possible.

Gee, that new team member is so stupid!

Well, maybe the new team member is really stupid. Unlikely, but it’s not unheard of. Sooner or later you’ll meet someone who’s not up to their job. But in general, it pays to assume it’s your fault as a teacher. Be patient. Find a different angle to explain things. Don’t show your annoyance to your mentee. Adding to the mentee’s stress level only reduces their capability to learn.

By the way, the Bible calls this behavior an original sin, and it has a point. There’s a fine line between getting frustrated by lazy pupils and arrogance. Being arrogant is tackling the challenge from a completely wrong angle. Mind you: of course you have to teach the new team member even the most basic things. The established team had a lot of time to find a common consensus. The new team member doesn’t know any of the team history. That’s the definition of “new”. But usually, they are eager to help you. If you fall into the trap of arrogance, you’ll ruin exactly this eagerness. Just keep in mind you’re the ace by definition. You know everything about your project. The new team member does not. Come to think of it, it’s no surprise they act stupid. Increasing the team is not so much about you, but about embracing a new team member. On the long run, you’ll benefit from it. But you’d better prepared for a marathon than a short sprint.

Demanding too little

One of the most spectacular failures in my vocational life was when I wasn’t challenged enough. The job was simple, stupid and boring. My brain reacted by switching off altogether. So I wasn’t even up to such simple tasks like copying a pile of papers in a certain order.

In general, developing software is a demanding task, so I doubt this problem occurs very often. But even so, it may happen. If somebody fails at their job, it may be both because of demanding too much and boredom.

I can’t afford to spend time on the new team member!

Oh, yes, you can. If you really can’t, don’t hire them in the first place. Onboarding a new team member requires a lot of time. As a rule of thumb, it takes more time than expected. If you consider them as a distraction to your daily chores, you should either change your mind or communicate it to your boss early. Not everybody is interested in teaching other people. That’s OK as long as everybody knows it. But if someone chooses you as a mentor, the worst thing you can do is to chase away your mentee if they need help. If you really don’t have time to spare, politely tell them and promise to come back later.

Learn from your mentee

Teaching is one of the best opportunities to verify your ideas. If your mentee has difficulties to understand the architecture of your program, you’ve probably chosen the wrong architecture. More generally speaking, your mentee’s difficulties are always a good indicator that something’s fishy.

External consultants

External consultants are a special case. On the one hand, they are usually very experience and have seen a lot of different approaches to solving problems. On the other hand, that makes them fond of standard approaches. If a consultant tells you “it’s non-standard,” that doesn’t necessarily mean your approach is wrong. Sometimes it’s simply different. But beware: being different makes it difficult to add new team members. So this may be a good reason to listen to the consultant.

Another common mistake is to exclude the external consultant from the team. That’s just stupid. Many teams employ external consultants for months and even years. In this case, they are just another team member. Treat them as equals. If you don’t, you’ll probably ruin the consultant’s motivation and their productivity.

Anything else?

I guess there’s a lot to be added, but I’ve already stated the bottom lines:

  • Teaching a new team member is not about you. It’s about them. You’ll benefit indirectly, on the long run.
  • Teaching always takes more time than expected. Be patient.
  • Never get angry, arrogant, or something like that. Keep in mind that the new team member wants to help you. And that it’s easy to destroy their motivation.
  • Be prepared for nasty surprises. It’s always possible someone excels in one situation and fails in another. If they fail, analyze the situation and find a solution everyone’s happy with. This may include assigning that job to somebody else. This is a valid solution, but keep in mind that’s only one of several solutions.

Wrapping it up

Onboarding new team members is a complex process, involving a lot of social interaction. Don’t concentrate on the technical aspect alone. The blogosphere is full of technical discussions, but in reality, projects almost never fail because of technical issues. They always fail because people don’t collaborate.

I’m sure I’ve barely scratched the problem. What’s your experience? Feel free to leave a comment. I’m looking forward to hearing from you!