Review of My Three-Month Experience in a Company’s Mission-Driven Team

For the first time in my life, I participated as a developer in a mission-driven team. I’d like to share my experiences from this journey.

Motivation for Participation

I didn't initially have a strong desire to join a mission-driven team. However, when I was invited to participate, I started seriously considering it.

The Product Owner (PO) explained the problem the mission-driven team aimed to solve and why that problem was important. They also described what I could contribute and what I could expect in this role as a mobile client developer.

At first, I was excited about the opportunity to work on something different, but since this was a major decision affecting the long term, I carefully weighed the pros and cons before committing. I outlined the experiences I hoped to gain:

1. I wanted to participate in decision-making with a strong sense of purpose and contribute to product development.
2. I wanted to think in terms of key performance metrics and conduct rapid experiments to solve problems.
3. I wanted to apply agile methodologies and continuously improve processes.

After careful consideration, I decided that joining the team would allow me to contribute meaningfully to both my personal growth and the organization's development.

The first thing we did after forming the mission-driven team was to define a key metric that would guide our goals.

Defining Key Metrics

Our organization was formed to improve customer retention for our ride-hailing (taxi) service by delivering a high-quality riding experience. Additionally, since this was the company’s first attempt at allocating resources to a mission-driven team, we also had to demonstrate the effectiveness of this approach.

To achieve this, we needed to define measurable key performance indicators (North Star metrics like OMTM or OKRs) for the otherwise abstract concept of riding experience.

However, we faced challenges because:

• The available data wasn’t sophisticated enough to quantify riding experience accurately.
• There were two conflicting approaches:
  1. Prioritizing backlog items that had a clear causal relationship with riding experience over metric quantification, aiming for quick impact.
  2. Focusing on defining and refining measurable metrics first, then addressing them through backlog improvements.

We couldn't come up with a perfect North Star metric that satisfied everyone. Instead, we agreed to select multiple metrics that showed a strong correlation with riding experience and work towards improving them.

Although we didn't achieve a single ideal metric, the discussions helped team members develop a deeper understanding of the domain and align with the organization’s goals, which later facilitated decision-making.

Eventually, we realized that improving riding experience without a solid way to quantify it was problematic. Based on this lesson, the mission-driven team is now being restructured to focus on metric quantification.

Operating the Mission-Driven Team

With our goal defined, we needed to take action. The core purpose of a mission-driven team is to run fast experiments and iterate to achieve its objectives.

Implementing Scrum

To support rapid experimentation and learning from failures, we introduced Scrum as our agile methodology.

Initially, we implemented two-week sprints, time estimations, daily stand-ups, and backlog grooming. However, we lacked a clear understanding of why we were using Scrum. At times, I felt we were too focused on process adoption rather than its actual benefits.

To address this, some of us studied Scrum in depth, reading books like:

• Growing Together
• Scrum

This study later evolved into broader discussions on growth hacking. 😊

Through these efforts, we reinforced the ideal purpose of Scrum:

Focus only on what’s essential for achieving our goal, maintain frequent and transparent communication within the team, and use the successes and failures of short iteration cycles to continuously refine our processes.

However, implementing this ideal in a real-world team was far from easy.

Challenges and Improvements

Initially, the team didn’t fully align on the why behind Scrum. In hindsight, it would have been better to build consensus first before diving into process implementation. I, too, was overly focused on methodology rather than ensuring shared understanding.

Still, as we studied Scrum together, we began to see its value. Over time, we identified pain points through retrospectives and implemented improvements.

Some key improvements included:

• Using JIRA to quantify and track project progress, while continuously refining our usage to reduce overhead.
• Visualizing scenarios to help stakeholders understand and coordinate release schedules.
• Defining clear test cases during planning to ensure specification clarity and improve QA.
• Introducing a pre-dev stage to allow developers to better estimate workload and suggest alternative solutions early.

However, not all issues were resolved within three months. Some persistent challenges included:

• Estimation accuracy remained difficult to improve, and the retrospective-driven overhead sometimes became counterproductive.
• The qualitative and frequently changing nature of our mission metrics made it hard to measure and communicate the impact of our work.
• Since we were tied to external teams, we couldn’t easily adjust timelines, leading to overburdening team members when estimations failed.

Despite these challenges, the process of identifying and addressing issues led to clear growth, both individually and as an organization.

Final Reflections

After three months of experimentation and iteration, I revisited my initial goals:

1. Participate in decision-making with a strong sense of purpose and contribute to product development.
2. Use key metrics to validate hypotheses and drive improvements.
3. Apply agile methodologies and incrementally improve processes.

I felt somewhat unfulfilled in achieving goal #2. Late in the process, I started studying growth hacking and felt a growing need to work more data-driven.

However, in terms of goals #1 and #3, I gained valuable insights:

• I experienced both the strengths and weaknesses of agile methodologies.
• I deepened my understanding of our domain and worked closely with my team to solve meaningful problems.

For three months, I grew not just as a developer writing code, but as a product builder shaping real-world impact.

If you're passionate about making a tangible difference through your work, I highly recommend joining a mission-driven team. 😊