Hacker News Reader

I agree with your take on this in general: It's better to be tactful and focus on beneficial outcomes rather than "being right".

However, in this specific case, it sounds like:

1. Management was charging a client $60MM for a product they had promised.

2. They were convincingly told that they would be unable to deliver that product.

3. Their response was "Don't let the client find out."

And then what ended up happening was they failed to deliver and still charged the client. That's a massive breach of ethics and potentially outright criminal fraud. Quitting and getting the fuck out of there is 100% the right call.

I think the question a senior-level IC needs to ask themselves is how much they care about stuff "above their pay grade" when this sort of thing happens. Personally, I don't have the patience to deal with super-dysfunctional management structures where they just want to ignore reality unless someone takes the time to Jedi-mind-trick them into doing the right thing. I would much rather give them the straight dope, and let them decide if they want to do the right or wrong thing. And if they want to do the wrong thing, that's just a very clear sign that's an organization I don't want to continue to be associated with.

And yes, I mournfully agree that this is the state of many organizations and management teams. But life is too short for me to put up with their bullshit.

Your solution to a dumpster fire is to play a very risky game of hero, navigating an environment where at any point you could step on someone's toes, in hopes of salvaging a project for which there is absolutely no guarantee you'll get credit, let alone a sizeable reward, while the market is rife with opportunities. For a bunch of capitalists, not some noble goal.

Forgive me, but playing hero (really just martyr) sounds like the absolute least logical thing to do.

Not necessarily — the person you’re responding to said you can always ride it out if you don’t want to take on more responsibilities. That’s fair to me: look for solutions if it suits you, but otherwise stay silent and don’t introduce negativity (which is bad for you politically in addition to being bad for the project).

I have to agree. When the risk is greater than the reward, you have to ask if the project is worth sacrificing for. I find the answer is generally no. Even noble projects are set into situations where it isn't worth the sacrifice. From a purely pragmatic view, you can do better for the world by skipping the sacrifice and finding a similar noble project to keep working at.

It is a sort of prisoner's dilemma. Society is worse off because people tend to operate this way, not just in IT but all over. But we aren't going to fix society, so build a small kingdom in your life you can control and try to make things nice within it.

I don't understand how the deputized team drove off the cliff. At the very least they surfaced the set of problems which would need to be addressed to meet the contract.

The 12 month extension was going to get the managers who proposed it fired. So they couldn't actually propose it - thus the cliff.

Instead they needed an alternative. Of course a better discussion would have been a frank reevaluation with the client, with several options and points of trade-off to consider.

But really the best way - presuming everyone is working toward the same ends (NOT a given) - is to identify some kind of MVP/pilot that can been delivered and evaluated and iterated upon. That way you have _some_ kind of success to build upon with the client. This is failure of every badly run waterfall project. Even presuming the original design could be built on time ... how would it know it was actually useful? You also need the more limited success to rebuild trust - otherwise your new estimates will be questioned and looked upon with suspicion. If some tells me an 18 month project is going to take another 12 months, I need to assume the same incompetence really means that the new estimate is behind the curve as well ... not to mention changing requirements in the meantime continuing to push thing things out.

> presuming everyone is working toward the same ends (NOT a given)

I have realized that in many cases neither the decision-makers at the client nor the decision-makers at the consultant/vendor are working towards the ends of a succesful product. Their ends are their careers, and benefit to their careers may be pretty orthogonal to actual product success.

Once when I was working at a place, I had a discussion:

"I think if we use this vendor solution, it's likely to not work very well for our users. I think we have a better chance of meeting our users needs doing it in-house."

"You could very well be right, but if we do it in-house and fail, it'll be our fault, everyone will blame us. Everyone is used to using the vendor for this, it's a decision nobody will blame us for, even if it fails. We're going with the vendor."

In some cases, everyone can in fact have their goals aligned... their goals simply aren't product success.

The end of the story is that they left the company. That’s a fine way to end the story, and maybe that doesn’t seem like defeat. But there tends to be better ways to handle it.

Most people can’t afford to leave at a week’s notice, which is what I meant by driving off a cliff.

I did what you would have done in my previous job [1]. A larger "enterprise" style company bought us out and was trying to force their Enterprise Agile unto us. I felt it was the wrong development style for the team I was one---for over ten years my team had always been on time, on budget, smooth deployments (four a year was a "busy" year for us [1]) and no show-stopping bugs in production. Once the new company took over, we were blowing our deadlines, disastrous deployments and major bugs in production were found.

I raised my concerns up the chain of command, and got to a VP of the new parent company, who was looking into the situation until he was let go (or sacked, depending upon your point of view). All I wanted to do was go back to our previous style of development, which worked. But no, the parent company wants to do it their way.

I left shortly thereafter.

[1] Our customer was (well, technically still is if they're still a customer) a major cell phone carrier where a sprint for them is two years, not two weeks.

> nor is it to say blatantly that a project is doomed. There’s usually a middle ground.

If you are in a situation where you are presenting 12 man-months of missing work to management and they stick their head in the sand instead of asking ‘how can we accomplish this anyway’ then your project is doomed.