The time has come: you’re asked to move somebody to another team to help out on another mission-critical project. But how can you “choose” somebody and look into the eyes of the rest of your team members?

Not Resources

Before discussing a few approaches on how to do it properly, let’s get to the bottom of what would be an example of doing it in the worst way possible. It’s pretty simple: treat people like faceless resources. As you can move a chair from one room to another, you can move an engineer from one team to another. A chair doesn’t require any explanation. It doesn’t have any preferences or career aspirations. If it starts squeaking, it must be quickly fixed.

If you ever want to lose the trust of the entire team in one single step - this is it!

But I have a feeling you’re reading these lines not for a disaster manual, so let’s keep exploring ;-)

Transparency

As with many situations in leadership, transparency is a requirement here too. Things that you want to cover with your team because you’re going to be asked about this anyway:

• Why another team needs more people?
• Why can they not just hire externally?
• What is the impact of this move on our and their projects?
• What is the impact of another project on the business?
• What are the requirements/necessary skillset for the person moving?
• What are the main differences in day-to-day work between this and another team?
• Why this move has to happen from our team?

Next, it’s best to openly declare the main objectives you want to reach, principles you’re respecting, and any rigid boundaries you’ve got to respect. For example:

• How many engineers do you need to move, and by what date?
• What kind of prioritization will you apply if there are more candidates than open positions?
• What will you have to do if fewer candidates volunteer than there are open positions?

Overall, it works best to give enough detailed information about the whole situation. It would be best if you persuaded someone to step into the relative unknown, and the less unknown it is, the less scary transition is.

Pitching

Just giving an insight over the needs and context probably won’t do all the job. Every change comes with at least some advantages. It’s now your chance to find words and means to present those advantages. The more personalized this list is, the better. If the receiving team manager has enough trust, authority, and credibility, it’s best if they do it with your support and backup.

However, don’t skip this even if you have pretty weak points to sell. Such pitch provides some positivity lifeboat even if the team move turns out to be a forced one.

Nobody?

You and I dread when nobody (or not enough engineers overall) wants to make a move. But you still have to do it. Well, this happens, but let’s not panic just for now.

First, try to find out if the move date could be adjusted, giving you a little more room for action.

Next, it’s about time to find out the reasons and motivation for “no” answers from the team members. The assumption is that there might be some doubts or outright problems they are seeing that you can resolve to unblock the transfer. Here you will undoubtedly have to collaborate with the leadership of another team and maybe even the leadership layer above you, but it’s always worth the hassle.

Then, try to approach engineers you think would be the best fit and explain why you think so. But don’t only sell, listen very carefully. Then, again, can you reduce or even resolve some of the blockers they’re contemplating about?

A backup plan (but usually a long shot): investigate if cross-moves would unblock this. If somebody doesn’t want to move from team A to team B but would be okay to move to team C, and somebody from team C has been dreaming about working on team B? You’ve got the idea! Roll up your sleeves and figure this out. It will require putting all relationships you’ve been carefully nurturing to gentle use.

If nothing else works, the last thing you can do is select who’s moving by yourself. That will be the last resort. But keep in mind: at this point, your team has already witnessed all the effort and explanations that went into resolving this in a civilized manner. So if you have explained what happens in such a case, this even won’t come as a surprise. There is no need to say that the chance for somebody to leave the company after such development is pretty high, so you have to assess the ratio of benefits and risks very, very carefully.

Execution

Execution of the move itself should be pretty straightforward once you’ve got the who question sorted out. Just a few notes:

• Don’t make “goodbye” events in the same mood as the person would be leaving the company. It’s the other way around - you’re now going to have very well-known colleagues in other teams too! Celebrate this!
• Make sure hand-over of tasks and projects are done flawlessly, including communicating about it.
• Agree who’s handling any bureaucracy changes in advance, so the engineer doesn’t have to waste time figuring it out. Remember, they are there to push something meaningful for the business forward!

Closing Thoughts

Handling team moves concerning individuals, and a good level of transparency can enable these usually agitated and potentially disastrous changes to be an example of drive and alignment. Even if that transparent truth is not very pleasant (who likes to hear their project is not the most important?), the respect for avoiding manipulation and office politics can win you and your team a lot in the long run.

Photo by Ketut Subiyanto