Lessons from Projects That Didn’t See the Light of Day
How can engineering help prevent some of these failures
Hey, it’s Irina! 👋 Welcome to another edition of The Caring Techie Newsletter. Today you’ll learn practical strategies for preventing projects from failing, based on hard-earned lessons in Big Tech at companies like Google and Uber. Enjoy!
Read time: 8 minutes
Throughout my software engineering career, I’ve poured my heart into not one but multiple projects that ended up being scrapped. It was demoralizing knowing that all the late nights, effort, and creativity didn’t lead to anything.
Why did these projects fail? The reasons varied, but there was one common thread: a “build first, figure it out later” mindset. This reactive approach led to preventable mistakes in most of these cases.
In this article, I’m sharing what I’ve learned from these experiences. The inspiration came from a LinkedIn post I wrote a few weeks ago, which received positive feedback and sparked interesting discussions, so I decided to share more on the topic.
Failures are often a shared responsibility, and reflecting on them is rarely enjoyable. Rather than assigning blame to other functions when projects fall short or get shut down, I asked myself:
Beyond execution, what role does engineering play in preventing these failures?
In my experience, engineering, especially senior ICs, can take a proactive role in avoiding these outcomes. By keeping a broader perspective, we can help guide projects in the right direction and prevent failures before they happen.
Why this matters to your employer
On one hand, you want an engineering culture that embraces experimentation and learning from mistakes. This keeps your business nimble and allows you to move quickly, which is crucial in competitive industries.
On the other hand, you need to consider the cost of investing design, product, engineering, and other resources into projects that ultimately get scrapped. If the project was an intentional bet, an MVP, or an experiment that provided valuable insights, you can justify the expense as part of the learning process.
However, if the goal was to launch a fully developed feature or product and you end up discarding everything after it’s built, you’ve just wasted months of design, product, and engineering effort that could have been used elsewhere. On top of that, scrapping fully developed projects can also lead to low morale. It’s hard to stay motivated you feel like all your hard was for nothing. This kind of waste should be avoided at all costs.
Why this matters to you personally
Getting involved early in the lifecycle of a project not only helps the company but also helps you as an engineer.
Also, keep in mind that wasting time on projects where you cannot show impact isn’t beneficial for your career. No matter how hard you work on it, it will be very difficult to get rewarded for it when it comes to promotions. Simply put, it’s a setback that directly impacts your career progression.
Caring about the company’s success may or may not be your priority, but caring about your own career should absolutely be your priority because if you don’t care, no one else will.
What can you do to make a difference
When you’re first introduced to a project, here’s a list of actions and questions you can use to ensure it's set up for success. Think of it as doing your due diligence.
1/ Mentally remove the invisible role barriers
Don’t limit yourself to only your job description. While your primary focus might be engineering, think beyond that—ask questions about the product, business goals, and timelines.
Don’t let the formality of the roles get in the way of you sharing your perspectives and input. Just because your manager or product manager assigned you some work, it doesn’t mean you should just blindly execute. This is a behavior I see often with engineers, and it holds them back.
Good product managers want to be challenged. And if you don’t believe me, check out what some of the senior product leaders think of this:
The success of projects is everyone’s job, and your career progression might be at stake, so focus on co-creating with your cross-functional partners.
Engineering, product, design, data science are ultimately one team with the same overarching goals. Remember this any time you want to say “that’s not my job”, or “I’m just doing what my manager/product manager told me to do”.
2/ Fully read the Product Requirement Document (PRD)
Some efforts will be led by Engineering, and some by Product. If a project is Product-led, there probably is a PRD for it. If there is no PRD, feel empowered to ask for one (or at least a mini version of one).
Consider it part of your job to read the whole document carefully. Treat it as more than just a to-do list, and aim to understand the project's vision, goals, and how it fits into the bigger picture.
Aim to spot potential pitfalls early and suggest changes that might save time and resources. To learn more about what are the potential pitfalls, keep reading.
3/ Make sure you understand the “why” behind the “what”
Why are we building this? What problem does it solve? Who benefits from it?
If you don’t know the answers to these questions but have already started coding, pause and get the answers first. It may sound surprising, but in many organizations—especially less mature ones—projects can move forward with a fuzzy “why.”
These questions are critical. If you can’t identify a clear “why,” that’s a major red flag and an early warning sign that the project could be headed for failure.
It’s like constructing a bridge without knowing what it’s supposed to connect—you might complete the structure, but it could lead to nowhere, serving no real purpose.
4/ Make sure decisions are either backed by data or calculated bets
A decision is data-driven if it relies on pre-existing data such as metrics, user research, or historical learnings to help de-risk the project from the outset.
Conversely, a decision is a bet, if it t relies on intuition, assumptions, or incomplete information, taking on more uncertainty and risk without substantial data to support the outcome. Bets should be calculated risks.
When considering a project, be careful about:
Overly optimistic bets - when risks are not properly weighed, and the chances of success are exaggerated.
Inaccurate data - drawing conclusions from misleading or insignificant data can lead to bad decisions; beware of biases that can distort insights.
If you notice these issues in PRDs or project descriptions, don't hesitate to flag them.
You are reading a free article of The Caring Techie Newsletter. I post weekly-ish articles on career growth, leadership and communication for high performing ICs and leaders.
If you’re learning new things and wanting for me to continue putting these articles out, please consider becoming a paying subscriber. See the benefits here.
5/ Ask questions often
Many engineers I've met hesitate to ask questions because they worry about how they'll be perceived, don’t want to appear uninformed or fear it might come off as challenging authority.
In a healthy engineering culture, asking questions is encouraged—especially when starting new projects. Questions spark productive discussions, help clarify the vision, and uncover trade-offs that can prevent surprises later on.
As a tech lead, there have been countless times when I asked questions that weren’t just unclear to me. I addressed the elephant in the room, and others were grateful because they were wondering the same thing.
It's important to remember that you won’t always have all the answers upfront—and that’s perfectly fine. Asking questions should be a habit at every stage of the project.
6/ Push back on unrealistic timelines or unfeasible work
Projects often fail when timelines are rushed or corners are cut in the name of speed. This can lead to poor execution, technical debt, and a higher likelihood of failure. Even if the timelines are set in the PRD, don’t hesitate to raise concerns if they seem unrealistic or if the scope of work feels unfeasible within the given timeframe.
Similar to asking questions, push back is something I did often as a Tech Lead and it always paid off. It’s important to recognize the difference between aggressive timelines, which may be challenging but doable, and impossible ones that set the team up for failure.
So speak up early and openly—it’s much easier to adjust expectations or timelines at the beginning than to fix problems caused by rushing later on. Your concerns may prompt critical discussions about trade-offs, priorities, and resources, ultimately setting the project on a better path to success.
7/ Encourage and incorporate de-risking strategies
In case the PRD doesn’t already include these things, feel free to suggest:
Using minimum viable products (MVPs) or prototypes to test assumptions and gather feedback before investing significant resources.
Conducting thorough technical feasibility assessments to identify potential risks and challenges early in the process.
Smaller, iterative releases where possible to get early feedback and allow course corrections
Develop risk mitigation plans to address potential issues proactively. This can include contingency planning, backup strategies, and contingency budgets.
Are you enjoying this article? Hit the ❤️ button or share it with a friend or coworker. 🙏🏻
Conclusion
At the end of the day, the goal is to create projects that matter and make an impact. While not every project will succeed, staying engaged, asking questions, and understanding the deeper purpose behind your work can make all the difference. That mindset will always set you and your team on a stronger path, no matter the outcome.
All of the advice shared in this article are things I had to learn the hard way, by being in the trenches for more than a decade of hands-on engineering.
I would love to hear from you. Have you worked on projects that didn’t see the light of day? What tips do you have for preventing failures?
Until next time,
Do you want to grow your career? Here are 3 ways I can help:
1-1 coaching - I have 2 coaching spots left for the rest of the year, email me at thecaringtechie@gmail.com or DM me to learn more!
Book a one-hour call where we can tackle your most pressing issues.
Teaching private cohorts of “Impact through Influence”, if you’re a manager or leader interested in this for your teams, reach out!
Related reading:
cant agree more.
Nice job, Irina! Thanks for sharing it.