14 ms·

Probably the biggest surprise I'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.

by unoti 11y ago

Probably the biggest surprise I'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. Here are two quick examples where I see this happen often. Let's say you'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'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'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'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. I've also seen variations on this same theme where a company is working on a product that does what we're implementing, but it's not ready yet. Then a year down the road, when we're doing the final rollout, their product is almost ready, so now they'd like to see us fail. And suddenly the alliance falls apart. Over the last 30 years working in IT, I've seen something like 20-30 variations on this theme. 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's often a significant project risk, and almost always overlooked.

lfowles 11y ago
One way to look at the first case is as a morale issue. They were excite d to plan and roll out their solution and have been "demoted" to gluing pieces together. Even if not actively wanting the project to fail, they won't be top contributors.
- unoti 11y ago
  You're right. I've also often seen it where the disenfranchised people are the ones who wrote the original system we're replacing. And we need their help doing extracts for data conversion, and possibly interfacing to special systems only they know about. Same situation-- it can feel like a demotion. It's important to take special care to get those people on board.
  - dllthomas 11y ago
    Any tips for how?
    - unoti 11y ago
      I suggest a few basic tips: 1. Make them feel like you like them. Show a real and genuine interest in and admiration for them and the work they have done, and look for opportunities to tell them how brilliant they and their work are. It's important to be genuine and not blow smoke up their ass too much; look for opportunities to be genuine about this. 2. Get them to say they are committed to the team, committed to the project, and will do everything they can to get it to succeed. Once someone says something, they tend to remain consistent with it. Getting them to publicly declare it somehow is good. Also getting them to declare publicly related things such as "I'm a team player" somehow can be very helpful and alter the course of their thinking. 3. Show how other people are pushing for the team, and build bonds between these people and their teammates. People will walk through fire for the love of their team. All if those ideas are elaborated on in the book "Influence", thee are 3 of the 8 or so major themes of that book.
      - jweather 11y ago
        What's the author's name? There are several books by that title.
        Kalium 11y ago
        "How To Make Friends And Influence People". AKA Everything You Need To Know To Manipulate People.
        unoti 11y ago
        It's Influence by Bob Cialdini. I've also read How to Win Friends and Influence people, and it's very weak in comparison. The Cialdini book is rigorously researched and backed by science.
    - nethsix 11y ago
