Moving engineers between client programmes: rotation, notice and knowledge handover

A programme head at an engineering services firm needs a firmware lead for a new client by the first of next month. The best person sits on another client's programme, which is two weeks from a release. If she moves too soon, the release slips. If she moves late, the new client loses faith. Her manager hears about it from a colleague in the corridor.

Rotation is a normal part of engineering services. Done badly, it costs delivery and trust. This guide sets out a clean process for the programme head who has to make the move.

Moves happen for different reasons and each needs a slightly different conversation. A skills match for a new client is not the same as a development move for an engineer who has been on one programme for years, and neither is the same as a move to cover an exit. Write the reason in one line. If it is hard to write, the plan is not ready.

• Demand: a new or expanding client programme needs the skill.
• Development: the engineer needs wider experience or has stayed too long on one stack.
• Cover: someone else is leaving or on long leave.
• Fit: a conflict or a mismatch on the current programme.

Client contracts often name key people, set minimum notice for changes or require consent. Some clients also hold access credentials in the name of one engineer. Look at the contract before telling anyone. If a clause is unclear, ask your own legal adviser how it applies. The facts of each contract decide the answer.

1. 1

   Name an owner and a date

   The programme head owns the move. Fix a handover window and an expected start date on the new programme. Share both with the HR contact.

2. 2

   Talk to the engineer first

   Explain the reason, the new role, any change in reporting line and what stays the same. Ask for concerns and note them. Do not announce before this conversation.

3. 3

   Inform both programme leads

   The outgoing lead agrees the handover window and names a successor. The incoming lead confirms scope, tools and a starting task.

4. 4

   Inform the client in the agreed way

   Follow the contract. Tell the client who is leaving, who is replacing them, how overlap will work and who to call during the change.

5. 5

   Run the handover

   Use the checklist below. Hold at least two overlap sessions, one to explain and one where the successor does the work while the leaver watches.

6. 6

   Close the move in writing

   Update the role, reporting line and access in HR records. Remove access to the old programme on the day the handover ends and record it.

Repositories, branches and build instructions, with a successful build by the successor.
Test environments, devices and how to reset them.
Credentials and tokens: list what exists, transfer ownership through the proper process, never share a personal login.
Open issues, known defects and risks, with the last update on each.
Client contacts, meeting rhythm and any standing agreements.
Decisions made and the reason, with links to the records.
Work in flight, next three tasks and who picks each.
Documents that exist and documents that only live in the leaver's head.
Successor sign-off that they can run the work alone.

The last line matters most. A successor who has only listened has not yet learned. Ask them to do a real task while the leaver is still there.

An internal move needs a reasonable notice to the engineer, and the right length depends on your policy, the contract and the programme calendar. Do not announce a move on Friday for Monday. Give the engineer time to finish open work, take leave they have booked and prepare. If the move involves a change of location or terms, treat it as a separate conversation and have the paperwork checked.

Also think about the person receiving the move. A new programme means a new client, new people and new tools. Give the engineer a buddy on the receiving side and a clear first task for the first two weeks. Ask how it is going at the end of the first month, and write down the answer. Early friction is easy to fix and costly to ignore.

The engineers who stay absorb the change. Tell them why the move happened, who now holds the lead role and what will change in their work. If you hide the reason, they will invent one. Check in with the team two weeks later and ask what is still unclear.

A simple register of who moved, when, why and how long they stayed on each programme helps you spot patterns. If the same engineer is always moved to fix problems, they may burn out. If no one ever moves, skills narrow and exits rise. The employee movement process page describes how we help firms design this record and the steps around it.

Rotation is also a knowledge risk when someone resigns instead. The post on notice and handover in IT services covers that case, and our note on product engineering firms gives wider context. The same discipline applies to the lab and prototype access rules when a move involves hardware.