04. From Rakuten to Fast Retailing: I Once Thought a Big Company Was the Answer

To comply with my employers’ disclosure rules, department names in this essay are descriptive rather than official. Some details about projects, processes, and technical systems have also been omitted or generalized. This essay reflects only my own experience and impressions through July 2026; it is not an assessment of either company as a whole.

Before I left Rakuten, a senior manager warned me that, based on what he knew about Fast Retailing’s software products and engineering environment, it might not suit someone who cared deeply about technology. If I had already decided to leave Rakuten, he suggested that I keep looking for a better fit.

I heard him, but I did not change my mind.

By then, I had spent six years at Rakuten. I hoped that moving to a new company would clear away the career uncertainty that had accumulated over those years. Fast Retailing offered better pay and a well-known name. Although the interviews did not leave me with a strong impression of technical depth, I still believed that a company of that size would have plenty worth discovering once I joined.

Two years later, I can see that the manager’s warning was fair. But the problem was not Fast Retailing alone. I had also misunderstood the relationship between technology, products, and organizations.

In 2018, I Was Lucky Enough to Join Rakuten

Before Rakuten, I worked at Jxpress, a startup that operated a media platform. I was a full-stack engineer earning about 3 million yen a year. Looking back, I was still at the beginning of my career, but I had great confidence in myself. I believed that if I kept writing code and learning new technologies, I would eventually be able to solve whatever problems work put in front of me.

In 2018, a recruiter contacted me and said he could introduce me to more than ten companies. After several interviews, I chose Rakuten, one of Japan’s largest internet companies.

More accurately, the team may have chosen me first. I had applied for a frontend position, and engineers with that background were relatively scarce at the time. My experience happened to match what the team needed. After two interview rounds, the recruiter told me that they had decided to make an offer.

My first reaction was excitement. It felt as though my earlier effort had finally paid off. Then I repeatedly asked the recruiter to confirm that the news was real.

I told my family and friends, and they were all excited for me. I believed that I had earned the opportunity, but I also knew that it had arrived more easily than expected. Timing and luck had helped.

Moving from a low-paying startup to Rakuten felt like crossing an important threshold in my career. I had not spent much time thinking about where I would go after crossing it.

At Rakuten, Managers Still Worked Close to the Technology

I worked on two teams at Rakuten. One supported Seiyu’s online supermarket business, while the other focused on data and analytics services. Managers on both teams came from software engineering backgrounds. That quickly changed my understanding of what a manager could be.

On the Seiyu-related team, managers did more than assign work. For larger projects, they contributed to technical design, while middle managers often participated as technical leads. When engineers ran into difficulties, we could place the problem directly on the table. We did not need to translate every technical concern into management language or spend a long time proving that the problem existed.

In 2020, I moved to the data and analytics team. When a data service failed, managers who understood both the business and the system would join the response. Some difficult problems still depended on these experienced engineers. Even after moving into management, they had not completely left technical work behind.

During my four years on that team, my focus expanded from development into technical design, documentation, releases, and incident recovery. Some releases, maintenance work, and upgrades happened late at night. When data problems appeared, we had to respond quickly. The team had dedicated SREs, but I also took on part of that work.

This experience taught me that code is only one part of a system. Design, deployment, maintenance, and recovery all determine whether a product can operate over time. Roles combining software development, data engineering, and SRE work are not easy to find. Rakuten gave me a valuable environment in which to grow.

But a good environment does not automatically give someone direction.

I Believed Good Technology Would Eventually Produce a Better Product

On the Seiyu-related team, I mainly worked on frontend development. Whenever the project needed another modal dialog, the usual solution was to add another template. The feature would ship, but similar code kept accumulating, along with repeated opportunities for bugs.

I proposed creating a shared abstraction for managing modals. To demonstrate that the idea was workable, I prepared a design and a proof of concept, then presented them to the project’s main technical leader.

The proposal did not enter the codebase immediately, which disappointed me. Similar designs were eventually adopted in several later projects, however.

At that stage of my career, this felt like meaningful recognition. My value did not have to stop at implementing assigned screens. I could also contribute to technical decisions.

Near the end of 2021, I was assigned a browser-based data collection SDK. Existing tools could not support the required integration with video playback behavior, so we had to design a new solution.

I was responsible for both the design and most of the implementation. Much of it had to be built from scratch.

I threw myself into the project. I studied mature open-source libraries, looking at how they organized code, designed APIs, and managed dependencies. I then applied what I could learn to my own design.

The project was nowhere near the scale of a major framework, but the way I worked felt close to my idea of creating a product. The problem was clear, the responsibility was coherent, and I could take the work from design through development while paying close attention to quality.

I built personal and open-source projects for similar reasons. Part of me wanted to solve problems that other people might also face and show what I could do. Another part of me had always wanted to experience the full path from making a product to building a business around it.

I admired developers such as Fabrice Bellard and Anthony Fu, not only because of their technical ability, but because they appeared able to commit themselves to directions they believed in and keep refining high-quality software over time. Reading projects like theirs encouraged a misleading idea in me: if the technology became good enough, the product would naturally improve with it.

