Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This is happening in every team.

For some reasons, conflicts arise in the team and they affect the overall motivation and productivity.

What is your recommended approach to solve that common problem?


  • one part of the team wants to implement dependency injection, the other part think it's a waste of time.
  • some developers think the rest of the team is slowing down development (which explains why they are late on the schedule)
  • personal incompatibilities between one or more developers
  • one developer refuse to talk to another one (without apparent reason)

locked by World Engineer Jul 18 '13 at 20:29

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

closed as primarily opinion-based by gnat, MichaelT, Bryan Oakley, Tulains Córdova, GlenH7 Jul 18 '13 at 20:24

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Could be a useful question, but I think you might want to update it to make it more developer-centric - seems generic/managerial at the moment? – Peter Boughton Nov 18 '10 at 16:01
I think the question is fine as it stands. The difference is that if a question had no relations to programmers we could object, whereas if a question relates to programmers but can also relate to other things, I don't see an issue. Many things in programming that are acceptable on this site can also be applied to many other topics and areas. – Jasarien Nov 18 '10 at 16:04
there are many types of conflicts, each has it's own way to be handled. Can you be more specific. – Geek Nov 18 '10 at 16:05
@David - The criterion for the site itself is questions related to programming. Nowhere does it it say they can't be related to anything else. If you swap out the term developer, then you're asking a different question, just because the answers are similar doesn't make it the same question. What is 3 + 3? 6. How many legs does an insect have? 6. The two questions are completely different, yet the answers are the same. Developers can be completely socially different to, say, members of an emergency service team. Both will have conflicts, both will have different ways to solve the conflicts. – Jasarien Nov 18 '10 at 16:59
@Pierre: Do you prefer that this question be closed now without notice, comment or chance to get a better place? This question is about any office jobs. – bigown Dec 10 '10 at 23:42
up vote 26 down vote accepted

I have had a team of 10 people for two years without a conflict(touch wood) I could be lucky or may be doing something right. The best way to handle conflict is never to let one exist for a longer time. There are several core values that you can preach.

  1. Team Spirit
  2. Fairness in everything (compensation/rewards)
  3. Being appreciative
  4. Give recognition, responsibility
  5. Give freedom
  6. Let people know they are not greater than the team
  7. Personal success means nothing if the team fails
  8. attach personally to people
  9. never show a carrot you dont intend to give
  10. never hire(no matter how good) who could ruin the team
  11. communicate more often etc etc.
  12. Appreciate whenever someone goes beyond the job
  13. Give regular feedback on performance and set expectations preferrably monthly.
  14. Let people know when they behave like children.

All these take guarded effort from some one.

Software is pretty much a team game individual brilliance is generally short lived. If I go by your examples :

  1. We have decided decided to go with dependency injection. Period. We will see if it is the best way or not. If it is not, you get a chocolate :-) till than cooperate and let's make this thing happen
  2. If the rest of the team is slowing you down you help them to make it faster they are your teammates you are the elder guy, help them. I know you are good.
  3. Talk to both of them tell them they are spoiling the environment. If nothing works get rid of one of them or both of them.

One thing I find very effective is to repeat "we are a good team" and repeat "we are a team to the lonely one's".

I'd give you 1000 upvotes. Team conflicts are the manager's responsibilty. Never been on a team with a lot of conflict that didn't have a poor manager. As you said, the best way is to make sure the conflict doesn't exist for long. Too many managers are afraid to upset people by resolving conflict. As a result they upset more people for longer and affect productivity more. When it is clear that you will treat people with respect and that you will not tolerate anyone not treating others on the team with respect as well, much of the conflict goes away. You seem like a good person to work for. – HLGEM Nov 18 '10 at 18:39
+1 for a good informative answer – Gary Rowe Nov 18 '10 at 22:56
+1 Very good answer! However as a manager you have to have it in back of your head that there is no perfect team, and that there are always a degree of conflict. That’s human nature! – Amir Rezaei Nov 19 '10 at 10:01
"Fairness in everything (compensation/rewards)" How can you possibly do this without disclosing? – Den Jul 18 '13 at 13:15

It depends on the conflict obviously; they come in multiple flavors.

  • The religious argument ("Why do you keep using tabs instead of spaces?!?")

