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?” In this series spanning three articles, we will talk to three key people overlooking the three areas of focus for RFS, namely C2C transactions, ID platform, and CS tool, and ask them about the problems faced by the project and how they are addressed. For this second installment, we reached out to the managers and tech leads of the CS Tool Team and asked them about the current status of the product from their respective points of view.

Taking on feature development for CS Tool in a two-team structure

──Let’s begin by going over your careers. As the CS Tool team is composed of two teams, can CS Tool 1 (“Team 1”) go first?

@Unsu：I used to be a web developer in a tech company in Seoul, before I moved to Tokyo in 2016 and joined Rakuten. There, I worked in the backend team as a software engineer and engineering manager afterwards. Later I transferred to Line and worked on the bank development project. I joined Mercari in February 2022. Currently I am the engineering manager of Team 1.

@hukurou： I joined as a new grad in April 2020, so I will enter my fourth year very soon. Before that though, I had a one-month internship here in the summer of 2018. Since joining Mercari as a full-time software engineer, I have been a member of the CS Tool team. Right now I am the tech lead of Team 1.

──Now let’s hear from the members of CS Tool 2 (“Team 2”).

@Peranikov： I joined Mercari in November 2018 and have since been a member of the CS Tool Team. My career in Mercari started as a backend engineer, but since the CS Tool Team has a culture of rotating the tech lead role, over time I also took on that responsibility and eventually became an engineering manager in April 2022, which is my current position. I was originally interested in improving team productivity, so deep down I knew that at some point I would have to go beyond sharpening my tech skills and take on a managerial role. At the time of an organizational shift in the team structure, I took the chance to become a manager.

Yuto Matsukubo (@Peranikov)

@waiting.lau： I joined Mercari in March 2018, so I have been here the longest in this group. I was in another team during my first three months, and later moved to the CS Tool Team. I joined as a backend engineer, but currently I am the tech lead of Team 2, looking over the backend and infrastructure.

──I’ve heard that the CS Tool team transformed into a two-team structure to fit the expanding business better. Can you talk about the mission and goals of each team?

@Unsu：Team 1 mainly works on service development, which also includes application development. Our main role is to develop and improve the overall features used by CS(Customer Service) members, including development involving changes to UI specifications. .

What we are doing specifically for RFS is eliminating dependencies between tools by removing the direct database calls to Mercari’s gigantic core database. Making the tools more independent makes development easier.

Eunsu Jang (@Unsu)

We are also in the process of shifting the frontend of the CS Tool from its current framework in order to comply with industry standards. We expect this will improve system security and developer experience. As the business keeps growing in the future, this is a necessary update so that we can handle development requests from CS in a more effective manner.

@Peranikov：Team 2 is composed of backend engineers. Team 2 also builds features for CS Tool, like Team 1 does. However, Team 2 mainly focuses on improving the developer experience for Team 1 and strengthening the system infrastructure of CS Tool.

The ongoing GKE migration project is a good example. We had a migration project before where we moved an on-premise application to GCP. This project is all about moving that application to GKE, which is the platform all other Mercari microservices run on. We aim to provide the same developer experience as the other microservices in Mercari.

──When running your respective projects, are the two teams working in parallel, or do you have common OKRs?

@Unsu： As I mentioned before, both of the teams are working on the development of CS Tool, so while we have distinct OKRs, we work together very closely. Both of the teams come together weekly to share their OKR progress and also hold retrospectives at the end of every quarter. For the retrospectives, both teams look back at how much of their respective OKRs were achieved, and compliment each other on the good work that was done.

A team culture established through RFS: Building an environment conducive to focus

──How did you update your team structures as you joined the RFS effort?

@Peranikov：Back when there was only one CS Tool Team, we had five engineers. I was one of those engineers, of course, and I later became an EM. Another engineer became a product manager, leaving the team with just three engineers for a short while. When the huge RFS project began and it was decided some of the efforts would be committed to working on CS Tool, we boosted our hiring activities, reorganizing the team into two sub-teams with 8 engineers in total. It was a roller-coaster ride to me given the fact that my career as an EM is relatively short. (laughs) My big challenge as a manager was to create the proper environment for the increasing number of members so that everyone can easily focus on their work.

