Why Senior Engineers Let Bad Projects Fail
88 points by lalitm
88 points by lalitm
"Let bad projects fail" implies an amount of control that doesn't always exist.
In a lot of companies, the engineer's role is to work on the project that the management and product owners already decided on.
This comment surprises me. The post is clearly specifically about why senior engineers *let * projects fail; why they see a project they think is doomed, but choose to not do anything about it. It goes into the reasoning behind when to speak up about a problem and when not to. It specifically mentions things like the political capital cost associated with killing or changing a manager or VP's pet project.
My point is that in many companies, an engineer trying to get a project cancelled or make it change course is a pointless excercise in wasting political capital.
To you it may seem they're "choosing not do anything", but the senior engineers in question may realize that it's out of their control and will only hurt their reputation with managment - especially if they're not on the project.
It's nice that there are companies who trust engineers enough to listen to their input on projects, but IME most companies don't work that way. I'm not even sure that it's a bad thing.
What you wrote there is exactly what I took away from the post... in the part about the bank account analogy, the author wrote exactly that getting a project cancelled requires expending so much influence capital that you get to do it once every few years if ever, didn't they?
Decent post, but it neglects to acknowledge that really bad projects sometimes succeed because of sheer force of will/throwing enough money at it. Especially if it's a VP's pet project. And also, sometimes, you're just wrong.
In a dysfunctional environment, the fact that 'success' is subjective also matters. Did it ship? Yes, success! But maybe it cost more to develop than the revenue it brought in and it cost us customers for another product because they don't trust our quality anymore. Those things aren't measured.
And individual success may not be tied to project success. If you lie to management about progress and look like your project is doing really well, then you maybe able to use this to move to another more important project. And then your old project fails, but only after someone else took over running it. I'm great, the project was doing really well when I was running it, it only failed because of this other person!
Did it ship? Yes, success!
and two months later most of the team is laid off because of that pivot.
yes, I was on that project. i lived that. I didn't get laid off and had to deal with the morale of being left with an abandoned project. I found a new job. I'd have preferred the severance package that others received.
My prime example for subjective success: https://doi.org/10.1016/S0164-1212(99)00094-1
A case study about the development of a medical instrument. The project had a total cost overrun of 419% of the approved budget. It took nearly twice as long as the approved plan. However, the developers considered it a huge success: "The common theme on all the responses included (a) the project was a technical challenge, (b) the product worked the way it was intended to work, and (c) the team was small and high performing."
There are so many high-impact things we could use technology for.
Very, very many of them are so high-impact that a project taking 2x as long as planned and costing 5x as much as planned is still a huge win if the result actually solves a problem.
Planning and cost overrun can also be a complex issue in no way indicative of failure depending on the approval and funding models. Oversight can often be both expensive and tight-fisted, so projects have to lie in order to get their foot in the door, following which continuance is expected.
And even when they don’t lie outright, any sort of project with significant unknowns will tend to not put too much weight on them for the reasons above, unless they’re talking to investors who are specifically looking for / interested in funding those.
it neglects to acknowledge that really bad projects sometimes succeed because of sheer force of will/throwing enough money at it.
Certainly, this can and does happen, but in my experience, it's the exception, not the rule. Also, if it required so many resources, can it really be called a success in terms of ROI for the company? Success is also highly subjective (i.e. in the eye of the beholder) until potentially years after first shipping. It's only at that point that people start to gain perspective and analyze it through a more "historical" lens.
And also, sometimes, you're just wrong.
I do call this out explicitly in the post: "You must also internalize the fact that just because you say something does not make it the truth" and "Sometimes you’re wrong and the project actually works." It's very important to remain self-aware that you're a human being who can make judgment mistakes, just like everyone else.
Even if the senior engineer intervention would be successful, like "oh, you are right, let's abandon this immediately", nobody will give you a bonus for that even if you saved millions of dollars.
But you can save you and your team some bad times and heavy pressure of trying to comply with a project that doesn't make any sense.
I'm currently in that exact situation, I called out months ago that a specific project would be a disaster because my team wouldn't be able to deliver our part on time. But the contract being already signed for big money, I was simply ignored and this is definitely the worst times I've lived in this company. So yeah, I wouldn't have gotten a bonus, but my life today would be much easier.
I was once among a rather large bunch of key people all trying together to kill a project that was going to be a mess. We failed. The bright side was that the project was given to the people who failed their rolls to disbelieve, and we the dissenters were all reassigned just outside the blast radius…
(It was a mess in ways pretty similar to the expectations, I don't think we would do better if we tried to save it not kill it, opinions differed on whether some of the issues were at the «completely unacceptable» level, and going forward things were gradually re-done in a more incremental way)
I like this write-up, and it surely contains hard-earned wisdom.
In my personal practice and experience (which is different from the author's, because I'm rarely at large corporate scale), I like to have a mixed meeting early on with leadership (whoever will join), stakeholders, and engineering, and we earnestly solicit risks from everyone. (Then again in private.) I seek to capture as many risks as possible, including existential, political, time-based, business, and technical. I march the risks past everyone's eyes at delivery milestones and during planning sessions, and will occassionally assign names to specific ones for strategic mitigation/containment ownership.
It's a bit depressing -- although I do take it on faith from people like the author -- that there are common settings where people in and adjacent to projects will identify significant & accurate risks that then simply remain tacit and hidden except to a few. I suppose it's overly idealistic to think that if there was enough, say, radical candor, that it could bear the load of fully transparent risk-assessments and their associated discussions; in practice, perhaps the dot product of everyone's competing interests and politics is simply too large.
One of the key ingredients to a working SRE culture is that SREs are never obligated to take ownership of services or codebases. Rather, when a software team wants long-term reliability, they must negotiate with SRE. Usually, SRE only takes ownership of a service as a last resort or as a final step to maturity, after the original development team has dissolved.
Very wise piece.
Politics and solving the correct problem matter just as much as technical beauty.
Exactly - you cannot win all battles; pick the right ones, worth energy fighting for.
Open source project maintenance follows a similar model, but with a different set of stakes.
The "price tag" of voicing concerns is lower, yet raise them too often and you still earn a reputation as obstructionist. Meanwhile, the cost of accepting problematic changes can be higher—you may end up maintaining that code long after changing jobs. And unlike corporate politics, the "influence bank account" is public: communications are archived indefinitely.
There is a fascinating shift in how "withdrawals" are calculated:
In a corporate hierarchy, the cost of dissent feels exponential: something like cost = exp(their_level - your_level).
Say, as a Google L3/L4/L5 engineer, opposing L6-L8 feels like trying to make a massive withdrawal with a tiny balance. In contrast, in OSS the cost almost stays constant despite the corporate level difference.
This created a paradox for me: leaving Google means less time for LLVM maintenance, but it also lets me voice objections more freely, without the shadow of internal performance ratings or hierarchical friction.
That said, I know I've been "withdrawing" heavily, including from a lot of previous colleagues. In a recent LLVM Project Council meeting:
There is a pattern of behavior here of blocking contributions due to concerns about maintenance cost and design simplicity.
(I appreciate the transparency of making these meetings public, by the way.)
I had to respond at https://discourse.llvm.org/t/llvm-project-council-meeting-november-19-2025/88848/3?u=maskray
In OSS responsibility is ultimately about deciding which features are worth the permanent "tax" on your time, and being willing to pay the "reputation price" when the design isn't right.
Your attention is finite, but the capacity for a large company to generate bad ideas is infinite.
True even for small companies!
Great write up.
At the risk of not sounding senior enough: I'm shocked by the comments agreeing with this post. While I was reading it, I was like, "no... no way... nope... not a chance...". Folks, I don't want to work with a project/company where bad things (as I saw them) cannot or are not worth being called out. That's against my culture and my beliefs.
Think of it this way: most of this post is about different ways of "calling out". You can "call out" things in a GitHub issue; in a structured code review; in a smaller meeting; in a private meeting; in many private meetings leading up to a public meeting; with an email to your manager or architect or CTO or CEO; with a letter to your state Attorney General… You have to choose the most effective way to do it, considering all the stakeholders, and your own career is one of the stakes.
The $5 Check: A nitpick on a code review. Cheap, daily expense.
[...]
The problem comes if you spend $5 on every minor inefficiency you see. If you are constantly saying “no” to small things, your account will be empty when you need to write the big check to stop a true disaster.
This is why it is necessary to have capable and automated QA tools that run before or during each PR.
Consistency and attention to detail are important to avoid accumulating tech debt, but nobody should pay the price of keeping the project's code in a good shape "out of their [political] pockets".
I really like this post.
The most important thing to do first is to be humble and evaluate whether you actually have the expertise to make a judgment. Seniority often brings opinions, but those are not always informed opinions.
I’ve seen quite a few cases of senior devs “intervening in bad projects” where all they have truly done is reveal their lack of understanding or context. And I agree there are significant downsides to gaining a reputation as a negative person.