Mercari Group defines the role of Engineering Manager (EM) as a person who removes obstacles in the way of team members in order for them to maximally demonstrate their abilities.

At least one person now fulfilling that role expressed an interest in becoming an EM as early as his job interview. But when the time came, what was it like when he actually became an EM? How did it compare to his years of working as an engineer?

For this edition of Mercan, we sat down with Shu Yokomizo (@shu), an experienced software engineer and tech lead now working as a Merpay EM. Leading the interview is Merpay EM Osamu Tonomori (@osamingo), the person responsible for hiring @shu.

On revealing at his job interview that he was thinking about becoming an EM

@osamingo: Correct me if I’m wrong, but I believe we first met during your hiring process. Back then I was in charge of hiring for the Backend Team, so I screened documents, scored technical assessments, and also attended interviews.

I seem to recall asking you in the interview what you saw for yourself in terms of your career and future. You told me that you liked being an engineer, but that it was just one of the steps you had to take on your journey. You said, “I’m also thinking about becoming a Project Manager (PjM) or an Engineering Manager (EM) going forward.”

@shu: I sure did. Even before I joined Mercari, I knew that if there was something that I could contribute to—and not just as an engineer—I wanted to take on whatever challenge I could.

@osamingo: My impression is that there are a lot of specialists working at Mercari and Merpay. But what’s good about you is that you’re a software engineer with a really broad field of vision. You have the generalist mindset that Mercari Group is going to need to expand going forward. When I first met you, my thought was that you were the type of hire that we don’t see very often.

What was it that made you think about joining Merpay in the first place?

@shu: The main reason I joined was that one of my ex-colleagues—we had joined my previous employer at the same time—had switched jobs to join Merpay before me. That’s who told me how great it was to work at Merpay.

At the time, I’d been out of university for six or seven years, but I’d been working on the same service the whole time, and I was starting to crave a new challenge at a company with a different kind of culture—I wanted personal growth. That’s what made me start to consider changing jobs. Then, working through a job site recruiter, a Merpay EM approached me about a position, and I wound up having a casual meeting.

During the casual meeting, I was able to find out more information about Merpay as a product, and it got me thinking that a job at Merpay would allow me to use the knowledge, skills, and experience I had honed at my previous workplace—plus, the job looked interesting. That’s why I decided to join the company.

People encouraged me to shift gears from engineer to TL with my own style of leadership

@osamingo: Right after you joined Merpay, you worked on the QR Code Payment Team. What did you think of the job once you actually started working here?

@shu: Well actually, I walked into the company with next to no experience with Merpay’s technical stack, like Go and GCP. This is why, for roughly the first six months after I joined Merpay, I learned domain knowledge and learned about our tech stack by taking on development tasks intently.

After that, I moved to the Partner Platform Team, where I was in charge of things like the development and management of an order/inspection tool for merchants. At that time, the way we worked was that the TL would single-handedly take on everything from development to operations, consultation, and investigation, but I was told by my TL that they wanted me to take on roughly half of that work. This is why I focused on acquiring domain knowledge involving merchant products and implementing scrums for the visualization and optimization of tasks, all of which were meant to stabilize operations within my team.

A few months later, the TL on the team next to mine resigned. So I made the shift to TL of the Partner Platform Team.

@osamingo: Back then there were a lot of tasks to do, and I’m guessing that also made things a little chaotic. Did you feel like you had what it took to sort everything out from the outset?

@shu: At my previous workplace, I was in charge of a system overhaul project as a scrum master. When I was able to get the job done within a year, it occurred to me sort of out of the blue that I just might have what it took to sort out complex projects. (laughs) It’s easier to move forward with work as a team if everything is organized well, and it’s also better for the team to work that way too.

@osamingo: What was it like for you to become a TL?　

@shu: Honestly, at first I didn’t feel all that confident, because I thought that a TL without the skills to lead their team technically would be in a really tight spot. That’s roughly when you told me that being a TL is not just about technical know-how, and that there are people with a range of special skills doing the job. Some TLs really put a lot of effort into keeping the wheels of their projects turning, and still other TLs work while engaging in as little technical decision-making as possible. You told me that there were all kinds of TLs and that I should just find my own way of doing things. It was after that when I really thought about challenging myself by becoming a TL. And what I concluded after trying that position out, was that it was brutal. (laughs)

@osamingo: I seem to remember you saying that. (laughs) What was it that made it brutal?

@shu: The hardest part was keeping up with the pace of the development requirements while working with a small team. My domain knowledge was still incomplete even as I moved forward large projects like automating inspections, and having to reply to the investigation requests of PMs and operators. By implementing scrums, I was able to get all of these matters organized and move each one forward. As far as the issue of not having enough resources was concerned, I was able to solve this while consulting with you.

