In December of 2021, Mercari introduced a new service, Merwork on a trial basis.

Through this service, users carry out tasks in the Mercari app, which earns them Mercari points. The data collected from this contributes to improved quality across all of Mercari’s services.

Meet Ayman, the Engineering Manager (EM) who launched the development team for Merwork, and had previously been working on the New Business Team.

Launching a new product is complete chaos, says Ayman. You have to work with new members from both inside and outside of the company to overcome countless difficult problems to which there is often no “right answer”.

So what kind of team building has allowed Mercari, a company that has historically launched and released many new services based around the flagship Mercari marketplace app, to overcome that chaos?

To find out more, we spoke with Ayman about the release of Merwork, and about Mercari’s collective knowledge and experience when it comes to launching services and team building.

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

Merwork—the new service that transforms users’ idle time into value

──To start things off, could you tell us a little bit about Merwork and the concept behind it?

Sure! We developed Merwork to give practical use and value to our users’ spare moments, leveraging the Mercari app.

We started from the idea of, “what if we could create a new job market where users help improve their favorite services whenever they have a bit of free time?”

More specifically, when users select the “work” option from the Account page of the Mercari app, they can answer yes or no to the questions displayed on their screen. Once they’ve answered all of the questions, they’ve completed the task. Merwork rewards participating users with points that they can use on the Mercari app.

The answers that users submit are used as data to help improve the quality of Mercari’s services and features, and are supplied to our internal development teams as feedback.

The work available on the current version of Merwork is called “synonym check” and consists of users answering whether or not a particular word is a synonym or match for another word.

For example, the user may see the following two words: “bag” and “Bag”. The user can then answer with ○ (yes) or × (no) to indicate whether or not they think these two words mean the same thing. By providing the data from answers like these to our development teams, we can improve the search feature on the Mercari app.

In other words, users are not merely answering questions to earn points for themselves, they are also contributing to the improvement of the Mercari app as a whole. These aren’t just some menial tasks or busy work; Merwork is about transforming our users’ time—and their desire to make the Mercari app easier to use—into value.

Right now, we’ve only implemented the fairly straightforward synonym check work, but we plan on releasing more and more of these micro-jobs in the future.

──So what is your role in all of this?

As EM, my job is to do things like team building, as well as designing development methods and release processes, such that each individual member of the team can make full use of their diverse backgrounds and specialties. At the same time, I am also cultivating an environment conducive to product development.

Until two years ago, I was EM of the New Business Team, but the launch phase of the project I was working on ended, which left the team in a really stable place.

Just when I was beginning to think that I wanted to be involved in a more challenging project and step outside my comfort zone a bit—I started to hear about Merwork. I immediately threw my hat into the ring!

At that time, Merwork was still in its infancy—no specifications or even team members had been decided—it was just a bunch of churning problems that needed solving.

──I see. So you pretty much started from scratch, assembling a team and ironing out the service specs from square one! Now, in terms of product development, do you have anything in particular that you like to focus on?

So for product development, there are basically three overarching themes that I like to emphasize.

The first is that while development starts with small steps, you have to dream big. My thought was that the product needed to be designed so that it could scale if we were to make it a service that had merit for all Mercari users, both in Japan and abroad.

The second thing is modularity. Right from the start, I wanted to rein in development costs, so I focused on creating a reusable system.

In other words, I wanted to make sure that, for instance, elements like the question display that prompts users with micro-jobs and the reward system for when users answer questions could be recycled and applied to similar services.

The third thing is spacing out our big sprints into one-week increments to ensure agile development. I wanted to have frequent sprints, especially during the period leading up to the release of the first version. I strove to implement flexible development methods so that we would be able to quickly respond to big changes.

From Day 1 Onward: “The Three Values”

──I’m sure that team building was another hurdle in the early days of the service. What were some of the key issues involved in improving team member performance?

In assembling a team comprised of members from both inside and outside the Mercari organization, we ended up with a group of incredibly diverse individuals. While that in and of itself is a great thing, I’m sure you can imagine how difficult it is to bring all of those diverse backgrounds and differing opinions together as one team.

You may be familiar with the tiered “Form, Storm, Norm, Perform” process of team building—I wanted to get the ball rolling on this as soon as possible.

