We Lost a Senior Engineer to a Team Two Floors Away: the 7 Steps I Use for Internal Transfers Now

A senior backend engineer told her manager she wanted to move to the platform team. Her manager said he would look into it. Six weeks later she had heard nothing, the platform lead had been told the headcount was frozen, and she resigned. She joined a company in Tanjong Pagar, in a role almost identical to the one she had asked for, eleven minutes from the office she was already sitting in.

Nothing in that story required bad intent. It required an absence: no written rule, no route around the manager, no date. What follows is the method I use now, and the structure matters more than any individual conversation in it.

Step 1: Publish the Rule Before Anyone Needs It

The first internal transfer in a company that has never done one is brutal, because the person asking has to invent the process and use it at the same time, in public, while their manager works out how to feel about it.

Write it down before anyone asks. It can be one page and it needs four things: who is eligible, after how long, where the request goes, and what happens next. Twelve months in the current role is a defensible tenure floor and most teams land somewhere between nine and eighteen.

Be explicit about the one thing everybody is actually wondering, which is whether applying is held against you. Write the sentence. "An internal application is not a resignation and is not treated as one." If you cannot honestly publish that sentence, you do not have an internal mobility policy, you have a form.

One detail that costs nothing and changes behaviour: publish the roles. If internal candidates learn about openings at the same time as external ones, through the same channel, the programme reads as real. If they learn about them from a recruiter’s LinkedIn post, it does not.

Step 2: Take the Releasing Manager Off the Gate

This is the step that decides whether the other six matter.

A manager who can block a transfer by not acting will eventually do it, usually with the best intentions and in the middle of a release. The engineer will find out, because people talk, and the next three people who were considering an internal move will skip it and go straight to a recruiter. One quiet block costs you more than the transfer would have.

So route the request to a third party. HR, the skip-level, a hiring committee, it matters less than the fact that the releasing manager is not the first and only stop. What the manager does get, and should get, is real:

• Notice. They hear it from the process, early, not from a calendar invite the engineer forgot to decline.
• A say in the date. Not whether, but when, inside a stated range.
• A backfill commitment. A written answer on what replaces the capacity, before the move, not a promise to discuss it next quarter.

Managers who fight internal mobility are almost always fighting the third one. They are not trying to trap anybody. They are trying not to be left with the same roadmap and one fewer engineer, which is a reasonable thing to be worried about and a solvable one. Our walkthrough of building an engineering backfill plan in Singapore is the companion piece to this step, and the two processes should start on the same day.

Step 3: Treat the Receiving Role as a Real Hire

The commonest way a transfer goes wrong after it is approved is that nobody scoped the destination. The engineer arrives, the receiving lead is pleased to have a body, and three months later both of them are quietly disappointed for reasons neither articulated in advance.

Write the role. Run a proper conversation about it, not an interview designed to catch someone out, but one that establishes what the work is and whether this person wants that specific work rather than an escape from their current work. Those are different motivations and only one of them survives contact.

Both sides must be able to say no. An internal candidate who is declined needs feedback that is usable and a clear statement that they can apply again, otherwise a declined transfer becomes a resignation on a delay. And an engineer who discovers in the conversation that the role is not what they imagined has to be able to withdraw without it being a mark against them.

Step 4: Fix the Release Date in Writing

Four to eight weeks, named on a calendar, written down where both managers can see it.

Under three weeks and you dump unfinished context on the releasing team, which is how transfers acquire their bad reputation. Beyond about ten weeks and the engineer is in limbo, mentally gone from one team and not yet arrived in the other, which is the least productive state a person can occupy.

The date is the deliverable. "After the release ships" is not a date. "Once we have hired the backfill" is not a date, and it is also a trap, because it makes the engineer’s move conditional on a recruitment process they do not control and cannot influence. Start the backfill on the same day you set the release date, and run the two in parallel rather than in series.

Step 5: Run the Handover as Three Tracks, Not One Document

Internal handovers are consistently worse than external ones, and the reason is almost funny: everyone knows the person is still in the building, so nobody writes anything down. Six months later they are deep in a different problem and the on-call engineer is messaging them at 11pm about a service they have not touched since March.

Split it into three tracks, each with a named receiver and a date.

• Systems. Services, pipelines, dashboards, on-call rotations, access and credentials. Every item gets a new owner by name. Anything that cannot find an owner is a staffing problem you have just discovered, and that is useful information rather than a reason to stall the transfer.
• Context. The decisions that are not in the code. Why the retry logic is strange, which vendor contact actually answers, what broke in 2024 and why the workaround is still there. This is the track people skip and the one that costs the most, and it is best captured as short written notes rather than a long meeting nobody rereads.
• Relationships. Who in the business depends on this person being reachable. Introduce the replacement explicitly, in the same channel, before the move date. An unannounced handover means every stakeholder keeps going to the person who left.

Set an end date on the handover and honour it. The alternative, a permanent half-attachment to the old team, is the single most common way a transfer ends up costing two teams one engineer each.

Step 6: Settle Compensation Against the Band, Not the Move

Here is the trap, and I have watched competent Singapore companies walk into it twice in the same year.

An engineer transfers. The receiving lead wants them motivated, so a bump appears. Word travels, because word always travels, and within two quarters applying for an internal transfer has become the fastest documented route to a raise in the company. You now have transfer applications from people who do not want to transfer, and managers who have learned to treat every internal application as a salary negotiation in disguise.

Decide it on level and band, before the conversation with the engineer:

• Same level, same band. The package does not change. Say this out loud early, so nobody spends three weeks hoping.
• Step up in level. That is a promotion that happens to coincide with a transfer. Justify it on promotion criteria, document it as a promotion, and ideally separate it in time.
• Band mismatch between functions. If platform pays differently from product at the same level, you have a banding problem that predates this transfer and will outlive it. Fix the band, not the individual case.

On the administrative side, an internal move within the same legal entity does not change who employs the person, which is what matters for pass and payroll purposes. What does deserve a check is any material change to title, responsibilities or salary attached to the move, and whether what feels like one company is in fact several entities. Have HR confirm before the date is fixed rather than after. The detail is covered in our guide to Employment Pass and CPF mechanics for Singapore engineering hires.

Step 7: Review at Ninety Days, in Both Directions

Three short conversations at the ninety-day mark: the engineer, the receiving manager, the releasing manager.

With the engineer, the question is whether the role is what was described in step three, and if not, where it diverged. With the receiving manager, whether ramp-up matched what they expected. With the releasing manager, what actually broke after the handover, which is the only way you find out whether the context track in step five did its job or was theatre.

Then write down what the transfer cost. Weeks of reduced output, what the backfill took, what the handover missed. Two or three of these and you stop arguing about internal mobility in the abstract, because you have numbers, and the numbers are almost always smaller than the cost of the resignation you avoided.

When the Answer Should Be No

A transfer programme that approves everything is not a programme. There are three situations where I decline and say why.

When the engineer is running from a manager rather than toward a role, the move relocates the problem and usually costs you both people within a year. The conversation to have is about the manager, and it is harder, which is exactly why it gets avoided.

When the receiving team cannot absorb anyone, moving a person into a team with no onboarding capacity produces a frustrated engineer and a lead who concludes that internal candidates underperform.

And when the move is three months old. Somebody who transferred in July and wants to move again in October has not found the right team, they have found a way of avoiding difficulty, and the useful response is a conversation rather than a form.

If the honest conclusion is that you need the capability rather than this particular person in a different seat, that is a hiring decision and not a mobility one. Our full-stack hiring page sets out what the profiles look like at each level in the Singapore market.

Frequently Asked Questions