“Microservices Are Not a Silver Bullet”: Lessons Learned and Woes Suffered by the CTOs of Mercari and GREE While Working to Expand the Engineering Organization [Ken Wakasa and Masaki Fujimoto]

Mercari: Taking a Step Toward Becoming a “Truly Global Tech Company”
In the reuse market, which is valued at over 1 trillion yen, Mercari has continued to make great strides as the industry leader. This year marks the ninth anniversary of the company’s founding and its unwavering mission to “Create value in a global marketplace where anyone can buy & sell.” The next phase they are looking toward is becoming a global tech company second to none in the world. In this special feature, we bring you a glimpse of where Mercari is today and what the future holds for the company as it continues to evolve.

GREE, founded in 2004, gave birth to a huge movement through its development of the world’s first mobile game, and Mercari, founded in 2013, has expanded the secondhand market in Japan.

While the nature and history of their services differ, one commonality that they share is that both companies have experienced significant growth in a short period of time and, at the same time, have rapidly expanded their engineering organizations.

Having built their organizations and services from scratch and come a long way since the days of being considered startups or venture companies, these companies are currently vying to grow into massive tech companies. What obstacles did these two companies face in expanding their development organizations to a scale of several hundred people?

Mr. Masaki Fujimoto, who has been supporting the expansion of the engineering organization at GREE for 16 years since 2005, and Mr. Ken Wakasa, who has been serving as VPoE since July 2020 and was appointed CTO in July 2021, spoke about what they learned, and what they realized during the periods when their organizations were expanding.

※This article has been translated and reprinted from the contents of “Engineer Type”.

GREE, a multi-product company, and Mercari, a highly integrated single-product company

—Both of your companies have about the same number of employees: between 1,500 and 2,000. Can you talk about how the number of employees has grown over the years?

Wakasa：In terms of the entire group, Mercari strengthened its hiring considerably from 2017 to around 2019. Our annual employee growth rate was sometimes as high as 20-30%. We did the same for the engineering organization as well, which quickly tripled in size in a single year from 2017.

But starting around 2020, hiring activities were put on what we call “safe mode” due to the COVID-19 pandemic, so the number of employees has been flat since then.

Fujimoto：From 2011 to 2013, the third to fifth years of GREE’s listing, we grew by several hundred employees each year. Since 2014, the number of employees has been stable at roughly 1,500 to 1,600. Out of the total number of employees, I’d say roughly 30-40% are in engineering positions.

Fujimoto：That being said, recently I’ve felt that the idea that the ”number of employees represents the size of the company” is no longer generally applicable.

Ever since the COVID-19 pandemic began, the number of people who work for us on the side or on an outsourced basis has increased, and the way we build teams and work has become more diverse.

There may be a company that has five employees, but 10,000 people working as contractors or on the side.

Wakasa：That’s definitely true.

Fujimoto：The natures of Mercari and GREE’s organizations are different, to begin with, so it’s difficult to compare them in terms of the number of employees.

In GREE’s case, we are developing a variety of businesses, including games, advertising, and most recently we have begun venturing into the Metaverse, while actively operating more than 20 titles for game titles alone. Meanwhile, Mercari almost completely focuses on a single product.

Wakasa：That’s right. While we do have the Merpay smartphone payment service and the Mercari Shops e-commerce platform, they are both basically linked to Mercari and can be considered one big product.

Fujimoto：At GREE, we have a common infrastructure, but each game title is developed by a different team. There are many products that are created by teams of 40 to 50 people.

So, in a way, GREE is considerably easier to work with than Mercari. For example, when it comes to language selection, we can be flexible and use the language that is most appropriate for each team.

Wakasa： Just as you said, having separate products will inevitably lead to loose coupling, which makes them easier to operate individually.

Unfortunately, in a single product business model, there is no way to stop the modules from becoming tightly coupled by default.

As you expand your organization, especially your engineering organization, the things you create get larger and larger, and the number of people and modules increase proportionately. In fact, dependencies grow not proportionately but rather exponentially.

This makes it so that when we want to release something, the change is much more impactful, and making changes requires getting permission from all the parties concerned. The number of stakeholders increases as well. This leads to ballooning adjustment costs.

