Would you simply tell them they're not doing their job, or would you ask questions, talk in private, and try to dig in tactfully?

When I was 22 or so, I did go around telling a certain senior engineer that they weren't doing their job. I still cringe at how headstrong I was back then. The people around me were trying to hint that things aren't quite as clear cut as it seems, but it took a swift kick in my backside to reboot my worldview.

You're right that the optimal strategy is not to stress about it, though. That would've saved me a lot of heartache.

My point is (and the point of many other commenters here) is that you can't really show up to a meeting and say "This project is doomed." That's arguably one of the core advantages of startups over bigcos -- you can pivot.

Your options are to climb the politics ladder, or ride it out and see what happens. It depends how much you care, or how much responsibility you want.

Was your rebooted worldview that you had been factually incorrect (i.e. the senior dev actually did do his work) or was it that you were factually correct, but hierarchy and office culture demanded that everyone pretend you weren't?

One specific incident comes to mind. I was working on Heroes of Newerth, a DotA clone. We achieved a bit of popularity in those days, and we reached around 50k concurrent users. So our servers tended to melt.

One day, the servers went south, and although games were being completed, none of the stats were being recorded. (Think of it like, the database was in read only mode.)

I remember it feeling a little surreal how they decided to handle it. They kept cool, looked into the problem, and got the servers back up within a couple hours. Then they went back to their usual jobs and didn’t seem bothered by the ticking time bomb.

I think in my usual 22yo fashion, I said that it was dumb that no one seemed to care that the servers were going down, and that we had to do better for the players.

What I should have done was ask questions. Should we try to figure out the root cause, and make sure this doesn’t happen again? Or was it really not a big deal?

A few hours’ downtime may or may not have been a big deal. We did end up suffering from some pretty serious server malfunctions which limited our ability to scale. But I certainly mishandled how to approach it, and won no friends.

Every team is dysfunctional in their own way. It’s important to adapt to the dysfunction and push things in a positive direction, not merely to be right.

Instead, I think HoN made some very bad decisions regarding cosmetics and fostered an extremely toxic playerbase. At least for me, those were the 2 main factors that drove me away to play DotA2 (even though I thought HoN's gameplay was superior).

The moment icefrog and valve dropped their $1M tournament prize pool, the company in hindsight was doomed. But it took a couple years to sink.

Players follow pros, and if the pros are playing DotA, they’ll switch to DotA. Our only chance was to keep the pros. It would have been smart to make an exclusive contact with as many pros as possible. But of course, that’s with hindsight.

The rise of twitch happened to coincide with the rise of pro DotA, which I think was a factor in shifting popularity.

> drove me away to play DotA2

How toxic is the HoN playerbase if DotA2 is an improvement? I don’t think I’ve ever not enjoyed my games as much as in DotA2.

* the existence of behaviour score together with a functional report system, which I don't think was a thing in HoN. I'm at 10k behaviour score (max) and there are generally no game ruining griefers. Some people do trash talk sometimes, but nothing too obscene.

* HoN cosmetics actively encouraged players to BM one anther. e.g. the Dumpster Taunt https://www.youtube.com/watch?v=VC4j4U7K6mc If you die while taunted you have a dumpster thrown on you and the global announcer tells you to get "dumpstered". Taunting a player right when they die (which is a strongly negative emotional moment) is a great way to tilt them and, in turn, make them grief, com abuse or generally bm. That negatively affects the rest of the players and the cycle goes on.

* A bunch of players in the HoN pro scene had really bad manners, e.g. Moonmeander was notorious for his trash talking, taunting and general BM. He actually significantly toned it down when he moved over to DotA - unclear if that was because he grew up or because the DotA pro scene is a different environment. Regardless, the behaviour of pro players sets the tone for how the community at large behaves, and the DotA pro scene is much nicer. (incidentally, this is why I believe pro players should be held at much higher standards of manners than the rest of the player base. Stuff like saying glhf, gg and generally not acting dickish should be mandatory)

Broadly, maybe. At work, I don't care about being liked by people that can't admit they are wrong.

That doesn't being a dick to anyone I think is wrong. The whole point of telling someone that they're wrong is to correct course and fix things, and bullheaded, righteous, approaches never accomplish that.

But it does mean you don't keep quite. You don't give up. You ask questions, you try to learn. Because part of the process of saying that something is wrong is being willing to learn that maybe you are the wrong one.

I understand being unwilling to bulge to people that come in thinking they know better about everything. But I do not accept not even listening to someone that disagrees, that's a red flag,and I am out asap.

Why do you presume all outcomes of your eggregious interactions is placing blame on others?

It seems you are totally oblivious to some of the most basic principles of working in a professional environment: if you antagonize and attack your team members, you are not trusted to help out and have their backs. This means you are not an asset but a liability. Working close to you is making them vulnerable to being stabbed in the back by you at the slightest issue. And that's why you are not liked, even if/when you are right.

All the people can be right, but that doesn't justify you insisting on pissing on everyone else's cereals.

I 100% agree that if you tell people they are wrong aggressively and arrogantly, that will backfire, and they are probably justified in ignoring your correction.

But some people, and particularly some organizations, seem incapable of accepting even the most thoughtful correction, and that's the kind of place/people I'd rather keep a distance.

   Because part of the process of saying that something is wrong is being willing to learn that maybe you are the wrong one.

Not only are there better ways to let people know they're wrong when you're 100% right, but in your example you aren't even sure you're 100% right, yet telling others they're wrong.

Good luck with that :)

    "Because part of the process of saying that something is wrong is being willing to learn that maybe you are the wrong one."

