6 Lessons Learned from Being a Project Leader

This article is the Day 3 post for the YAMAP Engineer Advent Calendar 2021.

Hello, I’m Kaoruko from the YAMAP development team.

Since August this year, I’ve been working as both a project leader and a frontend developer. In this article, I’d like to reflect on the lessons I’ve learned in this role. It might turn out to be a bit of an abstract poem.

What kind of project is this?

In the project I’m involved in, the development team primarily discusses how to achieve the ideals and goals set by the business side.

Instead of simply implementing the specifications we’re given, we engineers actively participate in the creation process, which makes it an exciting environment.

The project itself is exploratory and experimental, and clear numerical targets are often not defined. Additionally, the organizational structure is flexible, with a “those who can do, will do” startup-like culture, which makes many aspects uncertain. For me, it’s a bit of a stretch project.

I’d like to share six lessons I’ve learned through feedback from team members and one-on-one brainstorming sessions.

1. Preparation is 80% of a meeting

“We have so many meetings, yet somehow, we don’t feel like we’re making progress.”

This was the first piece of feedback I received. The key to an effective meeting is to clearly define the agenda and goals. However, I realized that alone isn’t enough. It’s also important to imagine what is needed to reach the goal, how many steps it will take, and the process to get there.

At YAMAP, our development process is highly data-driven, and discussions rarely occur without data. I learned the importance of preparing sufficient data and organizing my thoughts beforehand. Having a draft makes discussions much easier than starting from scratch.

Additionally, sharing data and thoughts in advance is crucial. It saves time, and others can point out missing information.

2. Finding the balance in schedule adjustments

Even if development progresses as planned, unexpected events can always arise—user notifications, coordination with other departments, passionate internal feedback, etc. Product development isn’t just about implementation and release.

While identifying stakeholders and managing risks are essential, it’s equally important to remain calm and find the best compromise when things don’t go as planned.

Sometimes, you might want to push through a plan with some extra effort, but if risks appear, it’s better to reevaluate the schedule calmly. It’s tempting to try and sprint to the finish line (maybe it’s my slightly competitive mindset), but I’ve learned that finding an optimal balance, assuming challenges will arise, is the key.

3. Find your “neighbors”

In agile software development, there’s a framework called the inception deck, which is used to create documents summarizing the project’s purpose and background.

One of its sections involves “finding your neighbors,” essentially mapping out everyone involved in the project. I underestimated this and ended up causing some inconvenience to other teams.

Just as we have our circumstances, other teams have theirs. By identifying stakeholders and clearly communicating early on, you can set expectations, mitigate risks, and foster mutual support. Maintaining good relationships with your neighbors is essential.

4. What isn’t the goal is just as important as what is

Defining the project’s goals is crucial, but equally important is defining what isn’t the goal.

Without clarifying what’s not the goal, discussions can endlessly diverge. Ideas can expand vertically and horizontally, leading to scattered opinions, increased communication time, and more difficult decision-making.

Defining what’s not the goal at the outset helps focus discussions and achieve the objective. This definition was crafted collaboratively by the entire project team, which I think was a great practice. Addressing even minor differences at a word-by-word level led to smoother alignment.

5. Don’t rush to solve problems

I tend to be impatient. When I hear about a problem, my instinct is to quickly propose a solution: “Let’s do this.”

Whether it’s internal or external feedback on specifications, it’s important not to react hastily. Without thoroughly considering what the problem is and whose problem it is, you risk implementing superficial solutions that may introduce new issues. Sometimes, what appears to be a problem isn’t actually a problem at all.

Rather than solving a problem, I’ve learned that defining it is more critical. Problem definition isn’t about finding the “correct” answer—it’s about exploring, learning from mistakes, and continuing to refine your understanding.

6. Look at the project from just outside your role

This was advice I received from a senior colleague, and it completely changed how I viewed projects and teams. While I’d unconsciously done this to some extent, consciously setting a perspective just outside my role made my observations sharper.

Outside the project leader role, there are product managers (PdMs) and strategic members. Imagining how they view the project and actively thinking from their perspective proved to be incredibly valuable. It changed how I approached my work and improved communication with external stakeholders.

As project leaders often act as coordinators, maintaining this perspective is vital.

Reflection

Writing this down, I feel like I’m stating the obvious. Doing the obvious things consistently can be challenging, especially when you’re in the thick of a project. Or is it just me?

I haven’t perfected these lessons yet, but I believe that trial and error are the only ways to make them my own. It’s mentally exhausting every day, but it’s rewarding to grow alongside the product.

Finally, I want to express my heartfelt gratitude to my team members for their open discussions, feedback, and unwavering support. Thank you.

Bonus: The challenge of finding time to code

Balancing the roles of project leader and developer often means realizing at the end of the day that I haven’t written a single line of code. In my spare time, I prioritize code reviews, which means I can only focus on coding after core hours—but by then, my energy is usually depleted.

To all the playing managers out there—how do you manage?