TL;DR: An internal transfer succeeds when both managers agree on the change in responsibility, the former team has a named owner for unfinished work, and the employee can begin learning the new role without carrying an indefinite second job. Plan the handover around decisions and recurring obligations, then test whether someone else can perform them. Keep any post-transfer help bounded, visible, and agreed with the new manager. A start date alone does not transfer ownership.
Six weeks, two managers, one employee
The fictional company Larch has approved Omar's move from customer implementation to product operations. His new role begins in four weeks. The following six-week calendar includes the four weeks before that date and the first two afterward. It is an original planning example, not a recommended notice period or a statement of employment law.
Omar's current manager wants him to finish an important customer rollout. His future manager wants him ready for the next product planning cycle. Both requests are understandable. Together, they may exceed the time available. If Omar accepts each separately, he becomes the person expected to reconcile an organizational conflict without the authority to change either commitment.
The first task is therefore a shared conversation. What work will end, what will move to another owner, and what will be postponed? Who decides when an unexpected request arrives? Which date changes Omar's reporting relationship? Which date changes responsibility for customer decisions? These dates may coincide, but the plan should state that explicitly rather than assume it.
GitLab's public promotions and transfers handbook offers one concrete employer example: managers align a transfer plan and date, and functional changes can require new onboarding. Its policy belongs to GitLab and can change; it is not a universal employee entitlement. The broader planning lesson is that an internal move involves both departure and entry, even when the person remains in the same organization.
Week minus four: negotiate the capacity before the checklist
Omar brings an inventory of existing commitments to the joint meeting. He does not arrive with a promise to complete everything. The inventory separates work that must be finished before the transfer, work another person can continue, recurring responsibilities that need a new owner, and proposals that have not yet become commitments.
This distinction prevents a familiar mistake: treating every item in a personal task list as a binding obligation. Some tasks may have become irrelevant. Others may be useful but lower priority than the transition. The current manager must decide which work the team will stop or defer. Omar can explain consequences, but he should not quietly absorb the cost of preserving every item.
The managers agree that the customer rollout will transfer to Nina after its next review. Omar will complete the current configuration note and conduct two handover sessions. A proposed reporting redesign will be paused. The new team will protect Omar's first week for onboarding rather than schedule him as fully productive from the first morning.
They also agree on a temporary allocation for the final two weeks before the move: three days on the former team's transition and two days preparing for the new role. The allocation is a planning assumption, not a guarantee that every day will divide neatly. If urgent work changes it, both managers will discuss which commitment moves.
The key output is a small agreement about tradeoffs. A detailed checklist added before that agreement would only make the overload more legible. Capacity must determine the plan; the plan should not imply that a finite employee can satisfy two unlimited queues.
The inventory needs more than open tickets
Omar's ticket list captures visible project work but misses the responsibilities that have accumulated around him. He answers a recurring customer question, approves a weekly report, knows which person can resolve a data discrepancy, and receives informal requests because colleagues remember that he helped last time.
These responsibilities need different treatments. A weekly approval requires a formally recognized successor. A historical explanation may need a document. An informal request route may need a communication change. Simply copying all of them into a task tracker does not create ownership or authority.
Omar makes an obligation register with a plain-language question for each entry: “What would fail, wait, or become ambiguous if I were unavailable tomorrow?” That question surfaces work that rarely appears in project plans. It also helps him distinguish genuine operational dependence from personal preference about how things should be done.
Each entry names a future owner, an escalation route, and the evidence that the transfer has happened. For the weekly report, evidence is that the successor has produced and reviewed one complete cycle. For a customer relationship, evidence includes an introduction and an explicit statement about who can make decisions. For a shared inbox, evidence includes the appropriate routing and access changes.
An owner is a person or role with accepted responsibility, not merely the name typed into a document. If Nina has not agreed or lacks capacity, the register should show that the assignment remains unresolved. Recording uncertainty honestly gives the managers something to decide; pretending it is settled pushes the problem into the first week of the new job.
Week minus three: explain decisions that documentation cannot infer
A handover document often describes what happens during normal operation. Omar's successor also needs to know why the process takes that form and what to do when the normal conditions fail. The difference matters because a procedure without decision context can be followed correctly in the wrong situation.
For the rollout, Omar records the customer's approved scope, outstanding decisions, assumptions awaiting confirmation, and the person authorized to accept changes. He distinguishes settled agreements from his own recommendations. Nina should not have to infer which statements are commitments by reading the tone of an old message.
He then selects two past exceptions to discuss. One involved a missing data field; another involved a late request that would have changed the delivery date. The point is not to narrate every difficult week. It is to show how decisions travel through the organization when the standard process is insufficient.
The session is structured around Nina's questions. If Omar spends the entire hour presenting his accumulated knowledge, he may feel that he has transferred it while learning little about what Nina can now do. A better session ends with Nina explaining how she would handle a plausible new exception and identifying what she would need to check.
Do not treat a handover as permission to disclose everything the departing employee knows. Some personnel, customer, or commercial information may be restricted. Share the information appropriate to the successor's role through approved systems, and involve the relevant owner when access is uncertain. Knowledge transfer should preserve the organization's boundaries rather than bypass them for convenience.
A worked capacity calculation
Suppose Omar has twenty working days before the formal transfer. In this example, the agreed allocation reserves four days for new-role preparation, leaving sixteen for current work and handover. Already scheduled leave and mandatory training consume two of those days, leaving fourteen. That is the available planning capacity before ordinary interruptions are considered.
The current team's initial request requires eight days to finish the rollout stage, four days of recurring operations, and five days of handover preparation and practice. The total is seventeen days. The plan is already three days over capacity, even before any unexpected work. Calling the transition “manageable” would not change the arithmetic.
The managers can reduce scope, add qualified help, move a date, or change the new-role preparation allocation. Omar should describe the consequences of each option. For example, removing all practice time may make the calendar fit while leaving the successor unable to operate independently. The capacity problem has then been moved into the future rather than solved.
They decide that Nina will perform two days of the rollout work with Omar reviewing, and that one day of low-priority reporting work will be deferred. The revised total fits the fourteen-day allocation. This is still an estimate, so the plan includes a review after the first handover session. Estimates become more useful when their assumptions remain visible and can be revised.
The numbers are deliberately simple. Their purpose is to expose incompatible commitments, not to calculate a precise probability of success. A more elaborate spreadsheet would not improve the plan if the managers were unwilling to choose which work should change.
Week minus two: let the successor operate
Nina now runs the dependency review while Omar observes. She sends the agenda, identifies unresolved questions, and records decisions. Omar answers questions that require historical context but does not automatically take back the meeting when a participant addresses him out of habit.
This is where the handover becomes real. Participants need to experience Nina as the owner. If Omar continues making every decision because he can do so faster, the group learns that the transfer is ceremonial. A brief reduction in speed may be an acceptable cost of establishing actual responsibility, provided the work's risks are managed.
The review reveals a missing permission: Nina can see the report but cannot approve the next stage. The problem is not lack of knowledge. It is a mismatch between responsibility and system access. Omar records it for the appropriate administrator and manager instead of sharing credentials or making approvals under his own identity on Nina's behalf.
A second problem is less technical. The customer still expects Omar to answer every scope question. The account owner introduces Nina and states when she becomes the primary contact. Omar can remain available for a bounded historical question, but the customer should not be left choosing between two people whose authority is unclear.
Practice should include at least one ordinary cycle and one plausible exception where feasible. The goal is not to rehearse every possible failure. It is to discover whether the successor knows where the instructions end, who can make an exception, and how to obtain help without restoring the previous owner's permanent responsibility.
The future manager has work to do too
An internal employee knows the company, but that does not mean they know the new team's work. Omar may understand the organization's vocabulary while lacking the product operations team's priorities, decision rules, and relationships. Familiarity can make these gaps less visible because people assume he already knows how things function.
The new manager identifies an onboarding partner, the first bounded assignment, and the decisions Omar should initially observe before making independently. They discuss what prior experience transfers and what requires fresh learning. An internal move should not convert confidence in the employee into an expectation of immediate mastery.
The OPM career development guidance describes development planning as a way to connect an employee's growth with organizational needs. In Omar's fictional case, that connection means choosing an initial assignment that both serves the new team and exposes the knowledge he needs. It does not mean adding an unlimited training program on top of two full workloads.
Omar also asks how previous performance information will be used. Relevant accomplishments and development areas should not disappear merely because the reporting line changes. At the same time, the new manager should assess performance against the new role's expectations rather than import every judgment from a different job. Continuity of context and freshness of evaluation can coexist.
Week minus one: communicate the change to the people who depend on it
The transfer announcement is often written as a celebration: Omar is moving to product operations, and everyone wishes him well. That message may be welcome, but it does not tell colleagues where to send tomorrow's question. Operational communication needs a different level of specificity.
The current manager sends a concise note identifying the effective date, new owners for recurring work, the route for unresolved rollout questions, and the limited purpose of any post-transfer support. The message avoids exposing private career discussions. Its purpose is to change the flow of work, not explain every reason for Omar's decision.
Omar updates the permitted documents and team surfaces that still name him as the primary owner. This might include a project page, a shared calendar, or an escalation guide. He does not indiscriminately delete historical attribution; old records can remain accurate while current routing changes. The relevant distinction is between who performed past work and who owns future work.
The managers also agree how to respond when someone ignores the new route. Omar can forward the request to Nina and explain the ownership change. He should not quietly complete it and then complain that the former team keeps depending on him. The organization needs consistent signals, especially during the first few weeks.
The day before the move: resolve what remains unresolved
A final review should not pretend every item is complete. The useful output is a truthful list of what transferred, what remains open, who owns it, and what support has been agreed. An incomplete item with a clear owner is often less risky than an item marked complete because nobody wants to delay the transition.
Omar and Nina review the rollout's remaining assumptions. One customer approval is outstanding. Nina now owns following it up, while the account owner retains authority to negotiate scope. Omar's role after the move is limited to explaining a historical configuration decision if needed. The open approval does not itself justify retaining him as the project owner.
The managers check that the promised handover work matched the actual capacity. If a material new issue requires extra help, they decide how that help affects Omar's new commitments. They do not use a general phrase such as “available as needed” to postpone the decision indefinitely.
The OPM performance management cycle emphasizes setting and monitoring expectations. Applied here as a management principle rather than a required process, it suggests that a transfer should update the expectations under which work will be evaluated. Omar should not be assessed as though he spent the same hours on both teams.
Week plus one: bounded help is different from a second job
The agreed support window is two thirty-minute sessions during Omar's first week in product operations, plus escalation through the managers for an exceptional issue. This is a fictional arrangement, not a universal recommended duration. Its value is that both teams can plan around it and distinguish ordinary questions from work requiring a new decision.
During the first session, Nina asks why a configuration option was excluded. Omar explains the original constraint and points to the decision record. Nina decides whether that constraint still applies. Omar supplies history without reclaiming authority. This separation lets the successor use the past while remaining responsible for the present.
A more substantial request arrives later: the former team wants Omar to redesign part of the rollout. That is new work, not clarification. He sends it to both managers with an estimate and identifies the new-role task it would displace. The managers can approve the tradeoff, assign someone else, or defer the request. The important point is that the cost becomes visible.
A helpful employee can still set a clear boundary. “I can explain the earlier decision in our support session; implementing the new change would require reprioritizing my current assignment” is more useful than either silently accepting the work or refusing every question. It names the distinction the organization needs to manage.
Week plus two: close the handover without erasing relationships
At the end of the support window, Nina and the current manager confirm the remaining owner assignments. Omar's former team can still contact him as a colleague, but the default expectation has changed. Familiarity does not create an indefinite service obligation.
The closing review asks what the transition revealed about the work. Did an important procedure exist only in Omar's memory? Were access rights tied too closely to one person? Did customers lack a clear escalation route? These are team design questions, not evidence that Omar should never have moved. The transfer can expose dependencies that would also matter during leave, illness, or growth.
Omar records a small number of lessons for future handovers. He avoids writing a grand process for every possible internal move. The useful improvements are specific: maintain a current owner field, document exception authority, and test critical recurring work with a second person before a transition becomes urgent.
The new manager then reviews the first assignment with Omar. What did he understand quickly? Where did old assumptions lead him astray? What support would help next? This conversation marks the shift from being someone who is leaving one team to someone who is learning and contributing in another.
A transfer can change the meaning of familiar information
Omar's move also changes what he should receive automatically. A mailing list that was useful in implementation may now deliver customer details unrelated to his product operations work. A dashboard may remain relevant, while an approval permission no longer is. The transition should include a role-based access review through the organization's established process rather than an assumption that internal employees keep everything forever.
This review is not a request to delete historical work or remove access impulsively. The managers and system owners need to identify what the new role requires, what the handover temporarily requires, and when temporary permissions should end. Removing access before Nina can perform the work could create an operational gap. Leaving unnecessary authority indefinitely creates a different problem. Dates and responsible owners make the sequence manageable.
The same reasoning applies to meetings. Omar may remain on recurring invitations because removing him feels impolite. Yet continuing to attend every former-team meeting consumes the time reserved for learning the new role and encourages participants to keep treating him as an owner. He should retain meetings with a clear current purpose and decline the rest with an accurate explanation of the new contact route.
Some relationships should continue informally. Omar can still exchange professional ideas with former colleagues or join a social conversation. The handover does not require social disappearance. It requires a distinction between maintaining relationships and silently continuing accountable work. Making that distinction explicit preserves collegiality while allowing both teams to understand where responsibility now sits.
When the managers cannot agree
Sometimes the current manager refuses to release the employee until a replacement arrives, while the new manager insists on the original start date. Omar cannot solve this conflict by promising nights and weekends. He can make the competing commitments explicit and ask the appropriate organizational decision-maker to resolve them under the employer's actual policy.
The relevant evidence is concrete: the agreed date, outstanding responsibilities, expected effort, operational consequences, and available alternatives. Avoid framing the problem solely as whether one manager supports the employee's career. Personal support may matter, but an unresolved resource allocation still needs an accountable decision.
A temporary extension can be reasonable when its purpose, duration, and consequences are explicit. Repeated extensions without a defined endpoint are different. They prevent the new team from planning and leave the employee evaluated against two changing sets of expectations. The employee should ask what condition will end the arrangement and who can determine that the condition has been met.
The strongest transfer plan does not require every relationship to be frictionless. It requires decisions to be made by people with authority, ownership to be accepted by people with capacity, and the employee's time to be treated as finite. That gives the new role a real beginning and the previous role a responsible ending.