In October 2021, Mercari launched the “RFS” project to strengthen the company’s foundation for service and feature development.

“RFS” is an acronym for “Robust Foundation for Speed.” The project was launched to support disruptive growth across the entire Mercari Group, and aims to solve complex technical challenges and drastically strengthen the shared foundation of all Mercari Group companies.

It has now been more than a full year since the launch of the RFS project. So, in this article, we wanted to answer the question that’s on everyone’s mind: “How is it going?” To get to the bottom of all of it, we interviewed two key people at the helm of the project, Minoru Tsuka (Director of Developer Productivity Engineering) and Shunya Kimura (VP of Platform Engineering). We went into the interview expecting to hear about the “behind-the-scenes” of the project—in other words, what the issues and bottlenecks were and how they were resolved. However, when we asked the two to reflect on the year since the project’s launch, we were pleasantly surprised that our conversation leaned more into talking about about how the project has had a hand in the evolution of the organization, and less about the actual strengthening of Mercari’s technological foundation itself.

The next step in building relationship value: creating context that is easy for others to understand and accept

──So, how is the RFS project going?

＠mtsuka：My answer to this question is going to be more about the mindset shift of the members involved rather than an actual progress report on the project itself. I think that what we wanted to do from the start—Ken and Shunya included, I think—was to change our collective mindset.

The specific mindset change we were after was a shift from “let’s do this because it’s something we want to do” to “let’s do this because it will be the best contribution to the business.” This mindset change has caused us to focus more seriously on quarterly and bi-annual results. We believe that this should of course be shared among the members of Mercari’s engineering organization, but we want the rest of the company to hear about what we have achieved here, too.

Now, have we done enough to communicate this? Frankly, I don’t think so. Not yet. But we have definitely started talking about the mindset shift and putting it into words amongst ourselves in the engineering organization.

Historically, I think we engineers have not done a very good job of explaining our specific contributions to the business, but I think that the effort we are making to see our work from a broader perspective in and of itself is worthy of some recognition. I think at this point we have a fairly well-developed system, but of course that’s a qualitative statement and what we want to do is bring a bit more objectivity to measuring our results.

I also like that tech PMs are able to participate in discussions on an equal level to everyone else, plus I like getting invited to other teams’ team building events! (laughs) I think that’s a really good thing. From our perspective, we are not striving to create our own vision of some sort of “engineer paradise,” we just want to hire strong engineers who will be able to contribute to the business and we want to create a working environment that interests that kind of person.

Minoru Tsuka（@mtsuka）

＠kimuras：That’s an interesting perspective. Let me ask you this, Shunya: what kinds of things were important in gaining the understanding of people outside of your own team? For example, was it creating that “relationship value” that took you to a place where you were getting invited to those team building events?

＠mtsuka：I think it’s more like “creating context that is easy for others to understand and accept.” I know that’s a bit abstract, but what I mean by that is creating a situation where the other person thinks, “Oh, okay, I get it. That’s cool.” It has to be that easy because people only understand things in the way their brain is already trained to understand them. At the end of the day, regardless of each person’s specific role, we’re all colleagues working together toward the same common goal, right? But it isn’t always that simple because different teams have different focus areas and KPIs that they’re trying to improve, so there isn’t always a shared understanding—we have to create that. Ken (CTO of Mercari) always emphasizes the importance of easy-to-understand communication.

＠kimuras：I think the biggest difference between RFS at launch versus now is the independence of the project. At first, the project was mainly led by engineers, so I think that created this image of us just working on what engineers want to work on, but this has drastically changed. At a certain point, tech PMs started to take the lead. I think it can be difficult for a PM to take the initiative in creating a plan for improving the foundation of a system because the roles of “engineer” and “PM” are often so clearly separated.

Today, the RFS project has moved away from “what the engineers want to do,” and because of that shift we are now able to make progress with a PM taking the lead. We have a single shared direction.

＠mtsuka：Yeah, there is definitely this feeling of “Oh, we’re all in this together now!”