Because this team looks over the whole of CS Tool, there are many domains we have to be involved in. We also have to handle requests coming from CS as well as other teams. It’s common for the team to work across different domains.

While it is an ideal situation for every team member to constantly take on new challenges in CSTool, there is a trade-off where they must switch contexts and shift focus between varying tasks very often, which can critically affect their productivity. That is actually one of the reasons for the two-team structure, as it allows us to limit the scope of each team to a certain degree so that they can focus specifically on what they need to do. This organizational change happened last year and has proven to be a promising change.

──It is a big change indeed. Unsu, from your perspective, what are the issues CS Tool Team encountered and how did you address them?

@Unsu： I joined when the two-team structure was under consideration. I remember that we had long discussions to decide how the teams would be split, what work they would be in charge of, and so on.

It is not easy to split a team into two. Right now Team 1 looks over the application side, while Team 2 focuses on the platform side, but for example with on-call shift, which includes system monitoring and alert handling, there are still some areas which are not clearly any team. When assigning projects between the two teams, those gray areas still make it a little bit difficult for us to decide who should do what exactly.

I believe we could revisit these areas, and define which team should own what area and what knowledge the other team should acquire in order to handle any issue which is not maintained by their team.

When we first split the team, we also encountered the same issue that it was difficult for the respective sub-teams to be aware of each other’s projects and progress. The weekly check-in I mentioned earlier helped us alleviate this problem.

The check-in was initially designed specifically for RFS purposes, but it turned out to be helpful in visualizing the teams’ progress for other members. We continued to hold this meeting to confirm the progress of all projects in each team, and now it helps us track the progress of the projects in each team, identify the bottlenecks, and how we can collaborate with other teams.

──It comes through very clearly in your answers that there is a lot of emphasis on creating the optimal environment for the teams to focus on their specific tasks. It also lines up with what Kimura and Tsuka referred to as a “culture update in the engineering organization” during the interview we had with them. So then, what is your understanding of the CS Tool Team’s role in the RFS effort?

@Peranikov：The mission of the CS Tool Team has mostly stayed the same even after the shift to the two-team structure. Even though we do not bring Mercari values to our users directly, we deliver technical solutions to Mercari’s CS organization so as to improve user satisfaction.

That means our stakeholder is Mercari’s CS, and our role is to deliver technical solutions to improve the efficiency and reliability of their operations as much as possible.

Looking at the bigger picture, CS Tool has been around since Mercari has been established and there are so many more things that have to be improved when compared with the other new microservices. This makes us bring values to CS at a slower pace. Now we reach the phase where we must break through this barrier.

Our role and mission is to pay off the technical debt that has become the blocker for us to catch up the business, and ultimately deliver technological values to CS much faster. Thanks to the RFS project that aims to strengthen our technological platform.

──So we must address these issues one day, and the company finally decided to invest in the solutions. How did that affect your motivation? Do you feel like this is an opportunity to resolve all the existing problems?

@hukurou：The microservice migration of CS Tool had started before I even joined the company. The goal was to gradually migrate all the features in the original tool. However, while we were working on the migration, we realized there were many more features than we had anticipated, and the features were very complex. The migration also required CS to revise its operations, making the whole project very time-consuming. I think a lot of members believed we would never be able to completely migrate all the features to microservices. So I believe it was a good decision to change our direction from breaking down the tool into smaller units to maintaining the existing tool in a sustainable way as the mid-to-long term goal.

Reo Ishii (@hukurou)

@waiting.lau： I don’t think there are many companies who are willing to invest in resolving tech debts, even if everyone on the front lines is aware of them. It is extremely costly but important to set up the infrastructure properly and that’s why I am very happy to get involved in this project. I strongly believe the maintainability of the infrastructure is the key to success. As hukurou said just now, there are too many features in CS Tool.CS Tool is very likely to be completely unmaintainable in the future without RFS project.

@hukurou： Even though the number of our engineers went from three to eight, we had a very wide range of domains to cover, which required so much domain knowledge. We had to broaden our knowledge, especially for Team 1, which comprises mostly newer members, and we consciously tried to support them in the aspect of domain knowledge. That includes the historical background of the tool and its features. There really are a lot of features, just like everyone has been saying. Some of the features are only used once a quarter, for example. If we get an inquiry about such feature, the member who will handle it might have a difficult time until they get used to the feature.

