I’m @snamura, Mercari CTO. I’ve been asked to conclude the Mercari Advent Calendar, so I’m going to try my hand at writing a blog post even though it’s not something I’m exactly used to. I’ve spent the entire past year working on the engineering organization, so I’d like to talk about that here.
I spoke about this at Go Bold Challenge, one of Mercari’s recent conferences. You can find the details here.
I became CTO in April 2019 and began overseeing Mercari’s engineering organization in Japan. There were too many issues to count, so I spent the last year doing things that needed to be done, one task at a time. I thought about topics like what kind of engineering approach would be right for a service like Mercari. It’s still very much a work in progress, but I’ll take this opportunity to conclude the Advent Calendar by summing up what we’ve done up until now and what we’ll be doing next year.
What kind of engineering organization we’re aiming for
My goal as CTO is to establish an organization where all engineers can think proactively and make decisions on their own. This is much easier said than done, and the past year has shown us how difficult it would be to achieve this goal with an organization of several hundred engineers, in a business that is expecting major growth. I’ll be talking about the decisions I’ve made in the past year while working towards that goal.
Engineering Principles
id:tutti has already written about this, but the engineering culture has not been clearly stated, meaning that the criteria for engineers’ decision-making and evaluations has been vague this whole time. In response to this, we got engineers involved to create a set of principles and code of conduct.
The number of engineers nearly tripled in the span of 2 years, and Mercari’s small startup culture has faded. Many things that used to be feasible with a small company had to change as the organization scaled. One of the first steps towards helping everyone understand the company culture involves making a clear statement about what Mercari expects from its engineers.
Engineers hailing from various countries have joined, and English skills have become more and more important. Our approach when making the Engineering Principles was to create them in English and translate them into Japanese. Making a “high-context” document like this in Japanese and translating it into English would actually have been extremely difficult. The opposite is certainly true as well, but we believe that English would be more direct due to the nature of the language, and that’s why we took this approach.
Engineering Ladder
We are making a ladder system to set an evaluation system and expectations that everyone can agree with. Mercari uses the concept of grades, and has definitions for what actions are expected for each grade.
The Engineering Ladder is specialized for engineers in defining what actions are expected from them. They are based on the Engineering Principles and include specific details regarding these expectations. We evaluate engineers not based on their business output, but rather based on the actions they took.
Mercari aims to promote understanding of its culture by properly evaluating the engineers who embody the company’s engineering goals and values.
Data-Driven Decisions
The goal of Mercaris engineering organization is to provide users with the best possible experience. However, the idea of what makes the “best possible experience” varies from person to person. We are assessing the features we make by quantifying what makes something good for the users and for the company. Many decisions are being made, but it’s important to ensure that these decisions are consistent in propelling us in the right direction.
We are also promoting feature flags (used to control individual features and measure their effectiveness by turning them on/off) and data platforms in order to make data driven decisions in all areas. Although we haven’t completely reached that state, we’re aiming to release all features next year starting as feature flags.
Engineers’ creativity and innovation
Certain types of work naturally become prioritized when we keep business output in our minds and set high targets for performance. If we constantly only focus on things considered high-priority for the business, there is a risk that engineers will lose their ability to proactively create things by themselves. To accelerate innovation, it’s important to give engineers special opportunities to experiment with and show off their brilliant ideas.
Mercari believes that nurturing engineers’ creativity and giving them chances to create innovation are both forms of training. This year, we held Hack Week as a way to let engineers return to their roots as creators, forget about the business goals for a period of time, and do whatever they wanted for a week. Please feel free to check the article below to see the results. Hack Week is an internal event generally held twice a year, and the next one will be at the end of March.
メルカリ全エンジニアが参加した1週間の「Mercari Hack Week」結果発表！受賞したのは？ #メルカリな日々 | mercan (メルカン)
Aiming for a development structure that makes its own decisions
Id: As written by stanaka, we are aiming for a structure in which decisions can be made in smaller scales. For microservices, we need to think not only about technical approaches but about organizational approaches as well. Next year, the Backend Team’s structure as a domain team will change into one that is cross-functional, becoming a team making decisions regarding microservices.
In addition, having product development focus too much on business numbers can cause teams to lose motivation or morale. To prevent this, we need to verbalize and clearly communicate exactly why each team is focusing on certain tasks and what Mercari wants to achieve.
Revising the processes behind remuneration-related decisions
Decisions regarding salary have a high cost on managers, and are also extremely important to members. Giving feedback to members also takes a toll on managers. To help with this, we are going to change the remuneration process using a new method that is fair and agreeable to members.
We plan to share this process externally after operations are going smoothly.
Our approach towards technical debt
By pushing for the transfer of control over microservices, we aim to slowly reduce the technical debt and transition to a modern tech stack.
Aside from the previously-mentioned Hack Week, we decided that every six months, we would run a two week long Scrum sprint where members focus entirely on solving technical issues. All usual development will be paused during this time so that members can remove technical debt and have more time to focus on areas of the product code that they normally do not have time to work on. These two weeks are considered a sprint buffer.
Innovative ideas are turned into reality during Hack Week, and creative work on the product is done during Sprint buffers. Having this split should help push for both business growth and individual growth.
Guidelines for rewriting code
Mercari has been making changes and additions to the same codebase ever since the service launched. We are aiming to resolve this as the Backend migrates to microservices. In the same way, the architecture for the client side will also be revised accordingly.
What we’ve come to understand from our previous experiences is that maintaining existing code while slowly revising it is much more costly than making new code from scratch. This has taught us that regularly rewriting code is something that can’t be avoided when operating a product for a long time and making it grow further. In addition, rewriting code helps remove complications and reliance on specific people, and also makes everything more modern. We are now making guidelines for adding engineering resources for periodically rewriting code.
A rhythmic development schedule
We are currently aiming to make a more rhythmic development schedule by making clear timelines and visualizing the ideas behind annual decisions, development-related decisions, and various other decisions. Members can’t work to their full potential when there are uncertainties. If members have a clear understanding of what will happen at what time, they will be able to work better and more efficiently.
For example, we will follow this schedule every six months: Four sprints -> Hack Week -> Five sprints -> sprint buffer.
This clearly defines the time that members can spend on development. In addition, we want to make further improvements and make the flow of information smoother by clarifying the schedule for management meetings and company-wide All Hands meetings.
Future goals
The past year was spent levelling the grounds in preparation for new things. The following year should be one with visible results from all the approaches mentioned above, so I hope to have more to share in the near future. Wishing everyone a Happy New Year!