Fujimoto：Things used to be difficult for GREE when we had hundreds of people working on a single platform. Nowadays, we are adamant about treating each individual title as its own undertaking, so we can get by even if there isn’t much coordination between products. This has pretty much eliminated the burden.

Wakasa： To make development sustainable, Mercari needs to become a loosely coupled system linked by APIs. Going forward, we plan to achieve this by collaborating closely among teams.

Software and People Are Not the Same

—What are some of the challenges you have encountered in scaling up your engineering organizations?

Wakasa：This is related to what I said earlier, but Mercari faced a significant challenge: Creating software that is easy to change.

So in August of 2018, we made the call to switch to microservices. We then discussed what type of organization would allow us to make microservices a reality. We were trying to give the organization a structure similar to that of microservices in that each module would function autonomously. We were utilizing the “Inverse Conway Maneuver.*”

* Conway’s Law: A law that states that an organization’s structure and productivity are reflected in its software and architecture. The Inverse Conway Maneuver does the reverse by designing an organization that matches the software and architecture one aims to create.

Wakasa：Regardless of whether it worked or not, I personally think it was a pretty ambitious challenge. Software and engineers (people) are different, after all. Treating them the same way is a difficult proposition. When I look back at my previous job at Google, no one was talking about microservices.

Fujimoto：Because Google uses a monolithic repository, right? It’s pretty huge (laughs).

Wakasa：That’s right. But looking back now, I remember that each engineer was involved in a fairly macro service. In other words, it makes you think, “There doesn’t seem to be much of a link between the organization and what we’re making, does there? ”

And when it comes to carving microservices out of a monolith, no one knows how to cut.

We don’t know if we’re cutting correctly, but we cut anyway. We want our microservices and organization to be similar in form, so we cut the organization in a similar way. But later on, we might say, “It was a mistake to cut it like this.”

At that point, we can fix the software, but we can’t fix the organization so easily. Even for something small-scale, like saying “Let’s merge a part of Team A into Team B,” there are many adjustments that need to be made, and the whole process may take several weeks or even months.

Fujimoto：People have feelings, too. There will be disagreements and points of frustration.

Wakasa：It’s perfectly fine to make mistakes or to cut the wrong way because this can be fixed later. But the organization cannot be fixed so easily. That’s what makes it so difficult.

In other words, I personally think that microservices aren’t a silver bullet, but rather just a means to an end. This doesn’t mean that monoliths are bad or that microservices are a panacea.

Fujimoto：Shopify, for example, is returning to monolithic services from microservices in some instances.

To touch on a point that is similar to Mercari’s attempt to create an organization using microservices, GREE scaled its organization by hiring people at a tremendously rapid rate with a single product.

But in the end, we couldn’t maintain the momentum, and the company had to slow down the scaling. The level of maturity wasn’t sufficient. In the end, we couldn’t make the most of the organization we had scaled up, and we weren’t able to take on new challenges and grow our business as much as we had hoped.

So I think these past five or six years were about stopping, increasing the maturity level, and arriving at a point where we were ready to try again.

So even though GREE and Mercari were founded at different times and walked different paths, I feel that both went through hardships and have now reached the same point.

Wakasa：But GREE has a much longer history, so I’m sure it has had many more mountains to climb.

—At the time, why was GREE unable to take advantage of the organization that it had scaled as a company?

Fujimoto： In some respects, the strategy and tactics of the business itself were not formulated well, and in other respects, the culture of the organization grew disjointed, and everyone ended up focusing on different things.

As for the organization specifically, I think there were a lot of the typical problems that arise when the number of people rapidly increases.

Wakasa： I have a question: as the number of people increases, doesn’t onboarding naturally become necessary? How did GREE address this?

Fujimoto： When we had a certain number of people consistently joining the engineering team, we created a “boot camp team.”

When you joined the company, you would join that team for a certain period of time and work on assignments and learn the local development methods unique to GREE. If you meet the required standards, you graduate. That’s where you make friends who feel like members of the same graduating class.

Wakasa：Knowledge of the local domain sure is important, isn’t it? It can be different from your own tech stack.

