This post is for Day 3 of Merpay Advent Calendar 2023, brought to you by @keigoand from the Merpay Growth Platform Team.
Introduction
This post describes the transfer of an engineering team to a different business unit to join forces for a common Growth Platform and how that led to a positive outcome.
Some background in the decision-making process is shared, along with insights on its execution and how the close relationship with product managers and growth teams was an essential element for team engagement, the critical factor for any change.
If you are in a managerial role, whether or not you are involved in a similar reorg, this reading might be helpful.
Definitions
Some readers may not be familiar with the fact that Mercari and Merpay are different companies. They both belong to the same group, but since Merpay is in the financial business, it is subject to specific regulations to operate. For that same reason, engineering teams work separately, and their processes sometimes differ.
To distinguish between the Mercari company and the Mercari group, we will sometimes refer to the company as the Marketplace because that is their primary business. Similarly, we will occasionally refer to Merpay as Fintech.
Our platform supports Growth teams. They differ from Product teams because Growth teams do not improve the core product or add new features. At the same time, they differ from traditional Marketing because they strategically change the product to engage customers. They enhance the application’s design to achieve what the name suggests: Growth, not just for acquisition, but with a strong focus on retention.
Finally, despite the difference, we sometimes refer to some Growth members as marketers because they also use traditional marketing techniques.
Initial state
For this narrative, let’s go back to before the Growth Platform existed. I joined the Growth domain in the Marketplace around June 2022. The team consisted of backend and client engineers. Client here means Mobile and Web (Frontend). An additional backend team was set up in the newly founded India Office. English was the primary language.
The team was called "Marketing Operations," which reflected our self-perception. We felt that we were there to support marketers. Before, it was called CRM (Customer Relationship Management) because it was also part of the team’s scope. The team’s mission was under discussion.
In parallel, there was also a team at Merpay. They consisted of backend engineers and communicated mainly in Japanese. They collaborated directly with Growth teams to implement campaigns for Fintech products.
So, putting everything together in a picture, it looks like this, with the two large circles separated by company:
Marketplace and Merpay teams were focused on their organization’s growth strategy, but both had similar missions. They enabled growth teams to run campaigns in the app containing:
- incentive/rewards: points, coupons, loyalty, discount/sales
- communications: banners, modals, notifications (e-mail, push, etc.)
Having them doing the same things did not sound optimal, but it was at least justifiable from a business perspective.
Motivation
For a few years, both teams were dealing with a legacy tool that was causing many incidents and slowing down our progress on new features. Over time, we started a dialog to decide about the future of that tool.
All Engineering and Product members agreed it would be much better to sunset that tool altogether. We started to consider that as a common goal across companies. And since it impacted our results directly, our board requested our commitment to terminate that tool in favor of an alternative solution.
Having a common goal like that triggered meaningful conversations among Engineering Managers. We realized that our tasks were roughly 80% similar. Our teams had different approaches to the same things, but there was much to exchange. By applying the Inverse Conway Maneuver, if our teams could collaborate more with each other, we could avoid duplicated efforts, and consequently, our systems would become more integrated over time. Considering the team wasn’t too large for applying that strategy, it seemed feasible.
With shared interests and a good perspective, we decided to set up a cross-company task force.
The introduction of squads
We defined a few squads for the backend to start a structured collaboration with a common goal of sunsetting the legacy tool. Here, we casually use the term squad as a simple group of people for a particular task. In this case, we refer to members from different companies.
Our squads had a few important elements:
- Report lines didn’t change: people reported to the same managers as before, even if they were working in different squads;
- Autonomy: Each squad had its Scrum routines and boards. Some decided to operate with Kanban instead of Scrum;
- Squads were temporary by design. Each quarter, we tried slightly different configurations.
Working in squads allowed us to disseminate knowledge across different teams, which was necessary for the mission to sunset the legacy tool.
In the first iterations, some changes were relatively large, impacting the entire squad scope, but progressively, the sub-domains became more evident, and the collaboration model settled down.
In other words, the cognitive load increased temporarily with the introduction of squads, but once the sub-domains became stable, engineers started having more focus.
The decision to merge
As time went by, managers from both companies held meetings to discuss how to improve the collaboration because we observed that keeping the current model with a few small squads would have only a minor impact in the long term. Even with a good alignment among product managers, each team still had its own agenda, highly influenced by their separate organizations.
The idea of transferring the entire team from one company to another and consolidating their mission and objectives, which we call a merge, appeared as an alternative. But choosing which team should move wasn’t trivial.
On the one hand, it would have been simple to merge them into the Marketplace, as there were more engineers there, and they communicated in English – which was not so common at Merpay. However, there were at least two factors that were of great relevance at the time of the decision to move all teams to Merpay / Fintech:
- Regulation: financial rewards must be controlled, and Merpay has followed strict rules since it was created, which are required by law for their operation. It would be difficult to comply with those standards if the teams were moved to the Marketplace;
- Product: Merpay was planning large campaigns to support new products, so the Growth teams had more projects. I’ll mention that again in the outcome section.
Going to Merpay meant we could collaborate more closely with the growth leadership. That proved to be an essential element later.
Planning phase
EMs asked each engineer of the Marketplace for their opinions about transferring to Merpay. We created a spreadsheet to collect and discuss their comments, ensuring everyone could say no.
Surprisingly, everyone was neutral or optimistic about the change! They agreed with the motivation factors discussed before, as we shared them transparently. Furthermore, the collaboration had already started, so it all felt like a natural next step.
Still, there was a lot of uncertainty and doubts, so we investigated them. A few company procedures were different, such as how to do an expense report. There were also a few bureaucratic steps involving the company change, but none seemed critical.
In hindsight, two factors were complicated:
- Bringing the team in India to collaborate with Merpay, as it was the first team abroad
- Approving additional QA capacity to adjust to the finance regulation requirements
The dialog and leadership support proved essential to resolve those issues.
We planned the team transfer to coincide with the beginning of the new calendar year. There was enough time to prepare additional documentation, schedule a kickoff meeting, and perform all the necessary HR changes.
Deploying changes
The mission and vision for every squad were clarified in the kick-off meeting. In brief, we were all about to build a growth platform to serve the two company verticals. Product managers provided many insights on what that meant; beyond sunsetting the legacy tools, we wanted to add new features, make our tools smarter, support other teams, and enable many important campaigns that depended on us.
So, all set and clear, we started rolling out changes. We consulted the team even for a few minor decisions, like restructuring our Slack channels and Jira projects.
While implementing changes, we realized that the most significant differences were in the engineering practices. Finance regulations influenced many processes, including QA, release, and incident handling. There were also a few deliberate choices that differed from the Marketplace teams, for instance, which libraries to use for e2e testing and the existence of middleware specific to Merpay.
Client engineers were slightly less impacted because the codebase was already the same across companies. On the other hand, backend engineers had to "bring their services" with them – changing their microservices’ ownership and doing an additional Production Readiness Check, a checklist containing additional verifications, for each of them. The Merpay team created excellent onboarding documentation supporting that transition.
Some engineers were going through an entirely new onboarding period, and it took us a few months until everyone was familiar with the Fintech processes. That period was a little bit tedious and sometimes confusing as we never seemed to reach an agreement. Still, the result was positive: the team improved at incident handling, was introduced to a reliable and dedicated QA team, and our releases became more trackable. Plus, several other positive side-effects started emerging that I want to emphasize later in this post.
Let me first share what our team looks like after one year.
Resulting structure
After many iterations, this is how the team’s work scope is defined. It is relatively easy to understand.
The backend comprises two areas, CRM and Incentive platforms, providing services for the group like "coupon as a service," "campaigns as a service," and so on. Client teams are cross-sectional teams that enhance our platform for other client teams in any company to consume.
Also, the team structure became straightforward:
It was nice to see the members stick together through the journey; a few new people joined, and the squads became more cohesive. We may consider transforming the backend squads into established teams and implementing report line changes soon.
Along the way, we collected some interesting data I want to share in the next section.
Squad Health Check
We’ve been applying a lightweight version of the Spotify Squad Health Check model to monitor the team’s engagement throughout the process. It is a self-assessment, but it provides important insights for managers of engineering teams.
The view above is just an aggregated version. Each squad ran separate health check sessions. In addition to the red/yellow/green scale, the team members shared their comments and points of view. The retrospective exercise by itself was worth it. It resembles a Scrum retrospective in many aspects but on a larger time scale.
I like that "Mission" has always been green, given all our efforts to clarify it.
Of course, there are many points to improve, as the charts indicate. Among them, the "Pawns or Players," the "Health of the Codebase," and the "Easy to Release" never recovered from Yellow – actually, it was sometimes Red. Reading through the comments, the connection between those items surfaced. We always deal with tight deadlines to launch campaigns, feeling like we have little control ("Pawns"), leading to technical debt and making new releases relatively tricky over time.
The team is on its way to getting rid of that vicious cycle with the technical direction incorporated into the roadmap, integrating services, improving internal tools, and providing more flexibility to the engineers from other teams to use the platform autonomously. In fact, they have already been collecting positive results in that direction, as we will see in the next section.
The outcome
To put some numbers, we distribute, monthly, about 1.5 billion notifications to our users related to promotional content and over a hundred million financial incentives of different types.
There were a few system failures and issues, but the team always reacted promptly to recover and prevent them. Hundreds of campaigns utilize the platform monthly, and engineers provide support for the internal tools, or "weapons," as the product managers call them.
Mercard reached 2 million users in less than a year (news), and Mercoin reached 1 million users in 7 months (news); behind the innovative features, we have witnessed how Growth teams used the platform and tools to engage our users with well-designed campaigns launched at an incredible pace, achieving astonishing results.
Many other achievements didn’t hit the news but significantly contributed to the results: new types of coupons were introduced in the app; integration with LINE accounts to send notifications to users; an entirely new service for supporting the Loyalty Program was created from scratch; a new type of coupon for listers was introduced; and so much more.
EGP Pages, the landing pages editor implemented by the frontend engineers, became a "big hit," an internal success case, powering many of those campaigns. After merging the teams, Merpay services were also integrated – the Mercard example above being just one of them. At the moment of this writing, we have over 150 campaign landing pages live, with more than 40 million views per month.
It is also worth mentioning that a few unused services were decommissioned, and a few services unrelated to growth were already handed over. Having a strong sense of mission makes it easier for other teams to understand the boundaries, too. That confirms the Conway’s Law effect, but we are just starting to see it. There is much more to come from integrating a few services that were split before.
Coincidence or not, we have seen the consolidation of growth and marketing teams’ objectives across companies. The existence of a unified Growth Platform may have inspired that change. Or, at least, enabled it. Our team participates in the Growth All Hands, where all members across the companies working on the growth initiatives gather, and we have a dedicated slot to present the innovations we are introducing in the platform.
That is evidence of how much the growth leadership trusts the team and how it was an excellent choice to bring them to work closely together, All for One.
Summary
Engineering teams related to Growth were split into different companies. By trying to resolve a common problem, a collaboration started. Over time, they gathered into one company and became a unified Growth Platform. That boosted their productivity, which contributed directly to the growth of the entire group.
To make a smooth transition while transferring team members, expectations were aligned in advance, changes were introduced progressively, and leadership support played an essential role in keeping the team engaged.
It wasn’t an easy journey, but we have many good reasons to celebrate at our traditional year-end party!
References
If you are interested in Growth Platform, please check out many talks from the last Tech Fest and the blog posts related to our teams and systems:
- More details about the collaboration with the India Office
- About designing for scalability
- About inner details of point distribution
- To know more about "EGP Pages," the WYSIWYG editor
- Implementing retry and recovery mechanisms
Last but not least, I want to mention "How We Reorganize Microservices Platform Team" from the Platform Team (by @deeet), which is a source of inspiration and quite a handbook for similar organizational changes.
Tomorrow’s article will be by Shion. Look forward to it!
