Reflections on My First Time as a Project Lead

Let me briefly introduce myself. My name is Axing, I’m currently a frontend developer with nearly two years of experience (graduated in 2022), working at Fish Factory (programmer Yú Pí’s company). Today I want to share my experience and takeaways from becoming a (most junior) project lead over the past month or so. Let’s dive right in.

Why did I need to independently lead a project?

At the end of February, I remember it clearly — it was a Monday evening. The boss said he was treating us to dinner and had something to tell us. I went to the restaurant with curiosity, and then the boss told us that earlier that day he had chatted with a very sharp product expert (let’s call him Product Bro). Product Bro analyzed our company’s current situation and the problems we were facing. The boss said they had confirmed Product Bro would join our team to help the company grow better. I was very happy to hear that — having an experienced person join meant a better platform for me and more possibilities for the company. I also strongly agreed with Product Bro’s analysis and summary of our company. In early March, Product Bro arrived. The boss treated the new employee to a meal, and at the table Product Bro analyzed the company’s current state and drew two conclusions: 🌈💎🌈

1. All work in the company still relies on the boss’s assignments. Employees lack a sense of ownership, and no one can clearly define their own work goals.
2. The overall status quo is like “a frog in slowly boiling water” — not good, not bad, not how a startup should be.

After Product Bro’s analysis, we introduced a “lead system”: each project would have a designated lead (also called a “team leader”). The lead’s job was to gradually take over some of the tasks the boss used to handle. Previously, the boss planned requirements, refined them, arranged schedules, allocated resources, and then we developed and went live. Now, the lead plans the work, fights for resources from the boss, schedules tasks, develops, and goes live — just reporting progress to the boss. It sounds simple, but actually doing it was chaotic at first. However, Product Bro and the boss said they wouldn’t let us go totally independent immediately; they would guide us, help us gradually take responsibility, and we could ask them for advice anytime. Being a fearless newbie, I volunteered and said I wanted to try out this lead system.

What did I do?

Make plans, hold sync meetings: Every Monday, I’d plan the week, break down requirements into the smallest possible tasks, schedule them, document everything, hold a meeting to confirm what needs to be done, and align with the boss on required time and headcount.

Communicate with teammates, push work forward: After the meeting, I’d notify the relevant people about what they needed to do that week. For example, tell the backend engineer what I need from him and roughly when I need it, letting him prioritize accordingly.

Develop, ship, and sync with the boss: Then I’d go back to my daily work — frontend development.

1. The backend and I built a simple data dashboard using the company’s existing resources. Based on the dashboard data, we optimized the project. After launch, we quickly checked the data impact and provided feedback to teammates and the boss.
2. I did deep competitor analysis, and together with Product Bro, we analyzed and optimized our product from multiple dimensions (user journey, recharge flow, etc.) to improve user experience.
3. Every Friday, I made a brief report to the boss summarizing what was completed and what wasn’t.

Keep overall progress in check, flag risks promptly: I also occasionally became a dreaded overseer — for example, if a PR hadn’t been reviewed, I’d push for it; after finishing a requirement, I’d make sure to verify and test it. If I found a requirement couldn’t be completed on time, I’d immediately escalate and seek solutions. Maintained the community, documentation, daily sync of dashboard data, and data analysis: during this period, I started maintaining the community, posting product update announcements, collecting user feedback, etc. Every day I’d share the previous day’s dashboard data with the team in the work group, analyze it, note potential new requirements, and log them into the requirement pool.

Those are the good parts. Now for the bad.

Inaccurate time estimation, delayed requirements: Based on my experience and communication with teammates, the deadlines we agreed on always ended up tight, sometimes even delayed.

Couldn’t accurately prioritize requirements: I felt I still lacked a deep understanding of the product, sometimes working on less urgent tasks while higher priority work was waiting. The project I was responsible for is Laoyu Resume. If you need a resume builder, feel free to try it out: https://www.laoyujianli.com/. If anything doesn’t satisfy you, please let me know anytime — I’ll log it and work on improving it.

What did I learn?

At the end of February, I was just a frontend cog — writing requirements, minimizing bugs, ensuring deadlines weren’t missed. Now I had to be a project lead. My brain, used to being assigned tasks, felt like rust — totally lost, didn’t know how to plan. Luckily, I had Product Bro 😎! Whenever I hit a problem, I’d go ask him. He didn’t tell me exactly what to do or say “let me handle it.” Instead he said: find answers in data, analyze competitors. He taught me how to do simple data analysis to improve user experience of existing products. During this time with him, I learned a lot, and I truly trust him — now I consult him on almost everything I’m unsure about.

Handle emotions first, then work: During that period, my work was full of bugs — because I felt there were multiple projects and chaos, too many things to do each day, always in a “deadline is about to slip, I need to hurry” state. Code written under such tension had many issues. Later, I came across the book Getting Things Done: The Art of Stress-Free Productivity recommended in the group chat, and I learned to deal with emotions first. Now, when I feel unfocused or emotionally unstable, I do something else first — like get water, drink, chat with colleagues, etc. — to decompress.

Empty your mind, focus on the current task: This is another technique from GTD. I’m practicing it daily. For example, if a user reports an issue in WeCom group during work, I’ll check if it can be solved in 5 minutes. If yes, I’ll do it right away; if not, I’ll log it (365 Todo list) and handle it after finishing the main task. I plan to continue practicing the Pomodoro Technique to improve focus.

Communicate promptly, don’t let problems become big problems: I’m an introvert. When I had problems — especially ones I caused — I used to be afraid to escalate, afraid of being criticized. But now I don’t. I approach problems with a solution mindset, even if it’s bad news, I grit my teeth and report it, discuss solutions with the team, because not reporting only makes the problem bigger.

Data-driven business: That is, optimize the product by analyzing data. Every requirement we make is backed by data now.

Agile development: Previously, I’d start coding as soon as I got a requirement, figuring out implementation along the way. Now, as soon as I see a requirement, I instantly think: is there any technical difficulty? Who do I need to collaborate with? How much time is needed? Should we do it? Can we use existing tools? If we do it, I’ll break it down into smaller tasks. Also, during development, I create a separate branch for each requirement, enabling fast development, fast deployment, and precise analysis of the impact.

Follow principles: In development, it’s crucial to stick to agreed-upon principles — e.g., code review before launch, multi-person verification, and retesting after launch. These should be followed in daily work, even when handling urgent bugs.

Think independently, reflect and summarize my behavior: During this project lead period, I’ve been recording my shortcomings every day, and how to improve. Through daily reflection, I’ve really changed a lot.

Some reflections

During this time of independently leading a project, I’ve been criticized and praised. It’s been really tiring, but I’m still grateful for such a platform to try things out — it’s truly painful and joyful. I feel I’ve transformed from a passive receiver to an active one. Now, whether in life or work, I try to put myself in the driver’s seat. Even though I’m still not fully used to proactively pushing things forward, in the early days of being a lead, I’d think about work even while walking or showering. But let me say this: that’s unhealthy. Life-work balance is important. Now I try to stay highly efficient at work, leave on time, and then spend the evening learning new things — for example, Yayus’s “Next.js Guide” and Shen Guang’s “Nest.js Guide”. I hope to keep learning and keep improving.

Hope this article brings you some value!