sokoloff 11y ago
The former is also a leadership problem at the company. Let's have a vigorous and open debate while we're leading up to a decision. That's healthy. Once a decision is made, it becomes everyone involved in the implementation's job to make it successful. If someone is openly running counter to that and isn't corrected or removed (at least from the project, and possibly from the company), you have a basic and straightforward leadership problem, IMO. (In the second case of inter-company alliances, that's more normal and less amenable to a simple solution. It's also far less cancerous if left unchecked.)
- shanemhansen 11y ago
  I was at a company where a vigorous debate was held on a technology decision. People failed to understand the difference between a democracy and anarchy. Or even between a team and anarchy. Sometimes everyone has to pull on the same side of the rope.
  - sokoloff 11y ago
    I think we're saying about the same thing. I'm not specifying (and don't believe) that democracy is the best way to resolve a technical debate, but I am saying that once a path is decided, however decided, you pull in that direction or you need to be removed.
    - shanemhansen 11y ago
      Indeed we are. Gp comment was a "me too" post.
    - Scarblac 11y ago
      The people who aren't convinced can feel that the debate is still open, even while the majority is convinced that a decision was made two months ago. I'm in the Netherlands, where hierarchy is a bit of a dirty word, and educated employees are all expected to be critical, independent, outspoken thinkers all working towards a common goal. That has many advantages, but the technical discussions about pretty small details can go on forever...
jlg23 11y ago
> Lots of times you need to work with people who really want to see your project fail. Then you should seriously rethink whether the way you handle your project is good. Either you convince your team, or they convince you. If you have to fall back to the power your position gives you, either your angle is wrong or you fail to communicate. Either way, the problem is never the people, but you. PS: I learned that the hard way and I am incredibly grateful to all those people in my teams who openly told me.
- colinb 11y ago
  You say "convince". I don't think that has application to many technical discussions. Often these aren't settled on merit, because they're not actually technical at all. It surprises and disappoints me that many of the most heated arguments at work are really discussions about human factors. Pretending that all discussions are going to be resolved amicably ignores ego, laziness, resistance to change, dislike of being publicly gainsaid, unwillingness to admit to mistakes, obsession with what's cool and so on. These are never going to go away. The very best managers can take these conflicting concerns, balance them, and make a choice while explaining to all that yes, what they said is interesting and important but no, they don't always get their way. The less good managers, i.e. most of them [us - I used to be a manager, but I wasn't very good at it] lack that ability and so arguments rumble on, grudges fester and somewhere along the line, someone who might be a sweetheart most of the time will take malicious glee in screwing things up.
  - Pyxl101 11y ago
    There's always a reason behind a decision that can be explained to a group of people such that they understand and accept (if not agree) with it. A decision very well might have nothing to do with engineering. That's fine, and it's acceptable to say: "We're making this decision because of X." It's better to expose everyone to the full business context so that they understand what the priorities are (within reason). From experience, engineers and scientists aren't always training themselves to consider business value. Sometimes it requires a step back to say, even though this is worse from an engineering perspective it's better from a business perspective. We're all here to serve the business, so let's do what's right for the business. Software doesn't exist to serve itself. Maybe we know how to engineer and manufacture the best widget in the world, but the widget market is falling off, and we need to build a wamboozle instead. People understand this stuff. The failure is often a failure to explain it.
obrero 11y ago
Sure, I've sabotaged outside vendors that came in myself. One Fortune 500 company I worked for set up a fledgling out-sourcing group. I would see the tickets come up and I grabbed every one of them. I also watched for their caller ID on the help line and picked those calls up. My modus operandi would be to just not do any of the work they needed. Luckily for me, they usually didn't dot every i and cross every t with their requests. Usually we would hand hold most people, but I used this as an excuse not to do them. I remember the group manager screaming at me that he was paying a tech to sit there all week and the tech was not doing any work because I was blocking him from getting e-mail, logins and so forth. Then the next week they managed to figure out how to talk to my manager, but I had been doing a good job on everything else so far, and showed my manager how their requests were imprecise (of course, usually I helped people fill any gaps on the requests). I set up that account that day, but managed to quash or delay a lot of their other requests. Within a few weeks I was transferred to a better position on another team, so their requests may have started going through faster, but I had probably managed to put their project behind schedule for a few weeks. In her book "Nickled and Dimed", Barbara Ehrenreich talks about applying to some minimum wage job and on the application it said something like "Me and my employer have united interests" with her able to agree completely (a 5) to disagree completely (a 1). I saw a similar question when I applied to a minimum wage job years ago. I thought of her book, and the opening words of the preamble of the IWW constitution "The working class and the employing class have nothing in common". Of course I put a 5, that I thought my interests and the big retailers interests were completely aligned :) . One of the first books on the subject of computer crime, "Computer Crime" by Donn Parker, tells employers that their worst problem is not outsiders, but their own employees. It goes back to the IWW constitution, or William Jennings Bryan's Cross of Gold speech. Or FDR's 1936 speech at the Democratic national convention about how "conditions of their labor - these had passed beyond the control of the people, and were imposed by this new industrial dictatorship". A speech after which FDR won over 60% of the vote and all but two states. Those who work and create wealth are a class different than the parasites and heirs who control and live off our labor. When the word comes down from on high that our work decisions are to be sabotaged more than usual, it's natural for us to sabotage the sabotage. It's in the nature of the relations of production at this stage of our society.
- 11y ago
timv 11y ago
One example of this, and it happens too often, is when people are training their replacements. Jobs are sent elsewhere (outsourced, off-shored, or both) and the people currently doing those roles need to train up the people who will be taking them over. I know one government department that decided to relocate a particular job function to another location as part of a broader "regionalisation" strategy. The people doing that job at the existing location were all going to be made redundant once the new team was ready to take on the work. The old team had an economic incentive to make the handover take as long as they could. The new team didn't have a lot of incentive to make it go fast. Sure, they were keen to do some real work, but they were also reasonably happy to only have 50% of the case load, and leave 50% back with the original team. Since only the people at the top had any real desire to see the project succeed, you can probably guess how well it went.
- berntb 11y ago
  As an external I asked a question on a task today: "Can you give me an example on where you store tracking information in orders? I haven't been into the relevant subsystem yet." I was answered "We only need to store that when the supplier sends the order". (Which of course was why I asked for -- and the task was about.) That non sequitur was a step up -- I got an answer. :-( I think I'm seen as a potential replacement. [Edit: No more Mr Nice Nerd, if I'm not answered tomorrow I won't trawl the code base again for a couple of hours but send this to the project leader directly. :-( ] (Yeah, I'm Hellbanned. Too easily trolled.)
