She was excellent. The technical process had been careful, the offer competitive, the team genuinely pleased. Five weeks later she resigned, and in the exit conversation she said something I have thought about ever since: “I could do the work. I just could never tell whether I was doing it right.”
What actually went wrong
Three things, none of which appeared in any status report.
The working language drifted. Interviews were in English. Stand-ups were in English. But the design discussion that decided the shape of the feature happened in Japanese, in a channel she was in but could not follow, and the decision reached her afterwards as a conclusion rather than as a conversation. Nobody excluded her. She was simply absent from the room where the work was decided.
Nothing shipped for three weeks. Local environment issues, then a permissions problem, then a review queue. Each individually reasonable, cumulatively devastating: three weeks of effort with nothing to point at, at exactly the moment when a new person is trying to establish that they were a good decision.
There was no first-question person. We had told her to ask anyone. In a new team, in a second language, “ask anyone” reliably means ask nobody, because every question requires first choosing a target and estimating how much you are interrupting them.
None of these are Japan-specific problems, but each of them is amplified here, and together they are the reason a strong hire concluded within five weeks that the role was not the one described.
Step 1 — Settle the working language in writing before day one
This is the step that would have prevented the departure on its own.
Both answers are legitimate. A team can operate fully in English, or it can require conversational Japanese for design discussions. What fails is the unstated middle: a role advertised as English-speaking where the decisions happen in Japanese.
Write down, before the start date, four specific things:
- Which meetings are in English, by name, not in general.
- Which written artefacts are in English — design documents, incident reports, code comments, commit messages.
- What happens when a discussion switches to Japanese: does someone summarise, does the decision get written up afterwards, or is the person expected to follow?
- Whether Japanese ability affects progression, honestly. If senior roles in practice require it, say so at offer stage.
This document costs an hour and eliminates the single most common cause of early departure among foreign engineers in Tokyo. It also filters candidates before they join rather than after, which is considerably cheaper for everyone.
Step 2 — Clear the day-one access blockers in advance
A new engineer’s first day should not be spent waiting. In Tokyo there are usually more moving parts than a team expects, and several of them depend on external timelines:
- Accounts and repository access, created and tested before the start date — tested, meaning someone logged in with them.
- A working local environment, verified on the same machine model and operating system the person will use.
- Administrative items with external dependencies: bank account, residence registration, payroll enrolment. These are not your responsibility to complete, but they are your responsibility to sequence, because they consume days the person cannot spend on code.
For engineers relocating, the sequencing matters even more, and the practical detail is covered in our guide to relocation support for engineers moving to Japan. The payroll and social insurance side, which surprises almost every foreign hire in their first month, is covered in our breakdown of shakai hoken, payroll and equity.
Step 3 — Ship a real change in week one
Not a reading list. Not a two-week architecture tour. One real change, merged and deployed, in the first week.
The size genuinely does not matter — a configuration fix, a copy correction, a test. What matters is that shipping it exercises the entire path: repository access, local environment, review process, deployment pipeline, permissions. Every broken step surfaces at once, in a week where breakage is expected and cheap to fix.
The alternative is what happened to us: the same broken steps surfaced in week three, when the person had already started wondering whether the problem was the setup or themselves. That is a very different psychological position, and it is the one from which people quietly decide to leave.
Practical version: before the start date, pick the change. Have it waiting. Make it real work that someone actually wants, not a manufactured exercise — engineers can tell the difference immediately.
Hiring your first English-speaking engineer in Tokyo?
We help teams write the language document, sequence the day-one blockers, and shortlist React developers who thrive in exactly the setup you actually have — not the one on the job posting.
Let’s talkStep 4 — Name one first-question person
“Ask anyone” is generous and useless. In a new team, in a second language, every question first requires choosing a target and estimating how much you are imposing. Most people, faced with that cost several times a day, simply stop asking.
Name one person. Tell the new engineer: “This is who you ask. Any question, however small, for the first month. It is explicitly part of their job right now.” Then tell that person the same thing, out loud, so they know it is a responsibility rather than an interruption.
Two details make the difference between this working and not working:
- The person should not be the manager. Questions to a manager carry an evaluative weight that questions to a peer do not.
- Give them a scheduled slot — twenty minutes daily for the first two weeks. A standing slot removes the need to decide whether a question is worth interrupting for, which is the whole barrier.
Step 5 — Write down the unwritten workplace context
This is the step that is specific to hiring from outside Japan, and it is consistently skipped because everyone already there finds the content obvious.
Two pages, in English, covering things nobody thinks to explain:
| Topic | What to write |
|---|---|
| Payslip and deductions | What each line is and why the first month may look different |
| Expenses and approvals | Who approves, in what system, and the actual turnaround |
| Forms and seals | Which documents need a physical seal and which do not |
| Leave | How to request it, how much notice is normal in practice |
| Social norms | Team dinners, what is expected, what is genuinely optional |
None of this is difficult information. All of it consumes attention a new engineer would rather spend on your codebase. And the document signals something more valuable than its contents: that the company has thought about what it is like to join from outside.
Step 6 — Two documented checkpoints, day 14 and day 30
Not a casual “how’s it going”. Two scheduled conversations with a written outcome.
Day 14 is about friction, and the questions are deliberately concrete: What has taken longer than it should? What did you have to ask twice? What is still not set up? At two weeks, people will answer these honestly, because the problems still feel like the company’s rather than their own.
Day 30 is about direction: What do you now understand that you did not at the start? What is still unclear about what good looks like here? What would you change about the last month?
Write down what was said and what you will do about it, and follow up on at least one item within a week. A checkpoint that produces no visible change teaches the person that feedback is theatre, which is worse than not asking.
Step 7 — Ask what they still cannot do alone
The final question, and the most useful one in the whole plan: “What can you still not do without help?”
Ticket counts at day 30 measure very little. A new engineer closing many small tickets may be avoiding anything unfamiliar. One closing few may be working through the hardest part of the system. Neither number tells you whether they are becoming independent.
The dependency question does. Typical answers — “I cannot deploy without asking”, “I do not know who decides on design changes”, “I cannot follow the incident channel” — are each a specific, fixable gap. And each of them, left unfixed, is a reason someone eventually leaves.
In our case the answer would have been the third one, and we would have heard it at day 14 rather than in an exit conversation at week five.
Three mistakes worth avoiding
Treating onboarding as an HR process. Nothing in this plan is administrative. Every step is engineering management, and every one of them is owned by the team rather than by a function.
Assuming the second hire needs less. The second English-speaking engineer needs the same plan, and gets it much more cheaply because the documents already exist. The mistake is treating the first plan as a one-off rather than as an asset.
Confusing early activity with early integration. A new engineer who closes many tickets in month one may simply be avoiding the parts of the system they do not understand. This is not a Tokyo-specific trap — teams in Singapore and Dubai make the same mistake, as our colleagues at HireDeveloper.sg and HireDeveloper.ae both report — but it is more costly here, where replacing the person takes considerably longer.
Frequently asked questions
Why do English-speaking engineers leave Tokyo roles so early?
Rarely because of the work, and rarely because of the salary, which is what makes early departures so surprising to the employers they happen to. The pattern we see repeatedly is a gap between the working language described during hiring and the working language in practice: interviews are in English, and then the design discussion, the incident channel and the decision that actually matters happen in Japanese. The person is not excluded deliberately; they are simply absent from the room where the work is decided. Five weeks of that is enough to conclude, correctly, that the role is not the one that was described.
How much Japanese should a React developer need for a Tokyo role?
That is a decision for the employer to make explicitly, not a fact to discover after the person joins. Both answers work: a team can operate in English and require none, or it can require conversational Japanese for design discussions and say so in the job description. What fails is the unstated middle, where the requirement is nominally zero and practically substantial. If your incident channel, your architecture reviews or your product decisions happen in Japanese, that is a language requirement regardless of what the job posting says, and writing it down costs you fewer applicants but far fewer failed hires.
What should a new engineer accomplish in the first week?
One real change, merged and deployed, however small. A configuration fix or a copy correction is enough; the size is irrelevant and the completion is everything. Shipping something exercises the entire path — repository access, local environment, review process, deployment pipeline, permissions — and surfaces every broken step at once, in a week where breakage is expected and cheap. Teams that spend the first week on reading lists and introductory meetings discover the same broken steps in week three instead, when the person has begun to doubt whether the problem is the setup or themselves.
What is the most common onboarding mistake in Tokyo specifically?
Leaving the administrative and social context undocumented because it is obvious to everyone already there. Setting up a bank account, understanding what appears on a payslip, knowing how expenses are approved, knowing whether a physical seal is needed for a given form, knowing what is expected at a team dinner — none of this is difficult, and all of it consumes attention that a new engineer would rather spend on the codebase. Writing a two-page document once, in English, removes a recurring source of low-grade stress and signals something more important than its content: that the company has thought about the experience of joining from outside.
Five weeks of onboarding decides three years of tenure
We build the 30-day plan with your team and introduce React developers in Tokyo who fit the setup you actually run. The plan stays yours, hire or no hire.
Let’s talk