Dealing with the arriviste problem

Yesterday I described what I’m calling the arriviste problem - when a new team member joins and immediately wants to start making sweeping changes.

To jump straight to the end, there are few ways you might deal with this:

1. Fire them - you don’t need people like this ruining the balance of the team
2. Wait to see if someone in the team brings it up in the next retrospective
3. Privately ask other members of the team what they think
4. Talk to the new arrival immediately and tell them to cool it
5. Tell them flat out that you won’t be changing anything in the near future
6. Ask the new arrival what they’re hoping to achieve
7. Do nothing and hope the problem goes away

Which of these approaches you take will depend on the situation, though some are almost always bad - I’m sure you can tell which ones!

First of all, it’s important to understand why this kind of behaviour is a problem:

• Criticism without consideration of context is almost always taken as a personal attack on existing team members’ abilities. This needs to be addressed for what it is.
• This approach to improvement may not match the culture of the team if it’s based more on collaboration and shared responsibility than heroic individual contributions.
• Behaviour like this can be an explicit or implicit power play, which has to be dealt with on some level.

It’s important to remember that the intention behind the behaviour isn’t necessarily all sinister. Your initial reaction to it might be strongly defensive, but it’s important not to lash out in response.

The arriviste might be insecure about their technical ability and have chosen to deal with that by showing it off quickly.

Or perhaps they’ve been added to the team because of specialised expertise, e.g. a CSS specialist in a team of full-stack developers. In this context, strong and early criticism might be more expected, even if it is handled clumsily.

There’s a tricky balance to be trodden between taking advantage of the new person’s capabilities on the one hand, and ensuring that they don’t damage your hard-won team morale and productivity on the other.

If you are a team lead in this situation, it’s your responsibility to provide feedback quickly. Help the new arrival understand the effects of what they’re doing. Ask them what they are trying to achieve, and teach them better ways of achieving those goals.

Often the problem comes down to an under-appreciation of empathy as a way of building trust. Trust is not there just because they’ve earned a place in a team that already trusts each other. Each new team member has to earn it.

Trust is best earned by taking the time to listen and explore what the current situation is without snap judgement of previous decisions and work. For a team lead, this can take a bit of coaching and a few feedback loops.

If you don’t see an improvement in respect or attitude after a while, then it’s time to consider other options. After all, if someone is added to a team because of their expertise, they should be maximising the time they spend teaching that expertise to others, not just wielding a Big Decision hammer all over the place and causing all sorts of collateral damage in the name of better code.

All the best,

– Jim