U.S. · Offshoring Process
Moving Work Nobody Wanted to Hand Over
By Trang N.
Headquarters set the timeline and the business case was sound. The people who knew the work were the ones least motivated to explain it. What the constraint forced, and what I would decide the same way again.
Knowledge transfer
Cross-cultural teams
Change management
What happened
Into my second year as a pension benefits analyst, our headquarters decided to move part of the work on two large accounts from our U.S. office to delivery teams in Manila, the Philippines. The business rationale seemed straightforward: the company wanted to reduce cost. Nobody in our office had been consulted — most of us did not know the Manila office existed. We learned about it after the decision was made, with a three-month window already set, and were asked to begin.
The work being moved was manual data and payment processing. Between the two client projects, about fifteen people in the office were affected.
The problem nobody put on the plan
On the email, it was a task transfer. In the office, it was something else.
The U.S. processors were asked to train the teams that would take over their tasks, without any explanation of what would happen to their own roles afterward. Some of them were near retirement. A flood of questions went to project managers who had no answers. The initial training trial ran, and the necessary details did not travel. Once Manila teams began working through test cases, a steady flow of complaints about their errors followed — some genuine, some gathered into a case that the arrangement was costing more than it saved.
Project managers were caught in the middle. They had to implement a decision they did not make and could not explain, while keeping client work running and trying to reassure their own team members about job security.
A knowledge transfer has an obvious dependency: the people who hold the knowledge have to share it.
Why I stepped in
As an analyst working on calculations for both accounts, the task transfer did not immediately affect my role, except changing who I communicated with — Manila instead of the U.S. processors. Although it was not my responsibility, I told Pam, the project manager on the first account, that I would coordinate the transfer, and she agreed.
My initiative came from two reasons. Practically, the transfer was already struggling with in-house resistance and complaints, and errors coming back from Manila would eventually become my problem — incorrect payments and data entries that needed recalculation, and recalculation meant more work for me, other analysts, and technical reviewers. I could already see the domino effect of getting the process wrong, and I wanted to address the underlying issues before they became a larger burden for the whole team.
The second reason was personal. As a non-immigrant worker, I had been in positions where I had to prove I belonged before anyone assumed it. That gave me some sense of what the Manila team members were facing: new people, in another country, being handed unfamiliar work by counterparts who did not want to share the knowledge behind it.
What the work actually required
1Decision one: learn the process before teaching it
The first thing I did was not about training anybody. It was to learn the process myself.
The task looked like data entry — receive a completed calculation, verify the participant’s signed documents, enter the payment for the trustee to issue. Entering it correctly required knowing the plan terms, the tax treatment, when a calculation and its payment could be separated, when to go back to a participant for information, and how to handle exceptions: QDROs from divorces, non-qualified plans, beneficiary changes. The visible task was a screen. The knowledge behind it was years deep and undocumented.
I spent the opening weeks sitting with the U.S. processors and working through cases until I could follow the reasoning rather than the sequence. It also changed the conversation with the U.S. processors — asking someone for their documentation is a request they can slow down, but asking them why a particular exception is handled a particular way is a conversation between two people who both know the work. Sitting with them for weeks meant I heard what they were actually worried about, which was never the thing they raised in meetings. The documentation we gathered and compiled in that period became the knowledge guide that our project ran on afterward.
2Decision two: build a loop, not a handoff
Headquarters treated training as an event. Test-case errors already showed the hand-off model would not guarantee quality. After weeks of gathering documents and working with U.S. processors on real cases, I structured the training in the second month into four stages.
| Stage | Duration | What it established |
|---|---|---|
| Advance material | 1 week before start | I sent documents ahead of time, so Manila came prepared with questions |
| Formal training | ~2 weeks | Plan terms, documents, processing, systems — broken down to one process at a time |
| Shadowing | ~1 week | Manila observed U.S. processors working on live cases |
| Reverse shadowing | ~1 week | U.S. assigned cases to Manila, observed and commented as Manila worked |
I organized it so every session had an agenda and an owner, rather than falling to whichever processor was free. Then it continued past the deadline: complicated cases were walked through on a call rather than corrected quietly by me or any U.S. processor, so the reasoning transferred with the fix. During all sessions, I encouraged Manila teams to ask questions for any clarification they needed, fostering an environment where both sides were treated as equals.
3Decision three: hold the single channel
After weeks of training and daily contact, the U.S. processors still would not raise issues with Manila teams directly — errors came to me and I carried them across. Eventually, Pam and the team made me the point of contact for the working relationship between U.S. and Manila teams. This solved the problem the timeline could not afford.
To keep both sides aligned, I actively reached out to both teams with any question, change, or decision as soon as it happened, so nobody was working on old information. Every critical correction went through one person, so the process interpretation stayed consistent, the same fix reached everyone, and the teams were working from the same version of how the work should be done — increasing transparency, work quality, and communication.
The outcome
The teams stabilized within the three-month window, and quality continued improving over the next five months. Processing ran at roughly a quarter of the previous cost, which was what headquarters had asked for. The training documentation had become something better than the folders we started with — a consolidated working reference, continuously updated as new changes happened.
The part that was not in the business case was what happened to the roles. U.S. processors moved from doing the work to reviewing it and picked up lighter calculation work. Analysts moved toward complex calculations and broader scope. Nobody in our office lost their job during my time there — the work moved down a layer and the complexity moved up. That applied to me as well: after the transfer held, my project manager began showing me the cost and scope side of the account, and later offered to train me on billing and project management. I had not asked for either.
What I would do the same way again
I did not go into this assignment with a philosophy about giving work away. I volunteered because the work needed to get done and I understood the process. The conclusion came afterward, from watching how it resolved.
The people who held their work most tightly ended up with the least room to grow. I transferred everything I knew about a process and came out with a wider role. It is not generosity being rewarded, but that someone who has finished transferring their knowledge is available for the next opportunity, and someone who has not is still doing the same work.
01
Learn the work before teaching it. Collecting someone’s documentation is not the same as understanding their reasoning, and reasoning cannot be taught by someone who has not followed it.
02
Build the transfer as a loop, not a handoff. Teach, observe, then be observed, and keep correcting live cases together when needed — repetition increases capability, and the training is the beginning of the transfer, not the whole of it.
03
Treat resistance as information. When people withhold knowledge, it can signal delay, unwillingness to collaborate, or mismatched expectations. The longer it goes unaddressed, the more it costs. Ask people how they want to work together, then implement changes around the answer, or explain why it is not possible.
What the people on both sides said
“…On with the training, she was well-prepared. She explained the history and the fundamentals of Comerica, making it easier for us to understand why we do pension for them. Before proceeding with the actual process, she first made us understand the E2E of pension. She handed us a complete and straightforward process guide. She was an effective trainer and a patient teacher as well. We were able to grasp the whole process in one sitting…”
“…She has PM’ed several projects for Comerica over the past year with little supervision, including the process documentation, training and continued coordination with the Manila team, which has been very successful for Comerica. She managed phase I and is now assisting and overseeing phase 2. Our Manila team is well informed and any issues that are identified are immediately reported to Manila through Trang…”
The processes described are generalized from work on two large pension administration accounts. Quotations are unedited apart from marked omissions. This is my own writing, drawn from first-hand experience. You’re welcome to link to it or quote briefly with credit; if you’d like to use more of it, please get in touch.
Connect