- pluma 11y ago
  To be fair, training your replacements when an entire division is being outsourced to off-shore is incredibly cruel. My father in law works at an industrial manufacturer where several departments (including IT) are being outsourced to Southeast Asia. The company has been operating locally for nearly a century and a lot of the people who are being made redundant have worked there for decades and are now being kicked out at a point where they are too young for retirement but too old to find new jobs. I know that a company isn't a welfare organisation, but if you employ upwards of a hundred people in a small town you can't deny having some social responsibility. It's easy to see why the workers told to train their cheaper replacements are having a hard time staying professional.
stevoski 11y ago
I've definitely been that person who didn'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. 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't have so much ego affecting their work.
- troels 11y ago
  That's a very brave and honest comment!
  - ak39 11y ago
    Yes it was. But would it not have been braver of him to support the project by putting ego aside?
    - andrewingram 11y ago
      In fairness, he did say he tried. Perhaps there was a lack of bravery, perhaps he could have gone to this bosses and explained the situation, but perhaps he did that and it wasn't enough.
      - aknosis 11y ago
        It's also likely that he didn't realize what he was doing at the time. Maybe he felt upset or stressed about the situation but not necessarily that he was subconsciously hoping to failure.
    - klibertp 11y ago
      I wouldn't call that "brave". "Putting ego aside" is hard, requires a lot of work and in most situations it's a safe thing to do. Hence no bravery here, maybe loyalty would be a better word. He was being brave when he brought his problem to his superiors and said he'd like to quit. Actually, the only "braver" thing in this situation would be to quit anyway, without letting them "talk him out of quitting". But that could have been also stupid, we don't know the exact circumstances. On a more general note: everyone should try to ~~contain~~ [edit: solve!] his/her ego-issues (and other psychological issues) as much as possible, of course. But placing someone with mentioned issues on the project which caused these issues in the first place is clearly a fail of management. If "soft skills" are so important (and they are), then the management should use them! Management should place employees in an optimal environment so that psychological issues are less likely to occur. Making people work for a long time on things they are averse to is a recipe for disaster. Both for the employee and the project.
fit2rule 11y ago
>often people ostensibly work with the team, but actually want to see the team fail I've definitely seen this as a very common proclivity of small, poorly structured teams, over 30+ years of software development experience. "Buy-in", 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 'I agree' - not much work ever really gets done. 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. 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/weekly work load - often accomplish amazing things. 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't. Loitering around to 'do the right thing and destroy the project/be there when it "inevitably fails"' 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.
hga 11y ago
In my common role as a "fixer", someone called in or hired to rescue a failing project, one lesson I learned the hard way was to make sure the organization hadn't kept the person responsible for the failure on the same team, generally with a demotion. He would invariably continue to mess up the project; very possibly unconsciously, I figured one reason was that only continued project failure would validate his prior failure. That, and just plain incompetence, e.g. back in the bad old days of 8088 IBM PCs, when people frequently programmed in C, it wasn't safe to hand such a person the responsibility of error reporting code, which could easily crash the whole application (real example).

