The Calculus of Letting Failing Projects Fail: A CTO's Honest Take

General
1

The hardest thing I have learned in 25 years of building software is not how to identify which projects are going to fail. That part, frankly, gets easier with experience. The hard part is deciding what to do when you see it coming.

I want to be direct about something that has been circulating in engineering circles lately: the idea that senior engineers sometimes deliberately let bad projects fail, and that this can be the right call. I have mixed feelings about this framing, but I think it is worth engaging honestly rather than reflexively dismissing it.

A story I am not proud of

Early in my role at a previous company, I could see that a major infrastructure rewrite was going to be a disaster. The scope was wrong, the team was wrong, the timeline was fantasy. I said so in the initial design review. I was told the decision had already been made at the board level. I raised it again in a 1:1 with my CEO. He thanked me for my perspective and moved on.

After those two attempts, I made a choice: I stopped actively fighting it. I documented my concerns in email. I kept my team insulated from the worst of it. And I watched the project collapse over 18 months, exactly as I had predicted.

Was that strategic patience? Or was it abdication? I have asked myself this question many times.

The framework I use now

After a lot of reflection, I have developed three signals that I use to determine whether staying silent is acceptable or whether I need to keep fighting regardless of political cost:

Signal 1: Customer harm potential. If real customers are going to be harmed - financially, in terms of their data, their safety, their ability to do their jobs - that is a line I do not stay silent on. I will escalate to the board if I have to. I will put it in writing. I will be annoying about it. This is non-negotiable.

Signal 2: Junior engineer career risk. When I see talented engineers whose careers might be damaged by association with a doomed project, I try to intervene - not necessarily to save the project, but to protect those individuals. This might mean advocating for them to be assigned elsewhere, or making sure their contributions are clearly documented separate from the project outcome.

Signal 3: Pure organizational sunk cost. This is the gray zone where the “let it fail” argument has its most validity. When the downside is wasted money and management embarrassment, and when the team working on it actually might learn something important from the experience, there is a real argument for stepping back. Not because you are indifferent to the waste, but because sometimes organizations have to learn lessons the expensive way.

The honest part

I want to acknowledge something uncomfortable: this framework is easier to apply when you have job security, reputation, and a safety net. The calculus looks very different for engineers who cannot afford to be wrong about when to spend political capital. I have been in a position of relative security for much of my career, and I should not pretend that framework works the same way for everyone.

I also want to be clear that “documenting concerns” is not the same as actually doing something about them. Documentation is necessary but not sufficient. There is a real risk of using “I raised it in writing” as a form of moral laundering - making yourself feel better about staying silent by creating a paper trail.

The question I am sitting with

Where do you draw the line between strategic restraint and complicity? I have been on both sides of this decision and I do not think there is a clean answer. But I do think the engineering community benefits from having this conversation explicitly rather than leaving it as an unspoken norm that gets passed down informally.

What signals do you use? And have you ever gotten the calculus wrong in either direction?

2

Michelle, I appreciate the honesty here, but I need to push back on Signal 3 in particular - the “pure organizational sunk cost” gray zone.

I have spent 18 years in financial services engineering. What you are calling “pure organizational sunk cost” rarely stays pure. The wasted money has real downstream effects: teams that could have been building better compliance tooling, reliability improvements that got delayed, engineers who burned out chasing a deadline that was always impossible.

More importantly, in regulated industries the consequences of letting things fail are not just organizational embarrassment. They are regulatory penalties, customer trust violations, and sometimes - if the failure touches payment rails or data systems - real financial harm to real people. The framework breaks down in environments where there is no such thing as “isolated” failure.

I do agree completely on Signals 1 and 2. Customer harm and junior engineer career risk are absolute lines. But I would argue that in many organizations, what looks like a “sunk cost” failure from the senior level looks very different from inside the team.

The distinction I use is this: voice concern once, document it clearly, escalate to the right level - then accept the decision and execute as well as you can. That is different from strategic silence. You have done your job. The decision is now owned by whoever overrode you. But you should not rationalize silence as wisdom if you never actually spoke.

What you describe in your story sounds to me like you did this right - you raised it twice, documented, then stepped back. That is different from someone who saw the disaster coming and said nothing because they were protecting political capital for something else.

3

