Looking Back: A Very Unsuccessful Experience as a Project Lead

Here’s a concise introduction to myself: My name is A Xing. I’m currently a front-end developer with almost two years of experience (graduated in 2022). Right now I’m working at a startup. Encouraged by my class teacher, I made the bold decision to come and share—though what I’m about to share might waste your time, I still hope you’ll hear me out. Today I want to talk about my experience and takeaways from becoming a (very junior) project lead over the past month or so. Let’s jump right into the story of my independent project leadership.

Why did I need to lead a project independently?

At the end of February, I remember it clearly—it was a Monday. The founder said he wanted to treat us to dinner and discuss something. I went to the restaurant with questions, and there he told us he had talked to a really impressive product expert that day. This product expert analyzed our company’s current development status and the problems we were facing. The founder said they had already decided to bring him on to help the company grow better. I was thrilled to hear this—having an experienced person join meant the platform I was on was getting better, and our company had more possibilities. Plus, I really agreed with the product expert’s analysis of our company.

In early March, the product expert joined. As is tradition, the founder took us out for a meal. During the meal, the product expert analyzed the company’s situation and came to two conclusions:

1. All work relied on the founder’s assignments; employees had no sense of ownership. There was also a lack of goal orientation.
2. The overall state was like “a frog being slowly boiled”—not bad, not good either. That’s not how a startup should be.

Based on the product expert’s analysis, we introduced the “Lead System.” Projects became units, each with a lead (also called a “team leader”). The lead’s job was to take over the work previously done by the founder. Before, the founder would come up with requirements, refine them, then schedule them, allocate resources, develop, and launch. Now, the lead would plan the work, request resources from the founder, schedule it, develop, and launch—just with a simple report back to the founder. It sounded like the lead’s role wasn’t that hard, but when it came down to actually doing it, it was a mess. Still, the product expert and founder said they wouldn’t throw us into the deep end right away; they’d guide us, letting us slowly take on responsibility, and we could ask them questions anytime. As someone fresh and fearless, I volunteered and said I wanted to try this lead system.

What did I do?

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

Communicate with colleagues and push work forward: After the meeting, I’d notify the relevant people about what they needed to do that week. For example, I’d tell the backend: “I need you to do this, and I need it by roughly this time. Please prioritize accordingly.”

Develop, launch, and update the founder: Then came my daily work—front-end development. During this period:

1. I worked with the backend to set up a simple data dashboard. Based on the dashboard data, I optimized the project, checked the impact of changes after launch, and fed that back to colleagues and the founder.
2. I did deep competitive analysis and worked with the product expert to optimize our product from multiple dimensions (user flow, payment flow, etc.) to improve user experience.
3. Every Friday, I’d give a brief report to the founder on what was completed and what wasn’t.

Keep track of overall progress and flag risks in time: I also occasionally played the role of the least favorite taskmaster—checking that PRs were reviewed, pushing for timely handling, doing acceptance testing after completion. If I realized a requirement couldn’t be finished on time, I’d escalate to my superiors and look for solutions.

Maintain communities, documentation, daily syncs of dashboard data, and data analysis: During this time, I started managing communities—posting product update announcements, collecting user feedback, etc. Every day I’d sync yesterday’s dashboard data with colleagues in the group, analyze the data, and potentially add new requirements to the backlog.

The above are the good parts. Now let’s talk about the not-so-good.

Inaccurate time estimates led to delays: Based on my experience and discussions with colleagues, the launch dates we agreed on always felt rushed, sometimes even delayed.

Difficulty prioritizing requirements correctly: I felt I still didn’t fully understand the product—I’d sometimes work on less urgent tasks while higher-priority work was waiting.

What did I learn?

By the end of February, I was just a front-end cog—writing code, minimizing bugs, and making sure requirements shipped on time. In the blink of an eye, I had to become a project lead. Used to being assigned work, my brain felt rusty—I had no idea what to do, how to plan, or what to base the plan on. But I had Product Bro 😎, so I went to him. He didn’t tell me exactly what to do or say, “Let me handle this.” Instead, he said, “Find answers in the data, analyze competitors.” Then he taught me how to do simple data analysis to improve the existing product’s user experience. I learned a lot from working with him.

Handle emotions before handling work: During that period, I kept introducing bugs in my requirements. That’s because I had multiple projects going on—messy, too many things to do every day. I was always in a state of “the deadline is coming, I need to hurry.” Code written under that kind of tension had many problems. Later, I saw a recommendation in the group for “Getting Things Done: The Art of Stress-Free Productivity”. I learned to deal with my emotions first. Now, when my focus is scattered or my mood is off, I do something else first—fill up water, drink, chat with colleagues—to decompress.

Clear your mind, focus on the present work: This is another technique from that GTD book. I practice it every day. For example, during work, if a user suddenly reports a problem in the WeCom community group, I check if the requirement can be done in 5 minutes. If yes, I handle it immediately. If not, I log it (using a 365 to-do list) and wait until the main task is done to handle it all together. I plan to keep applying the Pomodoro Technique to improve my focus.

Communicate promptly, don’t let problems become big problems: I’m an introvert. When encountering problems, especially ones I caused, I used to be afraid to report them—afraid of getting criticized. But not anymore. I now approach with a problem-solving 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 means optimizing the product through data analysis. Every requirement I work on now is backed by data.

Agile development: Before, I’d start coding as soon as I got the requirement and figure out the implementation during development. Now, I immediately think: “Is there any technical difficulty in this requirement? Who do I need to cooperate with? How long will it roughly take? Can this requirement be broken down into smaller pieces?” During development, I create a separate branch for each requirement, enabling quick development, quick deployment, and accurate analysis of the change’s impact.

Follow the rules: In development, I must strictly follow agreed-upon rules. For example, code review before launch, multi-person acceptance testing, and re-testing after launch. These rules should be followed in daily work, even when handling urgent bugs.

Think independently, summarize and reflect on my behavior: During this lead period, which coincided with the last training camp, I would record my daily shortcomings and how to improve. I came to some insights I consider quite valuable. For example: Happiness is a skill—you need to have eyes that can spot it.

Some personal reflections

During this time leading a project independently, I was both criticized and praised. It was really tiring, but I’m still grateful for having such a platform to try it out. It was truly painful but also joyful. I feel I’ve transitioned from a passive receiver to an active driver—both in life and at work, I try to put myself in the driver’s seat as much as possible. Even now, I’m still not entirely comfortable proactively pushing things forward.

In the early days of being a lead, I’d think about work even while walking or taking a shower. But I want to say: that’s not healthy. Work-life balance is important. Now I try to be highly efficient during work hours so I can leave on time, then come home and study Brother Yu’s “Next.js Mini-Book.”

When you’re under a lot of pressure, talk to people more and go out for walks.

Why was I a failing lead?

During this period, even though I was thinking, my lack of understanding and experience led to a bad outcome in the end.