by unoti 11y ago

lfowles 11y ago

One way to look at the first case is as a morale issue. They were excite d to plan and roll out their solution and have been "demoted" to gluing pieces together. Even if not actively wanting the project to fail, they won't be top contributors.

unoti 11y ago
You're right. I've also often seen it where the disenfranchised people are the ones who wrote the original system we're replacing. And we need their help doing extracts for data conversion, and possibly interfacing to special systems only they know about. Same situation-- it can feel like a demotion. It's important to take special care to get those people on board.
- dllthomas 11y ago
  Any tips for how?
  - unoti 11y ago
    I suggest a few basic tips: 1. Make them feel like you like them. Show a real and genuine interest in and admiration for them and the work they have done, and look for opportunities to tell them how brilliant they and their work are. It's important to be genuine and not blow smoke up their ass too much; look for opportunities to be genuine about this. 2. Get them to say they are committed to the team, committed to the project, and will do everything they can to get it to succeed. Once someone says something, they tend to remain consistent with it. Getting them to publicly declare it somehow is good. Also getting them to declare publicly related things such as "I'm a team player" somehow can be very helpful and alter the course of their thinking. 3. Show how other people are pushing for the team, and build bonds between these people and their teammates. People will walk through fire for the love of their team. All if those ideas are elaborated on in the book "Influence", thee are 3 of the 8 or so major themes of that book.
    - jweather 11y ago
      What's the author's name? There are several books by that title.
      - Kalium 11y ago
        "How To Make Friends And Influence People". AKA Everything You Need To Know To Manipulate People.
      - unoti 11y ago
        It's Influence by Bob Cialdini. I've also read How to Win Friends and Influence people, and it's very weak in comparison. The Cialdini book is rigorously researched and backed by science.
  - nethsix 11y ago

sokoloff 11y ago

The former is also a leadership problem at the company. Let's have a vigorous and open debate while we're leading up to a decision. That's healthy. Once a decision is made, it becomes everyone involved in the implementation's job to make it successful. If someone is openly running counter to that and isn't corrected or removed (at least from the project, and possibly from the company), you have a basic and straightforward leadership problem, IMO. (In the second case of inter-company alliances, that's more normal and less amenable to a simple solution. It's also far less cancerous if left unchecked.)

