Onboarding Program​

MongoDB's onboarding was, hands down, the best new-employee orientation I've experienced across five companies.

The Leadership Commitment series, held over several weeks, was a core training program covering MongoDB's product design philosophy, core values, leadership principles, the customer journey, and inclusion. It was remarkably dense and well-delivered. What stood out in particular was that much of the content was presented directly by company executives, including the CEO.

The new-hire technical training was a twenty-plus-hour program covering MongoDB's core features, document data modeling, Atlas (MongoDB's cloud developer data platform), indexes, distributed architecture, and administrative capabilities. After watching chapter videos, we took quizzes to check our understanding. Being able to run examples directly on a provisioned MongoDB cluster was a huge help for hands-on learning.

Beyond the company-wide onboarding, there were also organization-specific programs. I worked through the new-employee training materials for both Marketing and Developer Relations, which helped me get familiar with more day-to-day operational information.

About the Role​

In my previous post, written before I joined, I briefly described what the role would involve based on the job description and what I'd learned through interviews. My first six weeks were, more than anything, a time for developing a much deeper and clearer understanding of the work ahead.

Just as MongoDB's tagline is Love Your Developers, developers are at the core of what makes MongoDB successful. MongoDB's Developer Relations team improves and accelerates developer productivity through a variety of Advocacy & Enablement programs:

• Creating content that raises market awareness and drives adoption
• Educating developers through workshops and live hands-on sessions
• Engaging strategic customers and providing data modeling consultation

First Business Trip​

In my second week, I went on my first business trip: MongoDB Days held in Manila and Ho Chi Minh City. Since the events included developer training and data modeling consultation, activities that would become part of my work after onboarding, it was a chance to experience those things firsthand ahead of time.

With DevRel APAC teammate Sourabh	With DevRel APAC teammate Wenjie

What I was most grateful for was getting to meet my fellow Developer Advocates on the DevRel APAC team in person. Events tend to thin out toward the end of the year, and joining in November meant the timing worked out perfectly. Sourabh and Wenjie are seniors who started as Developer Advocates at least a year ahead of me. Watching them deliver various sessions with such charisma and professionalism made me want to reach their level as quickly as I could.

With ASEAN regional staff after the MongoDB Days Ho Chi Minh City event

I also got to meet Solutions Architects, Field Marketers, and Customer Success Managers from across the ASEAN region. Seeing how Developer Advocates collaborate with them in planning and running an event was enormously helpful. In between sessions and at the group dinner afterward, I had wide-ranging conversations with staff from all over the region.

A second business trip is planned for Taipei in January, where I'll run my first developer session at MongoDB. I'm nervous, but excited.

Introduction to the Korea Office​

The Jamsil view from the Korea office

It goes without saying that bringing on someone based in Korea is about building programs for key customers and developers in Korea. So over these six weeks, I've had various opportunities to introduce myself to members of MongoDB's Korea office. Drawing on the model of how Developer Advocates work alongside local teams across APAC, we'll gradually build a similar collaborative structure in Korea.

Last week I attended the Korea office's year-end party. The culture of an international company, I found, has its own distinct character compared to the Korean IT companies I've worked at before.

Communication, Communication, Communication​

What struck me most was the open, multidirectional communication flowing throughout the entire company.

My manager Nick regularly set up 1:1 sessions to check in on the onboarding process and sincerely ask whether there was anything he could help with. Whether it was checking on my well-being given Korea's political situation at the time, or reminding me to put family first whenever something came up, I genuinely felt looked after, both as a person and psychologically. The separation between managers and ICs was something I'd only heard about before; joining MongoDB was my first time experiencing it. I could feel the ease and comfort that having a dedicated manager gives to individual contributors.

I also had casual introductory sessions with six or seven people I'll be working closely with from various teams, hearing about their roles and responsibilities. I used those conversations as opportunities to talk about my own background and interests. Being in an environment where expressing interest in something, or asking questions without hesitation, felt natural and encouraged. It was refreshing and fun.

Finally, I attended two monthly All-Hands meetings with direct participation from C-level leaders. Employees could submit questions in advance or ask in real time via live chat; the topics ranged widely and went deep, and the executives' answers were candid and unguarded. I was genuinely impressed.

That wraps up a record of my first six weeks at MongoDB. I'm looking forward to the days ahead. January and February will be when I start taking on real work. Let's do this well.

My name carries a Buddhist meaning, and my family practices Buddhism. Yet for some reason, I attended a kindergarten run by a Christian organization. Most of those memories are too distant to recall clearly now, but one person stands out. Someone who opened the door of the school van and made sure we arrived safely each morning and afternoon, who asked how we were feeling at the start and end of every day, who watched over the children and gave advice on how to get along better with friends. We called him the jeondobsa-nim, the evangelist, and that is what the word has always meant to me.

Tech Evangelist​