@waiting.lau：Just like hukurou said, this team has to deal with a very wide range of work. For the other teams, I believe that a new member could get started on their development relatively quickly, depending on their onboarding tasks, understanding of the services, domain knowledge, and experienced.

In the case of the CS Tool Team, however, you must communicate with other teams, especially CS. CS does many, many things when addressing inquiries about how to use the Mercari service. I’ve been here for five years, and still there are features I have never heard of. (laughs)

──Then allow me to ask on top of everything already explained: What is difficult about taking on a large-scale project to strengthen technological infrastructure?

@hukurou：We haven’t actually been able to get to the infrastructure strengthening part yet. We have been reducing direct database access, rewriting the frontend, and so on, but such work is very difficult to do while maintaining the tool at a level that does not create any blockers to the daily tasks of CS members.

Even if there is a certain part of the tool that we believe must absolutely be changed, it might be supporting a certain CS operation which was already optimized, so doing anything with it would knock many things over. It can be very difficult progressing our work considering its very wide impact.

──You just mentioned you haven’t been able to get to strengthening the infrastructure yet. What would you say is the percentage of your current progress in the RFS project?

@hukurou：It depends on where you set the ultimate goal for RFS. If it is defined as the completion of infrastructure improvement, we are still at 10–20%.

@Unsu：If the goal is for the work done in RFS to develop team culture and continue into the future, once again we are at a solid 10–20%. Our work has just begun. But in terms of the current phase we are intending to finish, we are progressing on schedule and aim to finish the project by the end of June.

A wide domain which should be considered as the foundations

──How would this foundation strengthening project affect your future careers?

@hukurou： We’ve repeated many times that there are so many features in CS Tool, but it has become what it is now, thanks to the help of many people. Some of these features are very important to the business, but some of them were not properly handled, just because it is “a legacy tool”. I understand it is not a nice thing to say.

It is a rare and interesting opportunity to be able to work on this tool that has supported Mercari for all these years and is vital for the business. I will definitely look back at it as a major experience.

@waiting.lau：The Mercari marketplace is the key product, so it is quite difficult to make big changes on it. “Difficult” here means “very unlikely unless it is necessary.” However, while CS Tool is also important for the business, the fact that it is an internal tool makes it much easier to make changes. And because we are working on such a wide domain, indeed it makes sense to consider the services as the foundation of our core business . I think it is indeed a fascinating experience of my engineering career.

Being the tech lead of Team 2, I have to consult with other teams in order to push forward the progress of our projects, but I often find it difficult to reach a consensus with all the stakeholders because each team has their own distinct requirements and expectations. Accepting every single request from our stakeholders is easy but it would also make CS Tool horribly complicated, eventually making it impossible to maintain. So we need to strike a balance between business needs and maintainability. I think CS Tool is a special domain which requires proper decision making process and guidelines in our daily work.

Jason Lau (@waiting.lau)

──I see, so it’s very important to set up the proper communication channel for you to manage the project better. Before we wrap up the interview, could you please tell us about your challenges as a manager.

@Unsu：Of course. RFS is a company-wide project, as you know. But sometimes another project pops up that is more aligned with the company’s priorities at that time. Then we have to figure out our priorities, how to run the RFS work in parallel with the other projects, and how to do it right – these are the most important topics for me. The team is larger than before, but not as large as it ideally should be.

If you ask me what is interesting about it, however, it is quite rare to see such a project focusing on improvement on a company-wide scale. I am thankful to be a part of it. Even after it is over, I wish to take what we have built and learned during the project and make sure they remain as part of our team culture. That also ties back to my challenges as a manager, I guess.

@Peranikov：It can be a problem to figure out how to measure the effects of this kind of system revamp. If it comes to boosting revenue or cost reduction, you are able to give direct business impact, and that is where you see the effects of your work. It is really difficult to define the performance indicators that might visualize how our work has strengthened the business. What I am trying to say is that we don’t have a mechanism in place to measure anything like that. Going forward, I would like to be able to see some figures and be able to explain to people the effects of our hard work. We have to keep in mind building a measurement mechanism, while still thinking of improving our systems for the long term. Juggling these two is a tall order, and searching for a way forward is a fun… but daunting task. (laughs)