shanemhansen 11y ago
I was at a company where a vigorous debate was held on a technology decision. People failed to understand the difference between a democracy and anarchy. Or even between a team and anarchy. Sometimes everyone has to pull on the same side of the rope.
- sokoloff 11y ago
  I think we're saying about the same thing. I'm not specifying (and don't believe) that democracy is the best way to resolve a technical debate, but I am saying that once a path is decided, however decided, you pull in that direction or you need to be removed.
  - shanemhansen 11y ago
    Indeed we are. Gp comment was a "me too" post.
  - Scarblac 11y ago
    The people who aren't convinced can feel that the debate is still open, even while the majority is convinced that a decision was made two months ago. I'm in the Netherlands, where hierarchy is a bit of a dirty word, and educated employees are all expected to be critical, independent, outspoken thinkers all working towards a common goal. That has many advantages, but the technical discussions about pretty small details can go on forever...

jlg23 11y ago

> Lots of times you need to work with people who really want to see your project fail. Then you should seriously rethink whether the way you handle your project is good. Either you convince your team, or they convince you. If you have to fall back to the power your position gives you, either your angle is wrong or you fail to communicate. Either way, the problem is never the people, but you. PS: I learned that the hard way and I am incredibly grateful to all those people in my teams who openly told me.

colinb 11y ago
You say "convince". I don't think that has application to many technical discussions. Often these aren't settled on merit, because they're not actually technical at all. It surprises and disappoints me that many of the most heated arguments at work are really discussions about human factors. Pretending that all discussions are going to be resolved amicably ignores ego, laziness, resistance to change, dislike of being publicly gainsaid, unwillingness to admit to mistakes, obsession with what's cool and so on. These are never going to go away. The very best managers can take these conflicting concerns, balance them, and make a choice while explaining to all that yes, what they said is interesting and important but no, they don't always get their way. The less good managers, i.e. most of them [us - I used to be a manager, but I wasn't very good at it] lack that ability and so arguments rumble on, grudges fester and somewhere along the line, someone who might be a sweetheart most of the time will take malicious glee in screwing things up.
- Pyxl101 11y ago
  There's always a reason behind a decision that can be explained to a group of people such that they understand and accept (if not agree) with it. A decision very well might have nothing to do with engineering. That's fine, and it's acceptable to say: "We're making this decision because of X." It's better to expose everyone to the full business context so that they understand what the priorities are (within reason). From experience, engineers and scientists aren't always training themselves to consider business value. Sometimes it requires a step back to say, even though this is worse from an engineering perspective it's better from a business perspective. We're all here to serve the business, so let's do what's right for the business. Software doesn't exist to serve itself. Maybe we know how to engineer and manufacture the best widget in the world, but the widget market is falling off, and we need to build a wamboozle instead. People understand this stuff. The failure is often a failure to explain it.

obrero 11y ago

Sure, I've sabotaged outside vendors that came in myself. One Fortune 500 company I worked for set up a fledgling out-sourcing group. I would see the tickets come up and I grabbed every one of them. I also watched for their caller ID on the help line and picked those calls up. My modus operandi would be to just not do any of the work they needed. Luckily for me, they usually didn't dot every i and cross every t with their requests. Usually we would hand hold most people, but I used this as an excuse not to do them. I remember the group manager screaming at me that he was paying a tech to sit there all week and the tech was not doing any work because I was blocking him from getting e-mail, logins and so forth. Then the next week they managed to figure out how to talk to my manager, but I had been doing a good job on everything else so far, and showed my manager how their requests were imprecise (of course, usually I helped people fill any gaps on the requests). I set up that account that day, but managed to quash or delay a lot of their other requests. Within a few weeks I was transferred to a better position on another team, so their requests may have started going through faster, but I had probably managed to put their project behind schedule for a few weeks. In her book "Nickled and Dimed", Barbara Ehrenreich talks about applying to some minimum wage job and on the application it said something like "Me and my employer have united interests" with her able to agree completely (a 5) to disagree completely (a 1). I saw a similar question when I applied to a minimum wage job years ago. I thought of her book, and the opening words of the preamble of the IWW constitution "The working class and the employing class have nothing in common". Of course I put a 5, that I thought my interests and the big retailers interests were completely aligned :) . One of the first books on the subject of computer crime, "Computer Crime" by Donn Parker, tells employers that their worst problem is not outsiders, but their own employees. It goes back to the IWW constitution, or William Jennings Bryan's Cross of Gold speech. Or FDR's 1936 speech at the Democratic national convention about how "conditions of their labor - these had passed beyond the control of the people, and were imposed by this new industrial dictatorship". A speech after which FDR won over 60% of the vote and all but two states. Those who work and create wealth are a class different than the parasites and heirs who control and live off our labor. When the word comes down from on high that our work decisions are to be sabotaged more than usual, it's natural for us to sabotage the sabotage. It's in the nature of the relations of production at this stage of our society.

11y ago

timv 11y ago

One example of this, and it happens too often, is when people are training their replacements. Jobs are sent elsewhere (outsourced, off-shored, or both) and the people currently doing those roles need to train up the people who will be taking them over. I know one government department that decided to relocate a particular job function to another location as part of a broader "regionalisation" strategy. The people doing that job at the existing location were all going to be made redundant once the new team was ready to take on the work. The old team had an economic incentive to make the handover take as long as they could. The new team didn't have a lot of incentive to make it go fast. Sure, they were keen to do some real work, but they were also reasonably happy to only have 50% of the case load, and leave 50% back with the original team. Since only the people at the top had any real desire to see the project succeed, you can probably guess how well it went.