The point to make clear in this case is that, in principle, it doesn't matter which one is right, it's actually far more important that the entire team is using the same approach. Explain that to the minority opinion holder (and make sure to highlight that it's not necessarily the right decision, but also not important enough to draw blood over). The degenerate case of this is, for example, a developer refusing to use source control or submit to code-review. That's a management issue, and I honestly wouldn't know how to resolve it without letting the rogue developer go.

  • The personal argument ("I just don't like you")

There really isn't a way to mitigate this. Make it clear to both of them that bickering isn't acceptable, and that their personal grudges need to be checked at the door if they're going to be productive members of the same team (this works whether you're the manager or not; peers can be surprisingly influential if they're sure enough of themselves). If that doesn't work, either try to split them up on the org chart to reduce their professional/physical proximity, or get youself a desk well away from them.

  • The technical argument

The key difference between this and the other conflict types is that there is likely a correct answer. Typically it's to do with the code one or the other developer owns and how it should work (occasionally, it's a larger architectural argument). The key thing to grasp here is that even though there's a correct answer, you probably don't know it. The best thing you can do is mediate to make sure it's a clean argument, and hope that either side can be convinced. Again, you can do this whether they report to you or not, but if you're a peer, they might go to a manager to re-run the play even if you manage to bring them to a conclusion.


Have a third-party unbiased mediator sit down with both conflicted parties and have them talk it out.

It helps if the mediator is someone the problem-havers are comfortable talking around, but that they still respect and will not talk overtop of


if they can't act maturely sack them both and get a professional, maybe a contractor/someone freelance ?


In my experience most conflicts of this nature come down to personality clashes. Some of them have other elements but most commonly these are just being used as a vehicle for disagreement so even if you resolve the issue that they're arguing about, it's just a matter of time before something else comes up.

My advice:

1) The first thing is to make it clear to both of them that conflicts reflect badly on both of them and that there isn't going to be a winner and a loser, just two losers of varying degrees.

2) Make it clear to them that whatever happens you expect both of them to act in a professional manner. They don't need to like each other but they do have to be civil, efficient and organised. Make sure that it's reflected in their annual appraisals and reviews - inability to get on with a team mate is a significant issue with their performance.

3) Do listen to their issues with one another and where appropriate be sympathetic but also point out their failings in this area and avoid getting drawn into extended discussions or some judgement about who is right and who is wrong. As I said above in 95% of cases (the remaining 5% being genuine bullying or the like which needs to be properly addressed as a disciplinary matter), they've both wrong and they need to understand that.

4) Where possible do keep them apart where it's easy to do so. I don't generally find that throwing people together does anything more than stir it up. If they're going to "reconcile" it will happen anyway and I suspect is more likely to happen when they're not continually in each others faces.


You should have them battle it out in a "tech off" each side gets a box of parts--a disassembled computer, he who gets the machine built and booting first wins.

if that doesn't work for you, you should try a machete fight, or even a chainsaw fight.

Chainsaw. Every software engineer has played DOOM, so we're all experts with chainsaw. FIND SOME MEAT. – Adam Crossland Nov 18 '10 at 16:12
@Adam Crossland ROFL – Muad'Dib Nov 18 '10 at 18:02

TKI identifies a handful of different techniques for resolving conflicts that may be an idea for how to resolve some issues. There are some legitimate issues such as using a framework or not, though this may be handled either by a team voting on something as one way to resolve it or by going to higher power like a manager of some kind. Some times there can be disputes in interpreting requirements which are best handled by going to a project manager or business analyst to get a specific ruling,e.g. does a blank search return nothing as nothing was entered or does it return everything as the wild card matching used says everything has nothing in it.

If it is more personality conflicts then the question becomes how well does each know of the issue and what will be done if this persists. This isn't so much an idle threat as much as a, "If you guys can't work this out, I'll work it out by removing at least one of you," mentality. Course this does carry the potential for passive-aggressive behavior and other childish crap but this is what happens when bright resourceful people enter a way that doesn't use traditional weapons to resolve hostility. "Mean Girls" has several examples of this kind of behavior, just to give a reference of sorts.


I don't think I'd be able to stand the babysitting aspect of management. I'd tell them to settle it with a duel to the death.

Sorry -1 for this answer :-) – Geek Nov 18 '10 at 17:33
dueling is good, as long as it involves machetes or chainsaws :) – Muad'Dib Nov 18 '10 at 22:37
+1 for understanding that there are days when it can feel like baby sitting. – Jon Hopkins Nov 19 '10 at 9:39

I've found a "team Contract" usefull.

It has to be colaboratively developed by the team members them selves, if it comes down from on high it won't work.

Although, it's a little late if the team is already fighting.