＠kimuras：Right. We all got on the same page. For Mercari to deliver value to our users, we have to work together to develop our foundation. I think that we have developed a strong base for teamwork in this sense.

One of the factors that made this possible is—and I think Minoru touched on this earlier—sustained effort. In other words, continuous, easy-to-understand communication. For any organization, no matter the size, a certain degree of concerted work towards this is essential.

Shunya Kimura（@kimuras）

──From my perspective, I would think that a shared direction would make things far easier for engineers to develop. Is it just that there’s something about dev teams that makes it difficult to work with a PM?

＠mtsuka：Well, it’s not as if we all don’t want to make it happen… When I talk to engineers, many tend to talk in terms of organizational theory, making sweeping generalizations about how all organizations are like this or that, but that just comes from a place of sincerely wanting to contribute as much as possible to the business. I think the dilemma we had before was that not everyone was sure how best to contribute. Now, we are finally in a place where we can start connecting the dots.

＠kimuras：One of the unique things about Mercari is that we regularly report the technical progress of projects like RFS at executive meetings… I’m sure Minoru must be enjoying that responsibility! (laughs) I know this is a generalization, but senior managers and executives are not necessarily well-versed in technology. So you have to constantly check in with them to make sure they understand, otherwise a day will come when the manager will start to question why so many resources are being spent on this or that thing. (laughs)

＠mtsuka：I think in that case both parties would be in for a big surprise! (laughs)

＠kimuras：From an engineer’s point of view, it takes courage to talk about this kind of thing with upper management. It is a technically challenging topic, and it is very difficult to accurately convey why it is valuable to someone who doesn’t understand already.

＠mtsuka：That’s true. If the value is not properly understood, people tend to start getting impatient and asking if it can just be done faster…

＠kimuras：Right, or they don’t ask any questions at all. (laughs) At Mercari though, everyone wants to know everything down to the smallest detail, which is quite unique. We have gotten to the point we’re at now as a result of Ken and Minoru regularly reporting on the project at executive meetings and getting approvals as needed. At first, there was definitely a fair amount of doubt and skepticism from management about whether we should be making such a large investment in our foundation. But now we have their support and encouragement—Jeff (CEO of Mercari Japan) even sent out a message to the whole company requesting that everyone come together to support RFS. This is the kind of thing that makes engineers super happy.

＠mtsuka：Also, Shuji (Senior Vice President of Strategy) gave a message at All Hands (company-wide meeting) that we should be investing long-term and not getting caught up in short-term temptations. There are other times like this where I can tell that management really has their finger on the pulse—I don’t think there are many companies out there like Mercari.

＠kimuras：That’s what you’ve been saying all along! (laughs)

＠mtsuka：I know, right? (laughs) I think that making sure to repeat it roughly once a year has likely been key.

What we need to quantify is not what we’re doing but where we are

──What changes have you seen in the organization as a result of RFS?

＠mtsuka：I personally feel that, with the current less-than-favorable global economic situation, there are actually more opportunities to reevaluate fundamental features and experiences. Those opportunities highlight the fact that, for better or worse, we have been emphasizing speed above other things. We shouldn’t be only addressing the technical debt we’ve incurred by favoring short-term patches, we should also be stopping to think about what we could be investing in now that will benefit us in the future. Speaking of which, we are actually in the process of taking stock of and reviewing what we have at present based on UX. From there we will move on to making fundamental improvements.

In the past, we have gone ahead and implemented projects without fully discussing them, simply assuming that everything would get done on schedule. I don’t think anyone could deny that. But now, the environment we have created allows for us to have communication that will enable us to implement those sort of fundamental improvements. I really feel like we have come such a long way as an organization.

At least in terms of what we’re promoting with RFS, we will meet those pre-requisites (feature requirements). However, we will also continue to make fundamental improvements in parallel. This plan has been created together with the PM.