So, yeah, I don't see a conflict on thinking something is wrong, pointing it out, and arguing for change, and at the same time be open to be convinced that it wasn't, in fact, wrong.

    Saying that something is wrong doesn't imply (at least for me) that you're 100% sure that it's wrong.

    English is my second language, so, I might be missing some nuance.

Telling someone they are wrong, means you know for a fact that they are wrong.

It does not mean you think they may be wrong.

It is binary.

You do not tell someone they are wrong if they may in fact not be wrong.

Thanks for the nostalgia hit!

What a novice usually does not realize is:

It is easy to be right. What is hard is being actually helpful, coming up with a viable solution (vs. an idea).

In the posted article there simply was no such solution. It was not viable. Unacceptable.

Yes, an outsider with fresh eyes might see things differently and without bias, but most certainly the experienced team knows damn right that you're right (to some degree), but also knows that it's just not that easy.

Throwing "We are doing this all wrong" around is often just short of saying: "I just came here and I immediately saw that you all are idiots, you should listen to me!".

I'm not saying that fresh input can't be helpful, outsiders might bring in new tricks and ways, but being humble is way more helpful than being loud.

It's easier to be wrong.

In the article, the management team had already failed to do their jobs.

They had already failed to notice (or ignored) obvious problems, and the company clearly had a culture that discouraged raising or acknowledging such issues.

They also had failed to work with the client to establish a complete set of requirements - 9 months before the end of a multi-year project.

> It was not viable. Unacceptable.

The option that they suggested, letting the project slip, was a significantly more viable option than what they actually took.

Re-evaluating the requirements and coming up with a viable subset of deliverables would also have been a sane choice.

But since the company had no intention of letting the client know they were having trouble, sane solutions were banned from the table.

And it is cinsiderably harder to be actually helpful.

While everything you said is true, we and the author do not know what was previously discussed with the client. We don't know what was promised by either party, we don't know what the client messed up

Heck, I attended meetings with partners/clients that were simply impossible to get an output from, since the expectations in general were on completely different sides of the book.

But you air this out, realize that everyone agrees, most people resignate, and really helpful is this one guy, that offers to invest effort and time to work closely with a well chosen peer from the other side to get them on your side and finally work on the interesting things.

This is helpful. And it is hard.

That isn't the case, has never been the case and will never be the case.

  > "I just came here and I immediately saw that you all are idiots, you should listen to me!".

There could be dozens of other reasons beyond just these two...

The single most common fault that I see is perspective. Individual sections have limited context or visibility of the whole picture to assess the importance of their section's dysfunction. This isn't necessarily a bad thing -- in a highly-fluid environment, it's often important for sections to achieve their own objectives without N^2 comms overhead (e.g. military command & control). Firefighting provides a useful analogy. One section's 4-alarm fire might actually be a 1-alarm or 2-alarm fire for the broader organization -- which means that other sections might get top exec billing.

For example: If this $60M contract was at Boeing during the last few years, it will rightfully be deemphasized while executives deal with the existential threat of 737 Max matters.

The failure here is not one of lack of politics or communication on the part of the author or their team, but on the culture of the management team. Why invite that presentation if all it does is publicly humiliate your PMs?

Could the deputies have done more? How is amateur politicking by technical contributors perceived at your place of work?

If it were me, I would have privately (emphasis on private) worked my way up the chain of command, trying to alert more and more people that there was a serious problem brewing.

