Failure To Launch

Last month, one of my mentees asked me a difficult question:

How do you continue working when all of your projects keep getting killed?

Outside of what I’m currently working on, I’ve made meaningful contributions to 8 different projects over the past decade. Only 2 of them still exist in any shape or form. And by exist, I mean that they have been fossilized as open source projects that someone may stumble upon and use one day.

Why Projects Fail

Product development is hard. A single engineer’s output is a tiny piece of the product success puzzle. The historical reason I’ve seen for projects being cancelled is leadership deciding that resources are better spent elsewhere. This comes in a few different flavors. Some projects get replaced by bigger and better tools from vendors or competing teams within a company. This can be disappointing but indicates that the core problem you were working on was valuable. Other products get released but fail to gain enough traction (or money) from customers to survive. Again, having your hard work get scrapped is demoralizing but there are plenty of learning opportunities for what aspects did or did not resonate with customers. The worst experience is when leadership loses faith midway through development. The engineering team feels like they’re close to a breakthrough and the rug suddenly pulled from under them. The last reason I’ve seen is when a project is determined to be technically infeasible^*. I put an asterisk because assuming you’re not violating any laws of physics, most engineering roadblocks I’ve seen can be resolved with enough time and effort. Granted, if you’re doing something novel, that “time and effort” becomes unbounded, which leads to a vote of no confidence from leadership.

What Can An Engineer Do About It?

Though some factors are outside of our control, we have agency in our careers. Each team or organization you join will have inherent tradeoffs.

Working on brand new problems in an experimental product organizations is appealing. With a greenfield codebase unburdened by technical debt, you have seemingly endless degrees of freedom to shape the system. At such a nascent state, you may have to, or get to, participate in non-traditional engineering tasks. You might pitch in to conduct user studies, write proposals for which customer segments to target, or define a pricing model. This is valuable experience to diversify yourself as a an engineer, but it comes with risks. Until you have active (production) customers, your project will be a potential target for leaders to discard or drastically pivot the core product you’re working on. Especially early in your career, these decisions are above your pay grade and you wind up feeling lost at sea.

Joining a team with an established product may not seem as fun outside looking in. Some projects get relegated to “keep the lights on mode” where you’re just making sure dependencies stay up-to-date and the application doesn’t crash. But building new features into existing applications with live customer traffic can present really fun technical challenges. If you’re working on a greenfield system and you want to change databases, you can tear everything down at will. When you have to factor in live customer traffic, you have to ensure no downtime or data loss. You also see first hand the impacts of tech debt on long-term maintainability of software.

Some Recommendations

It’s good to get exposure to different facets of software engineering early in your career. This may require changing teams or moving to a new organization. “Job-hopping” can become a reputational red flag if done too frequently, but if you feel your skills stagnating, it’s probably time to move on.

When working on a project, try to create durable artifacts that transcend the scope of whatever you’re working on. This could be in the form of a custom linter to enforce your preferred coding rules, a design document template, or a lessons learned presentation that could benefit the broader organization.