＠kimuras：Continuously improving base systems and refactoring code makes it much easier to start implementing changes This is a win-win situation for both engineers and PMs. Currently, we are concentrating on the CS Tool, transactions, and logistics systems. Now that we’ve made progress in decoupling and migrating these systems to microservices, technical contributions are becoming more visible and easier to understand. This has in turn made it easier for other people to understand what we’re doing, and due to that PMs are now incorporating RFS into their plans from the start. This is because they can now understand how RFS benefits their work too.

──What would you credit with this change? Is it organizational maturity or individual growth?

＠mtsuka：To put it simply, I think it’s that all the pieces have finally fallen into place. Until now, you could say that even though we were emphasizing speed, the system still worked, I guess. But a more accurate thing to say would be, “the system worked as long as someone worked very hard to make it work.” Now the system works without having to rely on individuals overexerting themselves. I’m not a big fan of the term “technical debt,” but the system we have now makes it very difficult for that debt to just keep accumulating.

＠kimuras：From the perspective of a business, what is the value of eliminating technical debt? It can be difficult to understand. So, when Minoru says “the pieces have fallen into place,” I think what he means is that the elimination of technical debt is a contribution to the business in and of itself, and it even became one of the methods we used to create new value.

＠mtsuka：“Debt” is such a negative-sounding expression. What I’ve been trying to say is basically just that we need a system that is easy to maintain. Having a system that is easy to maintain and easy for everyone to work with is indispensable. I keep telling our members that professionals should default to creating systems that are easy to maintain. Basically, there is nobody that doesn’t like an easy-to-maintain system. I now believe that each person understands what this means for their own role and that it has become a priority for us.

＠kimuras：Minoru, my understanding of the issue is that we need to be able to somehow “quantify” our contribution, but that this is sometimes very difficult to do. Could you expand a bit more on this?

＠mtsuka：Well, you pretty much nailed it—it can be very difficult to quantify certain things. We tend to want to quantify actions, but actually I think there is more to it than that. When we think in terms of results—for example when a member develops a product or a subsidiary starts running a service—the first question we ask ourselves is always, “Are we satisfied with this work?” It’s easy to fall into the trap of thinking that we always have to quantify things with precise figures. Ironically, this is exactly how an engineer usually thinks. However, what we should actually be trying to do is visualize the “status” of a project. In other words, how are things going? Of course there are also things that need to be measured with precise numbers, so I think it’s best to have a nuanced approach.

＠kimuras：In a different article, Minoru quoted Manabu Miyasaka, Deputy Governor of Tokyo, who said, “there can be no improvement without measurement,” but creating systems that lend themselves to measurement is no easy task. So I don’t think it’s sufficient to just say “we need to measure everything.”

＠mtsuka：That’s exactly right. We need to get meaningful numbers from a data-driven perspective.

＠kimuras：So, after all, it’s the “status” that has to be quantified somehow. Of course this is a problem for all of us to approach together, but ideally the most knowledgeable person in the field should be able to create KPIs.

This is an incredibly important discussion. We now have RFS members saying, “Hey, is this really going to contribute to the business?” or “I don’t think this is the top priority at the moment…” This is a clear change in mindset—our members are now asking, “Is this really what we need to be doing right now?” All the members involved in the project are really growing. Also, we now have enough team members that we can think in terms of prioritizing the things that will have a big impact on the business, or even giving up on certain projects if necessary, not just blindly refactoring. I think that’s what you want to quantify, right, Minoru?

＠mtsuka：Yes, that’s right. We have been told that we can allocate our time to building our foundation, but of course there’s labor and other costs associated with that. In other words, we’re talking about an investment here, so we have a responsibility to explain that this investment is justified—whether it is working or not. I think that holding discussions within that context is starting to happen on the front lines of our business as well.

＠kimuras：I think it’s because the PMs and engineers discussed it a ton, so they can now determine their own priorities.

So… what exactly is RFS?

──After having so many discussions internally, are there any other issues that you feel you need to address?

＠mtsuka：I would venture to say that there is more than a little bit of a downside to the OKR system. When we set goals like that, we tend to get tunnel vision and focus only on our own area. At a higher level, we have the group’s medium-term management plan, we have the roadmap, and we have the necessary preparations in order to achieve those things. I think that if we had someone to take the lead and explain that and how all of these are connected, we would have a much stronger organization.