The meeting in the story was obviously going to be a failure. So if you’re in a situation where you know that X is going to fail, doing something other than X is advisable. I would’ve tried to work with the deputized team to come up with a smaller plan that could be executed in, say, three months, and then figured out how to sell it to management in a way that three months isn’t a dealbreaker.

Alternatively, I would have gone to management ahead of the meeting and let them know privately what they should expect to hear. That way they’re not completely surprised when you’re in Zoom, presenting a 12 month extension, and they have to say something. “It would be career limiting” is about the best thing they could say.

You want to give them a better alternative. And giving management good alternatives is arguably the job of line engineers like us. We’re a part of a team; our job isn’t merely to do what we’re told, nor is it to say blatantly that a project is doomed. There’s usually a middle ground.

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.

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.

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

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.

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.

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.

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

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.

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.

Week 2 I was supposed to get assignments from the lead developer, but they were holding things close to their chest. I was given very, very menial things to do, or just told to continue to study the code. When we'd have project meetings and they'd ask how things were going overall, the lead developer would assure them we were on target - even in the face of ongoing bugs, missing features and incorrect functionality during QA testing. I'd offer the Lead my help, but they hadn't found the right task yet.

By the end of week 2, beginning of week 3, I was fairly confident the code I was researching was not lining up with the status reports in the project meetings. I started to speak up and ask questions to surface concerns in attempt to get something thrown my way. Again, the Lead Dev continued to assure management we were on target and that seemingly huge TODO items were trivial and would be handled in short order. I was kept on standby.

As things continued to progress in this direction, management finally bypassed the Lead and came directly to me to my feel for where were at. At this point I had only been with the company 3 to 4 weeks, but I had been a developer for 11 years. I told them in not so uncertain terms, "this project is doomed". The Lead dev is wildly overpromising deliverables, minimizing outstanding work and shielding the management team from truly understanding how behind he was. I honestly had no idea what his plan was to meet the deadline, but based on my estimates we were easily 4 to 6 months out. They were flabbergasted.

I continued to provide direct status reports at management's request. It felt like politics, but what else could I do? By the 2nd week in December, 6 weeks into my employment, the writing was on the wall. The project was canned, the Lead Dev was fired and I was wondering if I had still had a job myself as the only developer and no projects on the timeline.

By the end of the following year, I had been promoted to management overseeing a team of 3 and still developing myself. We rebuilt the project from scratch and implemented it exactly 1 year after its initial planned release.

I never wanted management and certainly never wanted to get anyone fired, but sometimes you have to put it all out there in black and white.

Telling a manager "we uncovered work that wasn't in the original spec" isn't literally the same thing as telling them they aren't doing their job.

In a situation like that, you can recover, but it requires tact. The end of this story was that they left the company. An alternate ending is that they may have been let go.

If they’re paying you to work on a doomed project, you have to work on it, or change it. And if you want to change it, political maneuvering is necessary.

But what's their incentive? They're probably paid as a regular IC, and saving a double-digit million dollar fiasco like this from disaster is super annoying and unrewarding work! You're effectively doing the job of five managers and not even getting their salary -- let alone a percentage of the disaster you're averting! This kind of political-technical skill combination can probably be fruitfully applied in a place that properly rewards the contributor!

I very much agree that this thing could have been handled better, when seen externally. But I'm also pretty sure it wasn't in OP's personal interest to do so! That's a very stupid state of affairs, of course, but I guess that might be par for the course of a failed $60 million project.

Pointing out that you've underestimated by X is pointing out something everyone already knows. And advocating to blow up the estimate by X so early in the project is arguing to piss the customer off and possibly walk away from $60 million. That's why everyone patted them on the head and blew them off. Everyone else understood the game but it's a bit gauche for them to explicitly explain what's going on.

I'd bet it doesnt requires tact to convince them anymore.

If necessary someone else will tell them they are not doing there job. Stick to your role.

One of the many benefits of being having extremely employee friendly laws is that you can absolutely do this.

It still doesn’t really help, but it’s not ‘career limiting’ either.

In TFA's case I suspect there really was no solution short of sinking a pile more cash into the project, and that was probably not an option. Though, who besides TFA knows, TFA gave us too little detail to be able to tell.

The problem described in TFA is that leadership was happy to ignore a problem rather than do anything. In that kind of culture you don't make your career by raising attention to issues (even with solutions, because remember, they don't really care), you get sidelined. In that kind of culture it's better to just compliment the emperor on his new duds.