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.
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.
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.
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.
And the social responsibility arises from shaping the local economy in such a way that a large number of people become dependent on the company. If a company becomes the main employer in a small town, it automatically takes on some responsibility. This is less true today when most people know they're not going to work for the same employer until retirement but it is still true for traditional companies with that kind of legacy.
It's not about some theoretical ethical responsibility for the greater good of mankind but about taking responsibility for your actions and the effect they have on people you have built a relationship with. If Industrocorp, Inc builds a factory in Podunk and the labour demand raises the number of residents by an order of magnitude, then relocating operations and firing a large number of staff will ruin the local economy the company created.
I'm not sure how that concept is difficult to understand: your actions have consequences, ergo you are responsible for the consequences of your actions. Large corporations may be amoral, but the CEO of a privately owned company deciding to offshore half the employees isn't. Especially when the company periodical repeatedly claims that the employees are valued and their families are important. This makes the CEO an asshole. Period.
Why does a non-contractual relationship change things? Are you applying the Copenhagen theory of ethics or something?
http://blog.jaibot.com/the-copenhagen-interpretation-of-ethi...
Also, why dont the workers who became dependent on a company deserve responsibility for that action?
I realise HN is a weird place to argue this, but corporations don't exist in a vacuum. They can't exist in a vacuum. Without a state guaranteeing its rights and the means to enforce those rights, a corporation is just a group of individuals. This is not only true for corporations. You don't have any rights other than those afforded to you by society (whether on a local level like the US or a global level like the UN). If there's no-one who's going to enforce your rights, they become purely philosophical (cf. Guantanomo -- unless you believe the UN is going to take on the US government and bail you out of there).
The social contract is primarily between an individual and society at a local level. Thanks to globalization it now extends to other societies across the globe, but the responsibilities of a local corporation to residents of a country on the other side of the globe they don't already have any business relationships with is only secondary at best.
That said, you're kidding yourself if you are trying to argue that increasing profit (or cutting costs, which boils down to the same effect) by outsourcing to cheaper markets could even remotely be considered something ethically positive.
[0] I'm using the terms "society" and "state" or "government" interchangeably here based on the democratic principle that a state derives its legitimation from the people, i.e. the society it governs.
What makes the social contract local? Why not say the social contract is primarily between and individual and his race, his class, his clan or his religion?
At one time it was considered a violation of the "social contract" for a white man to hire cheaper negro workers (language chosen to evoke that era). Many folks still consider it a violation of the "social contract" to hire someone who isn't Marathi. Why do you choose geographic locality rather than race?
Outsourcing to cheaper markets reduces poverty and inequality. As a person who doesn't consider Debbie more valuable than Deepika (both are real people that I know personally), I consider helping Deepkia (born into dire poverty and with little chance to escape) far more ethical than helping Debbie.
Stats: http://www.maxroser.com/economic-world-history-in-one-chart/ http://ourworldindata.org/data/growth-and-distribution-of-pr...
You're asking questions that have been discussed at length by philosophers, and while there is no definitive "answer", there are some thought frameworks you can think in. Questions of ethics are hard because they're dependent on culture, and their axioms do not stem from nature (although a few philosophers claim they do) but from human psychology and social-psychology. Still, they're not completely arbitrary. You can say your values make you prefer ethical framework A over ethical framework B, but each framework -- while may not 100% logically sound and 100% consistent -- at least frames the discussion.
So, to get back to your question, there are certainly reasons -- within a given ethics framework -- to prefer local responsibility. The reasons start with the question, "why do I have a responsibility towards the Other[1]?" Some philosophers (like Levinas[2], I think), take a very total approach. Others may say that the responsibility stems from relationship and mutual influence (my wellbeing is affected by the Other, and the Other's is affected by mine). If you prefer the second approach, it is clear that you have greater responsibility towards those whose lives are more affected by yours and vice-versa, and as mutual effects can travel through the economy or legislation (you both vote for the same government), and those are local, it stands to reason that the measure of responsibility grows with locality. Other ethical frameworks may agree with this notion of locality in principle, but say that locality only takes precedence when the needs are the same (of the local and remote), but if the remote person/community has greater needs, then that takes precedence over locality.
All of these can make sense, and different people can subscribe to different ethical frameworks. But each of them has to be consistent, or at least have good reasons for breaking the consistency in some circumstances.
Your idea makes a certain kind of sense, but it's not going to lead to anything except even more inequality than we started with.
http://www.maxroser.com/economic-world-history-in-one-chart/ http://ourworldindata.org/data/growth-and-distribution-of-pr...
That's got me thinking, what about the social responsibility of southeast Asians towards Americans who have been denied for decades the opportunity to own property and live in southeast Asian countries?
Every country has it's own laws about who can settle and work and under what conditions. America does it and so do 'Southeast Asian' countries and everywhere in-between.
Thailand decides who can own property (or work) there. It's neither racist (as you seem to imply - but perhaps you mean only when it's America?) nor is it evil.
Guess, I'll just need to suck it up and go without that great beach house in Thailand.
I don't know the Thailand govt well, but India has similar laws and is explicitly racist about them.
Regarding social responsibility, this is simply my opinion, but companies that wish to employ the full legal and financial protection of the United States and operate within its infrastructure bear some social and moral responsibility to contribute back into the system. Offshoring the bulk of a company's workforce or moving profits overseas to evade taxes and other things of this nature should disqualify any company from receiving the protections and benefits provided by the US, full stop.
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.
It's important to take special care to get those people on board.
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.
AKA Everything You Need To Know To Manipulate People.
You are replacing something they wrote. That in a way is saying what they wrote is obsolete.
Ask yourself why are you and other new members are working on this project; for your own advancement or for the good of the company. If the reason is the former, there's going to be a big ego-clash.
Look for win-win: * The original team wrote the system and have learned valuable lessons from it over time. Ask them if they could write it now using current tools, how would they improve. Sell them the vision that the success of the project depends on their knowledge, and they can learn new tools, language, patterns, from the new members. * The newer members can bring new ideas (backend, UI, etc). Sell them the vision that the success of the project depends on the new skill set that they bring.
Since you cannot change the original team composition, balance it by choosing the new team carefully, e.g., choose people who are goal-driven, and result-oriented; they care more about getting things done then throwing their weight around.
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.)
The problem is the people who make the decisions are rarely the people who pay the price for bad decisions. I've worked with many vendors who promise integration will be straightforward and that their software is easy to extend to handle the last 10% of our business flow that it doesn't currently cover.
In truth its usually a huge pain and time sink and it's the developers (on both sides) who end up working crazy stressful hours to get the project finished.
How can you expect the developers to go the extra mile and fix your dumbass decisions when you didn't listen to them in the first place?
Sometimes everyone has to pull on the same side of the rope.
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.
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...
If above is not enough to get an agreement, let the two people work it out on their own with a limit on how much time they can spend on it (and really limit this time). No need to have an entire team listen in or extend an existing meeting for ages (meetings should be brief).
Aside from that, sometimes you just need to do. So something like "it's not a perfect decision, but what you're saying is known and now it is time to do".
I'm from the Netherlands btw, though 50% of my colleagues are foreign.
It's when they covertly run counter to that that the real trouble starts.
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.
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.
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.
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.
Is there aught we hold in common with the greedy parasite,
Who would lash us into serfdom and would crush us with his might?
Is there anything left to us but to organize and fight?
[0]
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).
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.