＠kimuras：Yeah,it’s definitely true that all the pieces are falling into place, but I think there is still a lack of logical precision in the planning process. Ideally, we should be able to further refine this mindset by asking questions like, “Why is this what we’re doing right now?” or “Why is this the order of priority” and prioritizing in accordance with the mid-term management plan. We want the trifecta of the PM, senior management, and engineers all sharing the same understanding.

＠mtsuka：If we can do that, the company will be able to grow its business more efficiently. I think it also means that the company will then be able to invest in the next phase of its business. If we only focus on contributions to the business that are straightforward, we won’t be able to scale along the way.

＠kimuras：It is only now that things are much more organized that we can have this kind of discussion. At first we were all kind of stumbling around in the dark, but now we finally have a clear picture of what we should be doing. We are now approaching the point where we will have to refine the plan. That said though, the biggest overarching question is, “What does RFS mean to Mercari?” and that is something that I would actually like to ask Minoru.

＠mtsuka：To put it in engineering terms, it’s a commitment that we make to be “business enablers.” From a company-wide perspective, it is an investment in engineers to contribute to the business as accelerators. RFS is a project based on sound logic that tackles a difficult organizational development problem.

＠kimuras：So, in a way, it’s like a meta trigger for enabling?

＠mtsuka：That’s how I think of it, yes. I think it’s symbolic, like authority itself. But if you force it to be authoritative in an unnatural way, the means quickly become the end, so I guess you could call it a “mental model update program” or something like that…

＠kimuras：I think of it kind of like a “culture update.” As a company, we have been improving our services through fast, repeated POCs and experimentation. This is not sustainable though, and if we do not change course, then at some point we will go under. Before that happens, we need to make an update to the way we do things as an organization and honestly review the things we have always assumed to be good. Whenever you try to start something new, I think there is inevitably some friction and a tendency to adhere to precedent. We’ve been saying this for two years, and now I finally feel like it’s becoming part of the culture. Once it becomes part of the culture, it doesn’t need to be its own project anymore. People will naturally start to act based on those principles. I think that we can take what’s happening now as an encouraging sign of things to come.

＠mtsuka：I think everyone has gotten used to RFS, or rather, they seem to think that we’ve “finished” it? So we have to keep bringing everyone back into the fold and explaining that, no, it isn’t finished, we kinda have to just keep doing this… forever. (laughs)

──So, beyond these culture updates, what else are you looking to focus on as an organization?

＠mtsuka：I have said this many times in many places, but basically an engineer’s job is to solve problems. I mean, the ability to solve difficult problems is exactly what makes engineers valuable, right? By nature, we want to be solving difficult problems, but when you work for a company sometimes you have to work on solving not-so-difficult problems. For Mercari, our culture has become such that we can say things like “Your job isn’t solving easy problems.” I think this is something that engineers really enjoy. In other words, Mercari is beginning to create an environment where it is easy for engineers to make an impact.

＠kimuras：Oh man, I have so much to say on this topic. (laughs) The way you make an impact differs based on the phase of the company, right? So, in Mercari’s current phase, the impact is small for small endeavors. Or rather, the way that your endeavor fits into the big picture is just more important, so that kind of mindset change is super necessary now.

＠mtsuka：In the past, we would talk about contributing to product market fit or directly contributing to sales, but being able to contribute in some way to overall optimization also has a direct impact on the business. As the number of members increases and the complexity of the business grows, overall optimization will improve cost-effectiveness in a variety of ways.

There is also this view of “slow and steady wins the race.” I think it’s a good thing that we are creating an environment that values these things.

＠kimuras：Yeah, I don’t think it’s good for only the people who make the most visible contributions and impact get recognized. Focusing on the platform side of things is also important so that the surface-level, visible stuff can be implemented smoothly and securely. I believe that all engineers should have a platform perspective. I also think the most valuable thing about RFS is that it has fostered a sense that we are all working together to create a platform for everyone.