Michelle, I appreciate the honesty here, but I need to push back on Signal 3 in particular - the pure organizational sunk cost gray zone.

I have spent 18 years in financial services engineering. What you are calling pure organizational sunk cost rarely stays pure. The wasted money has real downstream effects: teams that could have been building better compliance tooling, reliability improvements that got delayed, engineers who burned out chasing a deadline that was always impossible.

More importantly, in regulated industries the consequences of letting things fail are not just organizational embarrassment. They are regulatory penalties, customer trust violations, and sometimes real financial harm to real people. The framework breaks down in environments where there is no such thing as isolated failure.

I do agree completely on Signals 1 and 2. Customer harm and junior engineer career risk are absolute lines. But I would argue that in many organizations, what looks like a sunk cost failure from the senior level looks very different from inside the team.

The distinction I use: voice concern once, document it clearly, escalate to the right level - then accept the decision and execute as well as you can. That is different from strategic silence. You have done your job. The decision is now owned by whoever overrode you. But you should not rationalize silence as wisdom if you never actually spoke.

What you describe sounds like you did this right - you raised it twice, documented, then stepped back. That is categorically different from someone who saw the disaster coming and said nothing to protect political capital for future battles.

4

This thread is hitting me in a complicated place, so I am going to share something personal.

I co-founded a B2B SaaS startup a few years back. We had a senior advisor - brilliant engineer, decades of experience - who we brought in early. Six months into our build, he could see that our core product assumption was wrong. The problem we thought we were solving was not actually the problem customers had. He told us what we wanted to hear in meetings. Later, I found out from a mutual contact that he had been saying privately for months that we were building the wrong thing.

When we shut down, I lost two years of my life and most of my savings. Three junior engineers who had taken equity packages instead of full market salaries lost real money. Our advisor moved on to the next advisory role.

Now I want to be fair: we were the founders. We made the decisions. He was not obligated to save us. But there is a question of what a senior person with relevant expertise owes to the people around them when they can see something the others cannot.

I do not think he was being strategically patient. I think he was conflict-averse and rationalized it as respecting our autonomy. The effect was the same either way.

Michelle’s framework helps me articulate what bothered me about it: the junior engineer career risk signal. We were technically co-founders, but we were also very much junior to him in experience. Someone should have told us directly, not in the polite meeting language that we could dismiss as normal advisor hedging.

The question I keep coming back to: what is the ethical obligation of someone who can clearly see what others cannot?

5

Great framework Michelle, and I think the three signals are useful starting points. But I want to probe on what triggers Signal 1 specifically - the customer harm threshold.

In practice, I find the hardest cases are not the ones where harm is obvious. They are the ones where harm is possible but uncertain, probabilistic, or deferred. A project with weak security posture might not cause harm if we get lucky. An architecture decision that creates scaling bottlenecks might not become a customer problem for 18 months.

Do you have a way of thinking about the harm threshold when the connection between the project decision and potential customer impact is indirect or delayed? Because in my experience, those are exactly the cases where the strategic patience argument is most tempting - and potentially most dangerous.

Also: your point about documentation as moral laundering is really sharp and I want to sit with it. I think there is a version of escalation that is genuine advocacy and a version that is CYA. What distinguishes them in your experience?

6

Michelle, thank you for writing this so honestly. I want to affirm the framework and add a dimension I think is missing from the conversation: the privilege embedded in the ability to apply it.

The three signals assume you have enough standing and security to make an informed judgment about when to spend political capital. That calculus is very different depending on your position in the organization.

As VP Engineering now, I have enough organizational standing that staying silent on a bad project is genuinely a strategic choice. I can absorb the consequences of being wrong either way. I have built enough trust that a single failed intervention does not define my relationship with leadership.

When I was an engineer earlier in my career - especially in the years before I had a strong track record - the same calculation was not available to me. If I raised concerns about a project that leadership had emotional investment in, the risk was not just wasted political capital. It was being labeled as a troublemaker, being taken off good projects, having my performance reviews influenced by someone who felt challenged.

The engineering community talks a lot about seniority as if it is purely about technical capability. But the ability to strategically manage when and how you advocate for things is itself a form of senior leverage that junior engineers do not have.

So when we talk about senior engineers letting things fail, we should be clear: we are describing a behavior that is only available to people with a certain level of job security and organizational standing. And those are not evenly distributed.