“Transfer Window” or how we make it easier to move teams

Tom Murton
2 min readDec 16, 2019

--

We recently made it clear to all the engineers at our London office the process on how they could easily move teams, if you want to know why allowing this and making it simple is a good idea read this https://medium.com/@tommurton/stop-that-2-year-employee-chur-6470618aff86 but here is the TLDR.

  1. Recruiting new people takes a long time and costs a lot to get the right people
  2. When people leave, you lose valuable knowledge and experience.
  3. Making this simple keeps people more engaged and happier and happier teams are more engaged, less likely to leave, and studies show actually produce more!
  4. People learn new skills but also bring new skills and experience with them; a win for both sides!

We have always verbally talked about this being possible, but we wanted to write down some guidelines and present it at one of our town halls to show we meant it.

Here are the 3 main routes to move teams that we highlighted.

TEAM SWAP

o If you want to swap with a colleague, then this is the best way; if you both have the same skill set, it can usually be done within 1–2 sprints as it has the smallest impact.

o Make sure you both chat to your Engineering Managers, and they can plan a suitable date; usually around sprint start and end.

SLOTTING INTO AN OPEN VACANCY

o If you want to move into a team that currently has a vacancy, then this is also reasonably easy as the vacancy can switch teams.

o It needs a little more planning as it may mean 1 team ends up with 1 less engineer until the role is filled, this can usually be done within 1–2 months.

o Where are the vacancies? (Description of where we display all teams with vacancies)

MOVING TO A TEAM WITH NO VACANCIES AND NO SWAPPING.

o This one is a little more difficult due to things like space in the pods (this is what we call our team rooms) and current project deliverables. The earlier we find out that you have this wish then the better we can plan for it, in this case, it might be possible in a short time, but it could take up to 3–4 months as it depends on current projects, workload and team.

No matter which route you take, we will aim to do it as quickly as possible.

This, of course, is the current guideline rather than a rule forever, like anything things could change and we can tweak these.

Ideally, we would keep dates on the shorter end, but we want to make clear sometimes it might be a little longer.

Hopefully, that gives you some ideas on how you could do it.

--

--

Tom Murton

Working in software development as an Engineering manager, big fan of Agile, management 3.0 style techniques, Simon Sinek, Dan Pink and good working culture.