Many years later, having grown up, I found myself doing the work of an evangelist too. Only, instead of the Korean word, the role goes by the English name "evangelist," specifically a tech evangelist, because it involves building relationships with developers through a specific technology and cultivating a technical ecosystem around it.

The work a tech evangelist does has much in common with what my childhood evangelist did. It means guiding developers on their first journey into a technology product, watching out for any difficulties they encounter along the way, and spreading the word about how best to use it.

My move toward this direction is closely tied to the interests and tendencies I've described in earlier posts on this blog. Throughout my time as a developer, I always kept an eye on the areas within the tech industry where communication and care were lacking. If there's one thing that sets my heart on fire while I work, something ikigai-worthy, it's developer experience.

Just as B2C products don't sell themselves to consumers, technical products used by developers don't sell themselves either. The process requires constant communication and attentiveness toward developers inside and outside the organization, along with the documentation and training they actually need. That kind of effort will likely take the form of dedicated people assigned to do exactly this work. That is what a tech evangelist does.

My Experience at NAVER Z​

The first place I experienced tech evangelist work was NAVER Z, the company behind the metaverse service ZEPETO, where I worked until recently. It was a broad role: building an ecosystem of developers using a tool called the ZEPETO World SDK, delivering technical content to developers, and handling everything from training to technical support. In Korea, where B2B SaaS and API/SDK-based technical product businesses haven't yet fully taken root, it was a rare opportunity. The particular draw was that ZEPETO had already built up a global user base, meaning I could work with developers and partners from countries all over the world who were building ZEPETO Worlds.

Once, I provided technical support via video call to a company in Israel. They were under a tight launch timeline and needed a feature that was absolutely essential to them, so they asked whether I could relay their request to the SDK development team. I listened to their requirements, filed an issue with the development team, and the new feature was prioritized and developed relatively quickly. I then wrote up how to use it and personally walked the partner through it in a follow-up session.

The whole process was genuinely fun and rewarding for me. And beyond that, I discovered that writing documentation for developers and creating sample code is a domain with its own kind of satisfaction and career potential, distinct from writing code as a developer in the traditional sense. Due to the direction the company's operations took, I wasn't able to do the evangelist work as long as I had hoped. But my appetite for doing this more deeply and professionally, helping developers and partners succeed through communication with technology, only grew stronger.

A New Challenge: MongoDB Developer Advocate​

Then, about three months ago, I was contacted by a MongoDB recruiter on LinkedIn. The message asked whether I'd be interested in working as a Senior Developer Advocate at MongoDB. I took an exploratory call, thought it was a good opportunity, and applied. I went through a total of ten interviews over about a month and a half, and after accepting the offer, I start tomorrow.

Developer Advocate and tech evangelist are similar roles at a high level, but there's a nuance in the distinction. In particular, moving away from the religious connotations of "evangelist," "advocate" implies siding with the developer, acting as a bridge between developers and the company providing the product.

As a Senior Developer Advocate, I'll be working alongside talented teammates I'd already met multiple times during the interview process, carrying out developer enablement and community-building activities for MongoDB across APAC, including Korea. This will primarily involve writing technical educational content aimed at developers, running workshops, and leading hands-on sessions. Working with the field marketing team to build effective strategies for engaging with customers and developers is also part of the role.

I'm going into this new opportunity with genuine excitement and anticipation. I hope to put my past experience together with what I'll be learning, and contribute to the team quickly. I'm already looking forward to sharing what I discover through this blog.

The Meaning of a Gift​

When we try to understand something from a new angle, we often turn to metaphor. Seeing technology as a gift starts with understanding the essence of a gift itself.

The "This is a gift" checkbox you encounter when ordering on Amazon doesn't simply signal a functional difference: no receipt, add a message card. It represents something deeper: thoughtfulness. When we choose a gift, we think beyond the transaction itself. We think more carefully about our relationship with the recipient, about what they actually need. We move past the bestsellers and algorithm recommendations, and instead make deliberate choices from options selected with the recipient's tastes and situation in mind.

Seeing a Friend's Name as Nothing More Than a String​

I came to understand just how important this shift in perspective really is through a small incident during the program.

On day three, a Japanese participant named Kiwako proposed a "coffee chat" idea for students, SFPC instructors, and YCAM staff. The idea: gather people who wanted to participate, randomly pair them one-on-one, and give everyone a chance to get to know each other. Jim, a Thai participant, and I volunteered to build the random matching system. Jim took the front end; I handled the back end, writing the matching logic and the code to store matching records. Implementation took a single night. On the first day the system was available, everyone who signed up found their partner on the screen and spent time together.

The incident happened on the second day of running matches. That day, the number of sign-ups was odd. Our system handled the last unpaired person like ("John Doe", ""). A friend named Takashi appeared at the very bottom of the screen without a partner, and he looked somewhat confused. Kiwako quickly added him to the last group to make it a three-person coffee chat, but I felt a deep sense of regret. Until that moment, I had been looking at the list of names as nothing more than an array of text data. I hadn't thought at all about the experiences and feelings of the people behind each name.

