Is Japanese IT behind?

People often say Japanese IT is behind. My answer is yes and no.

No shortage of great engineers

Japanese engineers have given the industry a lot. The QR code came out of Denso Wave in 1994, with Masahiro Hara leading its development. Yukihiro Matsumoto released Ruby in 1995. Lean and kanban in software development both trace back to the Toyota Production System. Japan has never lacked great engineers.

Those examples say nothing about the average, of course. I do think the average Japanese software engineer is behind their peers in the US and China, and universities have a lot to do with it: software engineering as a discipline is neither widespread nor taken very seriously here. But I don’t think that is the main point. Plenty of engineers in the US came from other majors, and it hasn’t held them back.

The real problem is how companies are built

The real problem is that the structure of the companies hasn’t kept up.

The numbers show it too. According to IPA, Japan’s Information-technology Promotion Agency, 73.6% of Japan’s IT workers worked at IT companies in 2020, and only about a quarter at companies in other industries. The US is the other way round: only 35.1% were at IT companies in 2021, and most work at the companies that use IT. In other words, many Japanese companies have no engineering team of their own. Their systems go to system integrators, often through layers of subcontractors. The people who decide are far from the people who write the code, and engineers have little say in the product itself.

On November 2, 2026, GMO Internet Group held a press conference about unauthorized access to its Onamae.com Desktop Cloud service. The attackers got in through remote desktop servers used by customers and stole an administrator account, and the group’s own security company had pointed out problems with the system back in 2024. What stayed with me, though, wasn’t the security failure. It was one moment at the conference: as the responsible manager began to explain to the press, the group’s chief interrupted him to scold him for his unbuttoned jacket. “We are apologizing, and you leave your jacket open?”

It’s hard to imagine Satya Nadella or Elon Musk stopping someone over a button, in public or in private. Most people would probably find it absurd, yet the person who did it clearly saw nothing wrong. To me this is exactly why so many Japanese IT companies fall behind: a strict hierarchy built around power doesn’t fit with the open, equal environment that software engineering needs.

By hierarchy I don’t mean reporting lines. Microsoft and Amazon have hierarchies and reporting lines too, but they divide the work; they are not a chain of command. There, many projects start from the bottom up. In Japanese companies, ideas rarely travel up like that. Whether the deeper cause lies in Japanese society and culture is beyond the scope of this post, and I won’t go into it here. What is clear is that complex software engineering struggles to get anywhere under a strong hierarchy of power.

Reasoned debate, and knowledge tested by argument, need an environment of equals. Google’s Project Aristotle studied 180 teams and found that, among those teams, of the five factors behind team effectiveness, the most important was psychological safety: team members trust that no one will embarrass or punish them for admitting a mistake, asking a question or offering a new idea. Diversity matters as well. A Harvard Business Review article that sums up the research finds that diverse teams focus more on facts, re-examine them more often and make fewer factual errors. These are exactly what many Japanese companies lack.

Do the leaders know the technology?

Another difference is whether the people leading teams know the technology. In Japanese IT companies, project managers tend to sit near the top of the hierarchy. American and Chinese IT companies are different. At Microsoft, I saw many PMs (program managers) who wanted to become engineers who write code, and very few engineers who wanted to become PMs; most team managers came up as engineers too.

What responsibility means

Then there is how responsibility is understood. In many Japanese companies, one important question behind a decision is whether it keeps the organization from being held responsible: “If I do it this way, I won’t be blamed when something goes wrong.” That’s understandable, but it’s a factor I rarely felt at American IT companies.

What Japan is good at

Now look at what Japan does well. In its creative industries, what one person contributes counts for a great deal. In heavy industry, cars for one, what counts is how rigorously a team follows the rules. Software engineering needs a third thing: discussion among equals, and fast iteration.

Japanese IT has its own individual and small-team breakthroughs too. Chainer, the deep learning framework from Preferred Networks, introduced the define-by-run style in 2015, an approach the research community went on to adopt widely. But for the industry as a whole to move forward, the way its teams think has to change.

What Japanese IT companies should do

First, learn from the top American tech companies: build engineering teams of your own and outsource less. Your systems are a core capability, and they shouldn’t all be in someone else’s hands. Only engineers inside the company can be close to the business and the product, and answer for the results.

Second, bring in highly skilled people from abroad, and understand why: you don’t pay top salaries to smart people to tell them what to do. You pay them so they can tell you what to do.

Third, and most important, embrace an open, equal workplace and weaken the hierarchy of power. At work, focus on the work itself, not, as GMO’s chief did, on a button at a press conference held to apologize.

Fourth, let people who understand the technology make the technical decisions. Give engineers a career path parallel to management, so senior engineers can reach the matching level and pay without becoming managers. The people who lead engineering teams should ideally be engineers too.

Fifth, when something goes wrong, review it without blaming anyone. Google’s SRE practice calls this a blameless postmortem: the review looks only for what caused the incident, accuses no person or team, and assumes everyone acted in good faith and did the right thing with what they knew at the time. What gets fixed is the system and the process, not people. Once people stop fearing blame, decisions go back to asking what is best, not what is least likely to go wrong.

I’m not writing this to point fingers. I want to show where there is room to improve.