How did you bounce back after having to scrap an entire project?

Hi Monet - there is so much to be learned from "scrapping" a project. In fact, I've gained more from my failed projects than from my successful projects. "Failure" is a scary word, but one that should be embraced. If you avoid failures, you never take risks and block yourself from big successes as well. Yet, in the moment, it can be disappointing to realize your work may not become a reality. I base these decisions on what's best for my customer - if a product isn't the best it can be, if there's a better solution in sight, if there are known failures, it's time to move on and find a better way to address the problem we're trying to solve.

When you make a decision to move on, the most important thing to do is to take stock of what you've learned and what you would do different next time. Celebrate these learnings and these takeaways - even though you've said goodbye to some great work, you've also grown as an engineer and will be that much better next time around.

My biggest failure was my first PhD dissertation topic, on which I spent three years before having to abandon it for a different project. (It was a fairly aggressive project--a new kind of hydrodynamic code for astrophysical scenarios--and it simply didn't perform as stably as I needed. It would have required at least another year of development to become stable enough; there was no guarantee even that would suffice; and even if it did, the actual research would require significant additional time above and beyond the software development.)

That was painful, of course, but I discussed the risks and uncertainties of continuing it with my advisor, and while he wasn't happy about abandoning it (the particular approach had been his suggestion in the first place), he ultimately agreed that the risks of continuing were too high.

"Bouncing back" was difficult primarily because I was quite tired at that point, almost burned out. But I was also stubborn, particularly about terminating six or seven years of effort with nothing but a masters' degree to show for it, so I "pivoted" and found an interesting related problem to work on instead. Nor had the previous three years been entirely wasted; in addition to working on the failed code, I'd also learned a great deal about my chosen field in that time. So the second project was something I could get started on immediately, with very little ramp-up. Even then, it took twice as long to complete as I expected (almost another three years rather than the 18 months I'd estimated), but in the end it was the right decision; I succeeded.

So a lot of it comes down to believing in yourself and not treating the failure of any given project as a personal failure. Failures are learning experiences, and perhaps the most valuable lesson of all is to be able to recognize fairly quickly when a particular approach is not working and another one should be tried. Doing that early enough might actually save a project, because the investment to date hasn't been excessive. Talking to other, more senior people about the project and getting their feedback is one way to make the call. Asking in forums like this is another. But ultimately the best teacher is experience: try lots of things. Expect to fail on some of them. Learn from those, do better the next time, make different mistakes. Rinse, repeat. :-) (You'll find that's a common thread voiced by a lot of serial entrepreneurs, too--keep trying, keep trying, keep trying.) It gets easier every time.