If only I had seen this system as a gift for people who were looking forward to the moment of connecting with someone new...

Giving Gifts to Developers Too​

Since that small incident in 2019, I've carried with me a mindset of treating the products I work on as gifts. In truth, seeing a product as a gift aligns with the User Experience (UX)-centered approach to product design that has become widely adopted across the industry. But the context in which we usually discuss UX tends to be limited to end users of B2C services.

As someone who began their career as a backend API developer, what I found myself thinking more deeply about was Developer Experience. Whenever I encountered undocumented APIs hiding behind "it's just for internal use," documentation that the author clearly hadn't read themselves, or endpoint designs built on no discernible principles, I kept asking the same question: why, after dividing software into modules, adopting microservice architectures, and reshaping organizations to match, are we so negligent when it comes to organizing the protocols these systems use to communicate with each other? It's even more disheartening when I sense an attitude of "build it and they'll figure it out" in the products of companies that provide APIs or SDKs to business customers.

But shouldn't developers deserve good gifts too? We ought to place far greater value on the act of giving gifts to developers. And those gifts will ultimately have to be something we developers give to one another.

All this time, I've been searching for a role where I can put these ideas into practice. Starting in November, I'm beginning a new challenge as a Developer Advocate. When technology becomes a gift, we move beyond mere feature implementation and think more deeply about the experience of both users and developers alike. That, in turn, leads to a better development culture and better products. I'm now ready to seriously explore and practice what the perspective of "technology as a gift" can bring about.

Next post topic: Someone who delivers technology as a gift: starting as a Developer Advocate

I love reading manuals. Before I touch almost any consumer product or service, I need to look through its design intent, features, and branding copy. I remember my friends finding it odd that, after buying my first car, I left it untouched and read the manual from page one. I'm the sort of person who reads "Health Benefits of Buckwheat" at a restaurant while waiting for the food.

That is how I enjoy a product. A good manual puts me in a good mood before I've even started using it. Product documentation, to me, is an important part of the user experience. Having absorbed so many different kinds of documentation over the years, I've naturally developed opinions. Lately I gravitate toward documentation that commits to user empowerment. I'll write about that separately.

A Developer Who Communicates​

This interest carried over into my career as a developer. Over the past ten years, I actively sought out opportunities to explain the products I worked on, in many different forms. Here's a rough list:

• Writing user guides, API reference docs, and release notes for B2B, B2C, and internal products
• Writing sample code for SDKs and building demo applications
• Running technical support sessions for partners and individual creators
• Preparing materials for in-house technical presentations
• Operating the company tech blog and research archive contribution process

Throughout my time working in teams, I've always believed in the power of clear explanation. For an organization to move without wasted effort, I think it's crucial that everyone understands the purpose of the work and stays aligned. As a team member, I supported leaders who took time to explain. When leading teams myself, I worked with the conviction that the time I spent writing something down saved far more time for everyone who would later read it, multiplied by however many people that was.

For example, I valued writing a Readme for internal projects, or producing clean migration guides when APIs changed. I treated sharing a meeting agenda beforehand, distributing meeting notes afterward, and keeping the team's documentation up to date as core responsibilities.

As a developer, I've always found a quiet satisfaction in work that involves explaining something. I consistently got good reviews in the "communication" category, and I thought of this as my particular edge inside a development organization.

Expanding Beyond Being a Developer​

Having someone like me on a development team was probably a useful complement. But as years passed, I started wanting my career to grow in a broader direction. If "communication within a development organization" was my strength, I wanted to build real expertise in it and extend my influence. That's when I realized there was no clear path upward on the developer track that matched where I was trying to go.

Around my seventh year, during a backend developer interview, the interviewer asked: "What would you want to do first if you joined the team?" I answered honestly: "I'd start by assessing whether our API documentation is in good shape and work on improving it. And if there are any request parameters or response fields in the API that serve no real purpose, I'd clean those up." The interviewer tilted their head.

Putting moments like that together with the bigger picture, I came to the conclusion that "communication skills" as a developer didn't, at their core, lead to materially better outcomes for either me or the company. The strength I thought of as my weapon was starting to read more like "I'm a decent person, really." I became convinced that to build genuine expertise and expand my influence using what I was actually good at, I'd need to move beyond being an individual contributor developer into a different role.

Starting This Blog​

The search and trial-and-error involved in that transition is still ongoing, and it isn't easy. In a world changing this fast, it may be something I have to keep working through for as long as I'm working at all. Some days feel unsettled and anxious. Starting this blog is, in part, an attempt to soothe those feelings a little.

I can't be the only person wrestling with the same questions. I hope this blog becomes a place to share thoughts and information about navigating a career. And maybe, just maybe, someone who is looking for exactly what I have to offer will find me here, and something new will open up.