@osamingo: The projects that you were involved with as a TL had an army of stakeholders. It wasn’t just the people on the product and engineering side of things. There were also the members of Merchant Due Diligence, BizDev, Sales, and more. My impression is that your work required a lot of difficult communication. Was there anything that you tiptoed around where communication was concerned?

@shu: No matter what I was working on, I never labeled anything as impossible when first starting out, and I did my best to empathize with the positions of the people I was dealing with. Basically, everyone was consulting with us because they wanted to move in the right direction. So, when differences of opinion cropped up between people of different job types, in my communications with them I would try to see things from their perspective and ask myself how I could help resolve their issues and contribute as an engineer.

To develop the product, I had to become an EM and develop my team

@osamingo: So then you switched from being a TL to being an EM. How did that come about?　

@shu: Once I was comfortable with my work as a TL, I started to see that in order to make a difference to the development of the product, I had to become an EM and work on upgrading the skills of my team. Of course even before that, we had worked on improving our scrums and resolving issues as a whole. We also focused on team building for the development and product teams. Within that structure, we had also started focusing on training team members. One day, while bouncing ideas off of the EM I worked with at the time, I mentioned what I thought it would take for one of the new team members to accomplish our bigger-picture goals. I said, “he’ll need to grow, and the best way for him to do that, will be for him to do the task we’ve assigned to him.” It was then that my EM suggested to me that I try working as an EM myself.

At first I was like, I don’t know if I want to move away from where all the action is; it was a big decision. So I asked for some time to think about it. After roughly three or four months had passed, the pressure was on for me to step up and become an EM. I could have refused, but I thought that as Merpay grew and grew as an organization, there might not be another chance for me to work as an EM.

What’s more, at Mercari Group, there are a good number of members who go from software engineer to TL or EM, and then return to being a software engineer. Plus there are people like you who have their main job as an EM, but also have a side gig writing code. Realizing that a career path like that was even a possibility was also a huge driver for me, and so I took on the challenge of working as an EM.

@osamingo: Even if you’re interested in becoming an EM, it can take a while to get to the point where you want to do the job. There are some people who, up until the point in their careers where they start working as an EM, only work on products and systems. Suddenly their job becomes people-focused, and they remember that the reason they became engineers was because they’re terrible at communicating in the first place. (laughs) By my calculations, about a year has passed since you became an EM. So how has it been for you?

@shu: Up until I became an EM, I had the impression that the work of an EM was all about people management, but that’s not the case at all. Actually, apart from people management, I’m now in charge of things like working with a TL to come up with a team structure and direction for the Partner Platform Team and communicating with HR members about engineer hiring.

@shu: The thing that left the biggest impression on me was our response to the Codecov incident. The incident didn’t just affect Merpay; the entire Mercari Group should think long and hard about what happened. I was the owner of the project to completely delete sensitive data not just from the most recent version of the code on GitHub, but also from the history of the repository.

@osamingo: I get the feeling that you turned around and were suddenly running the whole show.

@shu: Yes, exactly. But I don’t think it mattered much who was in charge; our highest priority had to be on restoring operations back to normal as quickly as possible. That meant investigating the impact on each stakeholder, figuring out the pros and cons of each proposed solution, and then requesting the approval of the company leadership. I had to switch back and forth between English and Japanese while handling things, which made the work really grueling. In addition to putting together procedural manuals, I also created the necessary workflows. I’m glad that we were able to buckle down and get the job done.

@osamingo: I think doing all of that in your first year of being an EM personifies Go Bold. What you said just before about working to empathize with the position of the people you are communicating with also impressed me. Being able to do that consistently even after becoming an EM is commendable.

@shu: It’s one of the few implements I have in my toolbox, so that’s what I’ve used to hammer away at the issues I face.

The importance of sense of purpose as a Merpay EM

@osamingo: So what would you like to do going forward, @shu? What do you picture when you think about how you’d like to evolve?

@shu: First of all, I’d like to invest some of my energy into hiring. As Mercari Group grows, if we fail to hire new members, there’s a danger that our business will stagnate. So that’s why I’d like to make an effort to work on hiring. Once I have that under my belt, I’d like to work on something that looks at the direction the company will take from a big-picture point of view. I’d like to look at what our entire engineering organization will do going forward—and from a further macro-level perspective—what Merpay will do going forward, and expand the impact I can have little by little.

@osamingo: What sort of mindset do you think indicates that a person might be ready to take on the challenge of becoming a Merpay EM?

@shu: Someone who has a strong awareness of what All for One means. Engineering is intrinsically just one part of the picture, right? So then what does matter? Well, the achievement of Merpay’s mission, or rather the achievement of Mercari Group’s mission. I think that if you have a strong awareness of All for One, even someone who now spends their workday laboring at their keyboard writing lines of code as a backend engineer can potentially excel as an EM.

@osamingo: They say that management is a skill. The positive side of thinking of management in this way is that it’s a skill that relies on individuals that can be learned, and for that reason a person’s sense of purpose is crucial.