──So what kind of specific measures did you employ?

Well, first, I established the “Three Values” from the very first day. Mercari has a strong, company-wide culture that places a great deal of importance on values; I was able to use that as a foundation for my team building.

The first value of the Merwork Team is “Trust”. In other words, the ability to rely on one another, and to count on each member to fulfill their work and decision-making responsibilities to the team. I also decided that it was important to the team that we not call into question the actions of our fellow team members.

The second value is to create a “Blameless” culture. This means taking ownership and not shifting responsibility. Even if someone else makes a mistake, we don’t blame or attack them; we try to solve the problem and learn from the situation.

And the third value is to create lots of opportunities and spaces such that members can speak up in an “Open” manner. To achieve this, we came up with several of our own methods for discussion and communication.

One of those methods was the use of a monorepo architecture (a single repository for all of the code used in our projects). When a new suggestion or opinion came up, we would save it into the monorepo as a draft. Naturally, we also included pros and cons with each entry.

We established a flow whereby we first debated new ideas or proposals within the team, and then shared our conclusions with microservice, architecture, security, and other teams to hear their opinions, before conducting a final review ourselves.

In addition to initiatives like that, we also set up a weekly meeting for which we set no particular theme or agenda.

This is a pretty common team building method at Mercari; instead of limiting the topics for discussion at the meeting, we try to create a space where anyone and everyone can feel safe and comfortable speaking their mind.

I really think that a lot of different problems can be solved by having these kinds of values, culture, and mechanisms.

──Managing the use of the monorepo in the chaotic early days of launch seems like it would be quite difficult.

Yes, it is incredibly difficult. That was actually one of the big issues we had to solve in the beginning.

Many different apps and services exist within the monorepo, and each uses a different programming language— one might use Go while another uses React or Node.js. Plus, each language has its own unique pipeline, so deployment, testing, and rendering are different processes for each one.

During that beginning period, one of the engineers on the team wrote a suggestion in the monorepo that we implement Bazel, a Google build tool, to help manage the monorepo. So we ironed out the pros and cons and held a discussion with the whole team, after which we decided together to implement it.

But, after actually trying it out, some people were of the opinion that Bazel was too difficult to use and that we should switch to another tool. The team was divided over what to do.

So, I had everyone go back to the monorepo and write their opinions in there so that we could organize the pros and cons of both options. We kept discussing and discussing until we came up with a solution that everyone could agree on.

Something that I think is very important when debating ideas like this is, at each step, to make sure that everyone is clear on the pros and cons. We ended up discussing both the pros of continuing to use Bazel and the problems we would face if we chose to do so. We also had an honest and open discussion about the problems we might face if we chose to switch tools.

It is crucial to maintain a culture that produces both mutual understanding and value

──In your opinion, what sorts of positive influences do these kinds of team building initiatives have on team members?

For everyone on the team, being able to choose tools and technologies to work with that everyone was already highly satisfied with made for higher motivation and better performance.

But I think the most important thing for me as a leader is to properly motivate and empower my team. This is something that I also focused on when I was EM of the New Business Team.

I’m sure that there are also people who believe that it is quicker, at least at the beginning, to have a top-down style of decision-making rather than having the whole team debate each and every thing.

But, I think especially on the technology front, top-down decision-making can ruffle a lot of feathers. Trust me, I have seen many instances in the past of people leaving teams because of top-down decision-making.

From time to time you do run into situations where a decision has to be made quickly, but even then I take the time afterward to reflect with the team, explain why that situation arose, and discuss with them why I made the decision that I made.

──Okay, last question. With Merwork now out of launch and into the growth phase, what kind of team do you want to be moving forward?

The Merwork Team came from humble beginnings, with only three members including myself. Now, we are quite a large team, with six engineers, three PMs, a product owner, a machine learning engineer, and a customer service professional.

But no matter how big we get, I really want the team to maintain this culture that we’ve built together in which each person is empowered, supported, and can work and learn freely. I really love what we’ve created, and I want to keep it going.

I want to be a team that values open discussion so that each person can recognize the value and meaning in their work.

Writer: Kanako Ishikawa
Photographer: Shota Akamatsu