berntb 11y ago
As an external I asked a question on a task today: "Can you give me an example on where you store tracking information in orders? I haven't been into the relevant subsystem yet." I was answered "We only need to store that when the supplier sends the order". (Which of course was why I asked for -- and the task was about.) That non sequitur was a step up -- I got an answer. :-( I think I'm seen as a potential replacement. [Edit: No more Mr Nice Nerd, if I'm not answered tomorrow I won't trawl the code base again for a couple of hours but send this to the project leader directly. :-( ] (Yeah, I'm Hellbanned. Too easily trolled.)
pluma 11y ago
To be fair, training your replacements when an entire division is being outsourced to off-shore is incredibly cruel. My father in law works at an industrial manufacturer where several departments (including IT) are being outsourced to Southeast Asia. The company has been operating locally for nearly a century and a lot of the people who are being made redundant have worked there for decades and are now being kicked out at a point where they are too young for retirement but too old to find new jobs. I know that a company isn't a welfare organisation, but if you employ upwards of a hundred people in a small town you can't deny having some social responsibility. It's easy to see why the workers told to train their cheaper replacements are having a hard time staying professional.

stevoski 11y ago

I've definitely been that person who didn'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. 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't have so much ego affecting their work.

troels 11y ago
That's a very brave and honest comment!
- ak39 11y ago
  Yes it was. But would it not have been braver of him to support the project by putting ego aside?
  - andrewingram 11y ago
    In fairness, he did say he tried. Perhaps there was a lack of bravery, perhaps he could have gone to this bosses and explained the situation, but perhaps he did that and it wasn't enough.
    - aknosis 11y ago
      It's also likely that he didn't realize what he was doing at the time. Maybe he felt upset or stressed about the situation but not necessarily that he was subconsciously hoping to failure.
  - klibertp 11y ago
    I wouldn't call that "brave". "Putting ego aside" is hard, requires a lot of work and in most situations it's a safe thing to do. Hence no bravery here, maybe loyalty would be a better word. He was being brave when he brought his problem to his superiors and said he'd like to quit. Actually, the only "braver" thing in this situation would be to quit anyway, without letting them "talk him out of quitting". But that could have been also stupid, we don't know the exact circumstances. On a more general note: everyone should try to ~~contain~~ [edit: solve!] his/her ego-issues (and other psychological issues) as much as possible, of course. But placing someone with mentioned issues on the project which caused these issues in the first place is clearly a fail of management. If "soft skills" are so important (and they are), then the management should use them! Management should place employees in an optimal environment so that psychological issues are less likely to occur. Making people work for a long time on things they are averse to is a recipe for disaster. Both for the employee and the project.

fit2rule 11y ago

>often people ostensibly work with the team, but actually want to see the team fail I've definitely seen this as a very common proclivity of small, poorly structured teams, over 30+ years of software development experience. "Buy-in", 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 'I agree' - not much work ever really gets done. 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. 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/weekly work load - often accomplish amazing things. 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't. Loitering around to 'do the right thing and destroy the project/be there when it "inevitably fails"' 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.

hga 11y ago

In my common role as a "fixer", someone called in or hired to rescue a failing project, one lesson I learned the hard way was to make sure the organization hadn't kept the person responsible for the failure on the same team, generally with a demotion. He would invariably continue to mess up the project; very possibly unconsciously, I figured one reason was that only continued project failure would validate his prior failure. That, and just plain incompetence, e.g. back in the bad old days of 8088 IBM PCs, when people frequently programmed in C, it wasn't safe to hand such a person the responsibility of error reporting code, which could easily crash the whole application (real example).