Reflections on my First Failed Project

(source)

Context

• Our team was tasked to create a GrabFood-like web portal to support new business endeavors
  • Team composition: 2x Backend Engineer, 2x Fullstack Engineer, ~1-2x Fullstack engineers (sister team, periodic assistance)
• I was granted the opportunity to be the Frontend lead for this project
• The project’s requirements were very Frontend-heavy
• Due to a persistent lack of engineering resources and my own professional inexperience, we did not manage to deliver the project on time.

Losses

1. I suffered an abysmal performance rating

   As we were unable to complete enough Frontend-specific features, I bore the responsibility for the failure to deliver on the project, and rightfully so, for:

   A Tech Lead’s core responsibility: To ensure the successful delivery of the team’s technical goals that they have committed to.

2. All my team members (engineers, managers, PMs) took a performance rating hit

   As a direct consequence for the failure to deliver the project on time, all my team members (upstream and downstream), had a negative hit on their performance reviews.

3. I bit off more than I could chew, and paid many personal costs

   Hindsight is 20/20 - It is clear to me now that I had grossly overstretched myself:

   • I was constantly very stressed
   • I fell sick more often
   • I had troubles falling asleep
   • I became less present to my family and friends
   • I had neglected on my self-care routines
   • I became more irritable and less willing to help others

Takeways

1. Deliver within the business cycle ⏱

   As most company processes are synchronized to time periods (eg. Quarterly Business Reviews, Biannual Performance Reviews), it is absolutely critical that projects are delivered within the target business cycle, so that:

   • Business is happy: They get to see their business ideas in action and perhaps even reap big monetary/strategic gains for the company.
   • Managers are happy: They get to show that their team delivered on their commitments to business.
   • Engineers are happy: They get to receive technical credit for making the business idea happen.

   
   So, yes, do your absolute damnedest in your ability to deliver the project on time! 🧨

   Alas, here’s another perspective: If the project fails under your watch, it’s not just you that takes a hit - all your other teammates take a hit too! No pressure. (nervous sweating) 😅

2. Seek qualified advice for your unknown unknowns 💡

   • As Software Engineers, it is far more often that not that we encounter something new.
   • It’s good to run your technical approaches with someone that is more technically capable, especially if it’s an area that you’re not that strong in.
   • If there’s something wrong, take the opportunity to learn and to improve your technical capabilities, for:

     “There shouldn’t be any shame in getting it wrong the first time round.”

   • If there’s nothing wrong, take the opportunity to validate your knowledge against someone else with stronger capabilities.
   • Additionally, you can also take these avenues to build rapport with other engineers within the firm, especially if you’re in a large firm (things are usually impersonal across functional teams.)

3. Know which battles not to fight 🛑

   • As a Lead Engineer for any project, one should perform a risk analysis (eg. “SWOT analysis” for the project. The question that needs answering is:

   “What are the delivery risks that this project faces?”

   • Examples of delivery risks:

     • Insufficient engineering capacity
     • Scope creep
     • Unrealistic timelines
     • Poor technical stewardship
     • Declining team morale
     • See more: PMI: Seven causes of project failure, SourceMaking: Project Management AntiPatterns
   • In normal BAU (ie. Business as usual) circumstances, we discover and proactively mitigate any project risks (eg. managing expectations, providing more technical leadership, acquiring more team members) - We should not quit prematurely; we should overcome difficult situations.
   • However, should the odds be so obviously stacked against the team (eg. unrealistically short timelines), then perhaps it would be wise not to accept the project at all.

   The crux of the matter is this:

   “Do everything in your power to ensure that the odds are stacked in your favour.”

   Note: At all times, do only what is ethical, legal, and honorable. Don’t be evil.

Epilogue

The Baptism by Fire

As we scale new heights and challenges, it is almost a given that there will be a baptism by fire for every major milestone:

• First time leading an Epic: Will I be able to design and execute the technical approach for a subsystem?
• First time being a senior engineer: Will I be able to be a good mentor to my juniors in my team?
• First time leading a team: Will I be able to provide sufficient technical leadership for my team?
• First time handling an entire project: Will I be able to successfully deliver on this project?

No risk, no reward; But high risk != high reward; So, take calculated risks 😅

The Acceptance of the Loss

You won’t always pull it off nicely on the first go, so…

• Accept that things can go sideways, and when they do, you’ll just have to “take an L” and move on 🤕😢
• Sometimes the losses can be pretty hard-hitting, so go easy on yourself, especially if the situation isn’t going easy on you
• Be patient with yourself: Processing through the 5 Stages of Grief can sometimes take longer than expected, depending on the severity of the setback
• Remember to take time off to process and recover - Do the work, but also do the Self-care too!
• Make sure you’ve recovered emotionally - We are humans, not machines. Yes, it applies to both women and men.
• (After you’ve recovered…) Take time to reflect as to how and why things went wrong, and how you can make things better the next time round

The Call to Responsibility

Taking responsibility shouldn’t just be a matter of barter trading it for good performance reviews. Nor should it be merely as a means to strong-arm your way into getting your own way with others.

Instead, I would like to humbly submit to you this proposal:

As a leader, how we can better serve others through our responsibility?

• As a Technical Lead to my team, how can I be more available to my junior teammates to help them with their questions, both big and small?
• As a Senior Engineer, how can I be more available to help other engineers within and outside of my company?
• As a Project Lead, how can I better communicate my team’s technical difficulties to my managers?
• As a fellow Colleague, how can I be attentive and caring to my colleagues, especially those who are in distress?

Appendix: Wins

See more

1. I was able to navigate and provide technical leadership through most of the project’s technical difficulties
   • eg. Proofs-of-Concepts, Cloud architecture, Frontend architecture, Component design
2. I was able to meet most of the technical requirements of external stakeholders
   • eg. OAuth Integration, Analytics, Internal CMS
3. I was able to perform the team project management role
   • eg. Sprint planning, ask estimation, task breakdown

All in all, I’m happy that I was able to fulfill most of the responsibilities of the Frontend lead role - It was most certainly not a walk in the park 😪.

Thank God ✝️ that I made it through, and that I was able to rise to the occasion! 🙏

PS: I think this section didn’t quite fit into the post’s overall core themes; I’m leaving this here in the appendix as, after all, it is good to recognize and celebrate our wins. 😌