<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>stevoski</author><text>I&amp;#x27;ve definitely been that person who didn&amp;#x27;t want the project to succeed - and I was the key developer (and an external consultant). I was convinced that we were implementing the wrong thing. Even though I tried to suck it up and do the job, it was hard to do my best on something I was sure was going to fail.&lt;p&gt;I had to be talked out of quitting a couple of times. I think they might have been better letting me quit the first time, and getting a replacement who didn&amp;#x27;t have so much ego affecting their work.</text><parent_chain><item><author>unoti</author><text>Probably the biggest surprise I&amp;#x27;ve seen in my career as a team lead is how often people ostensibly work with the team, but actually want to see the team fail.  It sounds ridiculous, I know, but it actually happens quite often.&lt;p&gt;Here are two quick examples where I see this happen often.  Let&amp;#x27;s say you&amp;#x27;re a vendor deploying software at an organization, and one or more people that work at your client organization originally wanted to write their own solution for this software, and their bosses overrode their wishes, and now they&amp;#x27;re forced to help implement your software.  You need to use those disenfranchised IT people as part of your team to do the implementation, but they&amp;#x27;d like to see the project fail, because they told their manager they could do it better themselves.  Other variations of this occur whenever someone doesn&amp;#x27;t get their way, and is forced to go implement things a different way -- now any delays that happen may demonstrate their sage wisdom in not wanting to do it this way.&lt;p&gt;I&amp;#x27;ve also seen variations on this same theme where a company is working on a product that does what we&amp;#x27;re implementing, but it&amp;#x27;s not ready yet.  Then a year down the road, when we&amp;#x27;re doing the final rollout, their product is almost ready, so now they&amp;#x27;d like to see us fail.  And suddenly the alliance falls apart.  Over the last 30 years working in IT, I&amp;#x27;ve seen something like 20-30 variations on this theme.&lt;p&gt;Lots of times you need to work with people who really want to see your project fail.  This came as a huge surprise to me, but I think any senior person should be careful and on the lookout.  It&amp;#x27;s often a significant project risk, and almost always overlooked.</text></item></parent_chain></comment><story><title>Things I was unprepared for as a lead developer</title><url>http://dev-human.com/entries/2015/09/07/things-i-was-unprepared-for/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>fit2rule</author><text>&amp;gt;often people ostensibly work with the team, but actually want to see the team fail&lt;p&gt;I&amp;#x27;ve definitely seen this as a very common proclivity of small, poorly structured teams, over 30+ years of software development experience.&lt;p&gt;&amp;quot;Buy-in&amp;quot;, or .. the phenomenon of staff actually buying into the project, and investing themselves in the effort required to realize a particular vision, actually requires them to agree with the project policies and strategy.  If people in the team do not agree - like, actively, not just saying &amp;#x27;I agree&amp;#x27; - not much work ever really gets done.&lt;p&gt;People who feel they have to covertly work to make a team fail need to realize where the failure really starts: in the decision to do so, without communicating about it.&lt;p&gt;Whereas, on the other hand, teams who really like each other - enjoy the project - use the technology well - and are open about the things they do not like about their daily&amp;#x2F;weekly work load - often accomplish amazing things.&lt;p&gt;It all starts with the decision to make something happen.  If that decision is made for you by someone else, either buy the decision or don&amp;#x27;t.  Loitering around to &amp;#x27;do the right thing and destroy the project&amp;#x2F;be there when it &amp;quot;inevitably fails&amp;quot;&amp;#x27; is quite a disastrous contribution, in my opinion.  I encourage everyone I work for - subordinate or superior, or otherwise - to keep things clean.  Work, or leave.</text><parent_chain><item><author>unoti</author><text>Probably the biggest surprise I&amp;#x27;ve seen in my career as a team lead is how often people ostensibly work with the team, but actually want to see the team fail.  It sounds ridiculous, I know, but it actually happens quite often.&lt;p&gt;Here are two quick examples where I see this happen often.  Let&amp;#x27;s say you&amp;#x27;re a vendor deploying software at an organization, and one or more people that work at your client organization originally wanted to write their own solution for this software, and their bosses overrode their wishes, and now they&amp;#x27;re forced to help implement your software.  You need to use those disenfranchised IT people as part of your team to do the implementation, but they&amp;#x27;d like to see the project fail, because they told their manager they could do it better themselves.  Other variations of this occur whenever someone doesn&amp;#x27;t get their way, and is forced to go implement things a different way -- now any delays that happen may demonstrate their sage wisdom in not wanting to do it this way.&lt;p&gt;I&amp;#x27;ve also seen variations on this same theme where a company is working on a product that does what we&amp;#x27;re implementing, but it&amp;#x27;s not ready yet.  Then a year down the road, when we&amp;#x27;re doing the final rollout, their product is almost ready, so now they&amp;#x27;d like to see us fail.  And suddenly the alliance falls apart.  Over the last 30 years working in IT, I&amp;#x27;ve seen something like 20-30 variations on this theme.&lt;p&gt;Lots of times you need to work with people who really want to see your project fail.  This came as a huge surprise to me, but I think any senior person should be careful and on the lookout.  It&amp;#x27;s often a significant project risk, and almost always overlooked.</text></item></parent_chain></comment><story><title>Things I was unprepared for as a lead developer</title><url>http://dev-human.com/entries/2015/09/07/things-i-was-unprepared-for/</url></story>