Fujimoto：There are people who are extremely talented but have never used Git before. There are also companies that implement their own toolchains all over the place.

The larger the organization, the more you need to know about local rules and company-specific systems. I think it’s important to provide

opportunities for people to learn about these things and forge relationships, especially during the phase where you’re enhancing engineering recruitment.

Wakasa：Mercari has created a similar system for new graduates. For mid-career hires, however, while we have begun to conduct orientations, get recruits used to certain local rules, and establish an onboarding process for each technical area, there are still a lot of inadequacies, and the enhancement of content continues to be an issue.

Without an onboarding system, the burden of those who serve as mentors on each team increases.

This is also connected to the seniority issue. At Mercari, we had a hard time adjusting the junior and senior member ratio when we scaled the organization.

In fact, for a while, we had a large percentage of junior engineers.

No matter how much potential the young recruits had, there were still many things we had to teach to those with no work experience, including how to behave like professional engineers.

At the time, some senior employees at the company said, that they couldn’t get any work done because they were spending too much time training young employees.

For this reason, we steered the company toward hiring more people with a certain level of experience.

Fujimoto：It was the same with GREE. When we quickly scaled up our development organization (around 2011), we tried to hire as many people as we could, and it didn’t go well.

Because we were focused on hiring a set number of people in a set period of time as opposed to hiring people who met our hiring criteria, we ended up with an increasing number of people who didn’t match our culture or have the experience and skills we were looking for.

Originally, our rule of thumb was “when in doubt, don’t hire,” but we were doing the opposite.

Wakasa：”When in doubt, don’t hire.” That’s exactly it. I read that in Joel on Software (Japanese Edition, Ohmsha) a while back. It’s difficult to follow that rule, though.

Mercari’s Goal: Letting Individuals Make Decisions

—When a company scales rapidly, a number of issues besides product development, such as organizational structure, hiring, and onboarding, occur in every area.

Wakasa：That’s right. That’s why we, as CTOs, need to continue to create an environment where engineers can focus on development, even if the organization grows or changes.

If engineers spend their time doing things other than development, such as internal coordination and document preparation, the organization’s development capabilities will not improve. How can we save our resources from spending their time on things other than development? That’s what I want to focus on even more going forward.

In particular, we’ve most recently been trying to reduce EMs’ (engineering managers) workload by placing a Tech PM (technical program managers) team in an organization that is kept separate from engineering.

Fujimoto： EMs have a tough job, don’t they? They do engineering, team management, and project management. I hope that GREE will be able to leave more of the project management to the PMs (project managers) in the future.

Wakasa：Don’t get me wrong, but what Mercari is aiming for in the future is an “engineering organization that doesn’t require managers.” I want each and every engineer at Mercari to be more autonomous.

Namura, the former CTO, often stressed the importance of micro-decisions. Basically, I want each engineer to become making decisions on their own “like adults” and take responsibility for their own work.

Fujimoto： I got the impression that Mercari was already doing a good job at that. But it takes a leader who decides the direction of the company, right? Even if it’s only a rough direction.

Wakasa：That may be true. I’d like to reduce the load on the EMs a bit more, but still have development run smoothly. The EMs would like to be able to spend more time on what they should be doing, like determining direction of the team at a high level, improving productivity and maximizing results for the team as a whole, and supporting team members’ growth.

―So then both companies have been creating new positions and improving engineers’ tasks as needed in response to changes in the size of the development organization and new issues that have come up.

Wakasa：That’s right. I think it’s important to keep searching for the best type of organization as our operations evolve.

Fujimoto：There is no right answer, but the moment an organization stops evolving, it becomes useless. In that sense, it’s amazing that Mercari has continued to constantly evolve.

Wakasa： It’s quite difficult to do, though. Some people think we’re evolving too much. (laughs)

Fujimoto：We’re the opposite. People say we’re evolving too little. Especially the CTO.

Wakasa：It’s really incredible that you’ve been the CTO of the same company for over 16 years, huh? Maybe you’re the only one capable of that. (laughs)

Large Companies Face Large, Complex Challenges

――Could you tell us about the challenges you’ll face in scaling up your engineering organization going forward?

