This is the 17th blog post in our Merpay & Mercoin Tech Openness Month 2025 series.
I’m ntk1000, Engineering Manager overseeing both Merpay’s KYC and Partner Platform team. Today, instead of focusing on a specific team issue, I’d like to share our company-wide Engineering OKR initiative aimed at enhancing Developer Experience (DevEx).
1. Why DevEx?
Developer Experience (DevEx) refers to how smoothly and stress-free developers can work and how much they can focus on meaningful tasks.
In research proposed by Nicole Forsgren and others, "Good DevEx improves developer satisfaction and efficiency, leading to higher productivity and retention, and ultimately contributing to business success." (Reference: The SPACE of Developer Productivity)
Google also emphasizes "how much time developers can spend on truly value-generating work" and treats DevEx improvement as a key factor in product quality and speed. (Reference: How Google Measures Developer Productivity)
As such, DevEx is not just an indicator of development efficiency; it is a strategic theme directly linked to team health and product competitiveness.
With the rise of AI, business diversification, and global expansion, engineering organizations are becoming more complex. New challenges are emerging in developers’ daily work, such as difficulty in securing focus time and making autonomous decisions. As complexity increases, structural friction that cannot be resolved through individual effort or goodwill becomes more visible.
For example, the KYC and Partner Platform teams I manage play a platform role, providing common features needed by internal teams and products. Therefore, we need to pursue two goals: developing to meet the growing and global demands of services, and improving our own platform. In reality, most time and resources are consumed by the former, and improvements to the latter are delayed, creating a vicious cycle. This is a form of structural debt that cannot be solved by individuals or single teams.
That’s why we regard DevEx not as an operational or score-optimization issue, but as a strategic initiative to balance development team sustainability and product competitiveness. To empower teams to act autonomously in complex environments, the entire organization must address structural issues together. We chose a systematic, company-wide approach to DevEx improvement rather than leaving it solely to EMs and development teams.
2. Measurement as a Starting Point for Action and Dialogue
We adopted DX, a DevEx visualization tool combining qualitative survey data with delivery throughput and other quantitative data. The goal is not to generate a score, but to provide a catalyst for teams to reflect objectively on their work styles, articulate challenges, and take action for improvement. By combining qualitative and quantitative visualizations, engineers and EMs could share previously implicit challenges, which sparked constructive conversations.
To avoid “measure and forget,” we designed a quarterly improvement cycle. Surveys are not just numbers; they visualize team voices and support EMs and members in identifying and articulating underlying issues. This forms the basis for prioritizing and committing to improvements with shared understanding. Through this design, a continuous cycle of Measure → Decide → Act → Reflect has taken root.
3. Designing an Improvement Cycle That Works Across the Organization
Here’s how the improvement cycle works:
- Measure: Conduct a 15-minute anonymous survey each quarter
- Decide: EMs review results, discuss with the team, and identify areas to prioritize
- Act: EMs create action plans and lead implementation
- Reflect: Teams review the impact through retrospectives and the next survey
The core actors in this process are the engineers and EMs within each team. Meanwhile, Manager of Managers (MoM), Directors, and VPs are responsible for ensuring follow-through and resolving issues escalated by teams—so that local improvements connect to broader organizational change.
This process embodies the principle in Section 2: measurement is just a starting point for dialogue and action. The aim is not to fixate on scores, but to read between the lines of data and comments to develop feasible, meaningful improvements. The process is designed to be simple and repeatable, empowering team autonomy.
Because the cycle is quarterly and runs alongside regular work, each team is encouraged to focus on one or two areas of improvement to avoid overload and ensure execution. Specifically, EMs use vote counts, comment volume, and score gaps from company/industry benchmarks to identify top priorities through team discussions. From there, they choose realistic actions based on feasibility and consensus—not quantity.
In this initiative, we aimed to systematize DevEx improvement not as an individual or team-specific effort, but as an organizational mechanism and cultural norm. In our first cycle, we achieved 100% survey participation from engineers and 100% action plan submissions from EMs.
The following points contributed to ensuring a high participation rate:
- The process was established as a cross-functional initiative aligned with the engineering organization’s overall OKRs.
- We continually communicated the reasons and objectives behind focusing on DevEx improvements, not only to engineers but also to the entire organization.
- During the survey period and the EM-driven improvement planning phase, we held Lunch & Learn sessions (informal learning and Q&A sessions during lunch) to increase engagement opportunities.
- We organized multiple Open Door Sessions to address questions and concerns related to DX and the survey, helping alleviate doubts and uncertainties.
- Before starting the process, we introduced the entire improvement cycle at an All Hands meeting to foster understanding and alignment on the significance and approach.
4. Structural Challenges Identified Across Teams
This continuous improvement cycle works not only at the team level but also as an organization-wide system for reflection and support. As a result, we were able to surface structural issues beyond the scope of individual teams.
While we cannot share internal scores, some of the most common challenges included:
- Lack of Deep Work (uninterrupted time for focus): This refers to the issue of engineers not having enough time to immerse themselves in complex tasks that require deep focus. Meetings, interruptions, and unclear priorities disrupt focus. This issue received the most votes across teams. Solving complex problems requires deep focus, which is undermined by constant context switching. This is not merely a time management problem—it’s a structural issue related to how organizations operate.
- Friction in Cross-Functional Collaboration: Product development does not end in Engineering; it requires smooth collaboration with Product, Legal, CS, and others. As businesses diversify and organizations scale, the number of teams and layers grows. This issue showed the largest gap compared to industry benchmarks. In our KYC and Partner Platform teams, we recognize this too—we aim to provide seamless shared capabilities, but lack of readiness and rising inbound requests are creating friction.
These issues cannot be resolved by individual EMs or teams alone. They require structural and cultural reform—such as creating rules to protect focus time, and promoting self-service systems that streamline inter-team collaboration.
5. Insights from Our Own Teams
Example: Lessons from Teams with Two Domains
Looking at results from the KYC and Partner Platform teams I manage, “Documentation” emerged as a shared issue. The KYC team also reported domain-specific issues like debugging in production and development environment complexity.
Documentation pain points include unclear sources of truth and scattered tribal knowledge, leading to repeated questions and delays in resolving specifications. This directly impacts our ability to deliver as a platform team.
Recognizing the limits of traditional documentation practices, we have already begun taking the following actions.
- Building an AI/LLM-powered knowledge base using past support inquiries
- Creating an internal portal where engineers can ask natural-language questions and retrieve insights from historical design docs and codebases
LLMs offer flexibility in handling fast-changing, semi-structured information. While still experimental, we believe easier knowledge access directly improves DevEx.
6. Conclusion: DevEx Is Product Experience
To build great products, we must create great environments for those who build them. DevEx isn’t just about speed or efficiency—it’s about clarity, flow, and focus.
In this first cycle, we were fortunate to see strong engagement and 100% participation across the company. That’s a great start—but the real challenge is making this sustainable, not exhausting. We want to normalize DevEx improvement as a habit.
Importantly, DevEx is not just about engineering efficiency. It’s about improving product quality and delivery. When engineers can focus, they ship better outcomes for users. That’s the mindset we’ll continue carrying forward.
We’re still learning. If you’re on a similar journey, let’s share notes.
Let’s grow better developer experiences—together.
Tomorrow’s article will be by y-arima. Please stay tuned!