A mature, stable product inside a company could not fully satisfy that desire to create. The team wanted to protect what already existed and move forward at a controlled pace. I wanted to replace weaker approaches and attempt larger improvements.

I made suggestions and built prototypes, hoping the team would accept them. I did not dislike the work itself, and I did not resent lacking final authority. As long as I could persuade my managers and upward communication still had some effect, I was willing to keep trying.

What I did not want to face was the distance between getting a technical proposal recognized and getting a product to change.

The Company Was Not My Only Problem

At Rakuten, one manager told me that I was too attached to technology and did not yet see the wider picture, although I was good at completing technical work.

The first part was difficult to accept. I thought I was taking product quality seriously. I also believed that problems left unresolved would eventually become larger burdens. From my perspective, better technical solutions often existed; the team simply had not invested enough effort in them.

During my final year at Rakuten, I began looking at projects more broadly. When analyzing and designing technical systems, I no longer considered only whether the code was elegant or the architecture was sound. I also considered business goals, delivery risk, maintenance costs, and whether other teams could support the plan.

Looking back, I began to understand what my manager had meant by a narrow perspective. Engineers can easily mistake the problems visible to them for the most important problems. We can also underestimate how strongly resources, organizational structure, and commercial goals shape products.

This change brought me closer to the way a senior engineer should work, but it did not remove my dissatisfaction. I still wanted to participate in more creative product work, and I still felt that the team was moving more slowly than I wanted.

When my personal ambitions and the team’s goals remained out of balance, my solution was to find another platform.

I treated changing jobs as a reset.

I Once Thought a Big Company’s Name Could Be an Answer

Leaving a company after six years meant giving up stable relationships and the reputation I had built internally. I was less worried about joining a new team or losing a sense of security. My priorities were salary, the work itself, and the level of challenge. The people came last.

Fast Retailing satisfied the first condition. Its size and brand also gave me confidence. Even though the technical conversations during my interviews did not meet my expectations, I assumed that a company of that scale would expose me to more complex systems and larger business problems.

My senior manager’s warning had already pointed to a possible mismatch. My unease during the interviews was another signal. Instead of investigating further, I reassured myself that a major company could not be too bad.

Looking back, I expected the brand to tell me more than it could. Company size can indicate business scale, but it says little about engineering culture. Headcount can indicate investment, but it does not show how much authority engineers possess.

I joined Fast Retailing in 2024.

My salary went up. The work itself felt like a step backward.

My Salary Went Up. The Work Went Backward.

Fast Retailing and Rakuten cannot be compared directly. One primarily operates internet services; the other is built around apparel retail. Software plays different roles in these businesses, and engineering departments naturally occupy different positions inside their organizations.

That difference is not inherently good or bad. My mistake was failing to ask whether I fit the organization built around it.

The most immediate gap appeared in how requirements reached engineers. A task might begin with only a short title, while its context, scope, and acceptance criteria remained incomplete. Before development could start, I had to find the relevant people and confirm the goal, dependencies, and division of responsibility.

At the same time, several projects could move forward in parallel. Engineers were expected not only to develop software, but also to fill parts of the gap in requirements analysis, resource coordination, and project management.

I do not object to blurred responsibilities by themselves. On a team with real autonomy, engineers who participate in product and management decisions can gain a broader perspective. Fast Retailing also forced me to notice things I had paid less attention to before: how business teams allocate resources, how managers schedule projects, and how different groups divide responsibility.

I also met colleagues I would like to remain connected with. Even in an environment that did not suit me, some people continued to work seriously and tried to improve the problems in front of them.

But greater responsibility did not come with greater authority or control over resources.

Within the area I encountered, engineering teams had limited ability to schedule technical improvements themselves. Business features kept entering the roadmap, while technical debt, testing improvements, and infrastructure work could remain unscheduled even after the team agreed they were necessary.

Legacy systems had complex dependencies. A small change could affect several other areas, forcing teams to spend more time communicating and validating their work to reduce risk.

Technical ability and delivery quality also varied significantly, and old problems continued to be inherited. Engineers understood that parts of the system needed to be cleaned up, but they lacked enough space to pause feature work and address underlying problems.

The hardest part was not that the work was difficult. It was knowing that many difficulties could have been reduced through long-term investment, while seeing that such work rarely reached the schedule.

What an organization puts on its calendar reveals what it values.

More Responsibility Does Not Always Mean More Growth

Fast Retailing encourages employees to take on more responsibility. Engineers do not work only on engineering; they are also expected to perform parts of the work normally handled by product or management roles.

Seen positively, this can broaden someone’s perspective and teach them more about how an organization operates.

But more tasks do not necessarily create more growth.

When an engineer works across several projects, constantly switches attention, and still lacks authority over priorities and improvement plans, “taking responsibility” can become another name for carrying a larger workload.

Someone can become skilled at completing tasks in a disordered environment without developing deeper technical judgment or stronger product instincts. More responsibility may create an experienced operator, not necessarily a craftsperson.

My ideal team resembles a jazz band. Each person has individual ability and judgment. They can improvise as conditions change while still collaborating around a shared theme.