Wakasa：We want to invest in our technology infrastructure. When it particularly comes to the C2C marketplace, we want to invest in transactions, listings, account management, payments, and delivery logistics.

Fujimoto：For us, we want to invest in ID, microtransactions, and payments.

Wakasa：We’d like to break these areas down into additional modules. That’s why we recently launched a project called “Robust Foundation for Speed (RFS)” to strengthen our technical infrastructure.

The RFS Project. A project launched to support disruptive growth across all of Mercari Group, by solving complex technical challenges and drastically strengthening the foundation shared across its businesses.

Fujimoto：So as a company, you’ve started to invest in infrastructure? That piques my interest.

Wakasa：I personally don’t really like this expression, but while we’ve been working to “pay off technical debt,” so to speak, the business side didn’t really understand its importance, so it was given less priority compared to the release of new features.

However, as the situation deteriorated, the various intricate parts of the project started to impact one another, and releases started to take a long time.

So we avoided using the phrase “paying off debt” and told management that we were not strengthening infrastructure for the sake of strengthening infrastructure, but rather to contribute to the business by delivering functions more quickly.

Fujimoto：Both Google and LINE, where you used to work, have lots of people working on one huge product as well, right? I’m sure you’ll be able to apply the experience you gained there.

Wakasa：That’s right. But if you’re serious about strengthening technical infrastructure, I think the most important thing is to have the resolve to do it as opposed to having knowledge of techniques and know-how.

For example, there are a lot of engineers at Google who constantly rewrite certain modules. Dozens of them work on things like completely replacing a part of the search function or adding Spanner into their database infrastructure.

From the users’ point of view, nothing has changed, but behind the scenes, the system has been optimized and development costs have been reduced.

This kind of investment decision doesn’t happen just because “it’s the right thing to do” to rewrite this or that module.

I think “big tech” refers to companies that have the resolve to make large investments of people and money for such a purpose. That’s what I want to do with Mercari, too. I want it to become a tech company that lives up to the world standard.

Fujimoto： I see. It would be really cool for Mercari to continue with that approach. In that sense, the bigger the product, the easier it is to get returns.

Wakasa：That’s why we want to visualize the return on our investment. After all, it’s difficult to understand the effect of investments in infrastructure. But I think that’s what companies like Google and Amazon are looking at.

—You mentioned that efforts to strengthen technical infrastructure are invisible to the users, but what’s the benefit for the engineers?

Wakasa：I don’t think many users care about the OS of their smartphone, but for example, the people who make iOS itself are creating the infrastructure, right? Without it, so many of the apps that keep society functioning would completely fail. I think that’s why they take pride in their work.

Fujimoto：I think it’s simply more difficult to skillfully improve something that already exists than to create something from scratch. I personally think solving more difficult problems is more satisfying.

When it comes to making a small application, you can ultimately do it alone, but it’s important for engineers to think about, say, how to make software that has been running for 10 years to run for another 10 years, and I think it’s a very difficult thing to pull off.

Wakasa：That’s what real engineering is all about, isn’t it?

Fujimoto：And recently, I’ve gotten the impression that collaborating to create something big is becoming ever more important.

This is because the software industry has matured, and there are fewer and fewer places where brash engineers who can create anything on their own can demonstrate their value like 20 years ago.

Wakasa：I know what you mean. The days when one person could dominate the market with a single idea are long gone.

Fujimoto：As the world gets flooded with a variety of products, the scale of the products that need to be created is growing larger, and higher levels of quality are being required as well.

I’m sure there are some tough times ahead, but it’s only at large companies that you can tackle complex issues on a large scale.

Wakasa：Especially when it comes to companies that are considered part of “big tech,” they can afford to make bold investments toward complex issues and technologies that at first glance don’t seem to be worth the money. That’s because they’re making enough money from their core businesses to be able to do so. I don’t think Amazon originally started AWS with the intention of making it into a big business, either.

And Mercari is at a stage right now where it’s starting to make investments to reach that phase. I want to further expand the scale of the organization so we can take on unprecedented challenges in the future.

Reporting by Kanako Ishikawa
Photography by Yota Akamatsu
Editing by Kotomi Kasai (Editorial Staff)