This kind of team does not reject process. It requires people with compatible skills, clear goals, shared resources, sensible task allocation, and room for limited failure. Removing every process would create chaos. But when process determines every decision in advance, engineers are left with execution alone.

Rakuten was not a true jazz band. It was only closer to one than Fast Retailing. Rakuten also had processes, internal politics, and management constraints. The difference was that many processes remained in the hands of senior managers who understood technology, leaving room for discussion and adjustment.

Fast Retailing showed me another organizational logic. When software built by individual contributors causes a serious problem, managers also bear responsibility for the result. Under such a system, a technical improvement without an obvious short-term return can easily appear as additional risk.

Business teams want more features. Managers want to reduce uncertainty. Engineers continue moving forward while carrying technical debt.

I disagree with this allocation of resources, but I have come to understand why it remains stable. Every role protects its goals within the existing evaluation system. Individual enthusiasm has little power against an established chain of responsibility.

There are still a few leaders willing to protect engineering judgment. They understand technology and will propose alternatives when upper-management demands conflict with engineering quality. But people like this are rare, and ordinary engineers cannot change resource allocation through technical ability alone.

I once believed that what I lacked was better technical skill.

Fast Retailing taught me that many technical problems eventually become organizational problems.

Two Jobs, Two Kinds of Uncertainty

At Rakuten, my uncertainty was: “There are many ways this product could become better. What can I do to move it forward?”

At Fast Retailing, the question became: “If the organization leaves no room for these improvements, why should I keep exhausting myself?”

The two forms of uncertainty look similar but come from different places. The first carries an engineer’s familiar impatience—the belief that a little more effort will bring the product closer to an ideal. The second feels more like powerlessness, because technical skill cannot directly change resources, responsibility, or decision-making authority.

I used to believe that good technology would eventually lead to a good product. After years of work, I now see that the ceiling on product quality is often set by how much time and decision-making room an organization is willing to reserve for it.

Time matters in particular. Refining a product over the long term requires time that people can direct themselves. It also requires an organization willing to let them focus on long-term quality.

Without that space, even an ambitious engineer can do little more than process the next task.

This does not mean engineers can blame every problem on their employers. Organizations define external constraints, but individuals still need to decide what to learn, what to accept, and when to leave.

My mistake was going for years without a concrete career plan. I only had a vague wish that, five years later, I would somehow be a “better engineer.”

When reality failed to match that image, I did not know whether to change my goals, change my approach, or change my environment. In the end, I chose the easiest option to act on.

I changed companies.

Rakuten Gave Me a Measuring Stick

What Rakuten gave me went beyond experience in frontend development, data engineering, and SRE work. It also gave me a way to judge how work should be done.

The company calls this philosophy Rakuten Shugi. It consists of five brand concepts and five success concepts, including continuous improvement, professionalism, maximizing customer satisfaction, speed, and turning the cycle of hypothesis, execution, and validation into repeatable systems.

These ideas carry the unmistakable tone of corporate culture, but they still gave me a reference point whenever I handled something well—or badly.

The idea that influenced me most was maximizing customer satisfaction. If people choose to use a product, I believe they deserve a better experience.

That conviction has sometimes made me focus too heavily on technology while overlooking commercial goals, limited resources, and organizational relationships. But it also prevents me from ignoring problems that could clearly be improved.

Fast Retailing gave me another, less comfortable measuring stick. It taught me to examine the conditions surrounding the technology: whether leaders understand engineering and can control team resources and workloads; whether a team has basic technical ability and some autonomy; whether user value is clear; and whether the development process can support quality over time.

In the past, I looked at salary first, then the work and its challenges, and finally the people. Today, that order is almost reversed.

Leadership, team quality, and decision-making come first. Salary and brand still matter, but they cannot compensate for a working model that remains incompatible with my values.

I Still Have Not Found My Ideal Team

If I could make the decision again, I would still join Rakuten. It was not perfect, but among the companies I have experienced, it was more willing to treat engineers as people who could help solve problems together.

I would not choose Fast Retailing again for the same reasons that led me there in 2024. This is not a judgment on the company’s overall value. It is an answer about personal fit. Fast Retailing has its own business logic and management system, but they are too far from the kind of engineering work I want.

As of July 2026, I still work at Fast Retailing. I have not found my ideal team, and I still do not have a final answer to the question of what kind of engineer I want to become.

What has changed is that I no longer treat the absence of uncertainty as a goal. Professional identities change. Interests change. Work environments change.

What I need is a direction that can keep me engaged while reminding me to continue moving forward.

If I could say one thing to the version of myself who joined Rakuten in 2018, I would tell him to spend more time around exceptional people—and not to believe too strongly in the power of technology alone.

A strong technical proposal does not automatically become a strong product. Seeing a problem does not give an engineer the authority to change it.

Personal ambitions and company goals will never remain perfectly aligned. When the gap is temporary, it may be possible to communicate, adjust, and wait. When it persists, it becomes necessary to ask whether the platform still deserves further investment.

Changing companies can change someone’s circumstances. It cannot define that person for them.

I still feel uncertain. The difference is that I no longer turn every organizational problem into a reason to doubt myself.