At my work I have two colleagues with very strong opinions on how something must be done (software), and their opinions are very different. One is very actively aggressive in his communication, the other is more passive aggressive. They don't get along and don't want to work together.

As as result, they tend to make their own solutions that are 'wrong' in the others' eyes, so the result is that code ends up being one style or the other which complicates re-use.

Now I ended up in a situation where I need something generic do be done in both their projects. I would prefer to end up with one generic solution instead of two.

How should I approach this? I could ask one of them to write up a solution and ignore the other, but I would like to get something that they both support.

  • Welcome to the site RobAu. I've edited your question so the title more closely matches your situation. That said, what is your actual question? We can't really offer situation-specific advice; we need to know what your goal is.
    – Lilienthal
    Commented Sep 16, 2015 at 9:32
  • @Lilienthal thanks. I changed the last bit of my question. I realize it is a bit generic; I hope there is a generic approach for this kind of situation. Commented Sep 16, 2015 at 9:36
  • 1
    Do all of you share a single manager? If this personality clash is so detrimental to your projects they should be involved in resolving this, if you can't resolve things informally between yourselves.
    – Dustybin80
    Commented Sep 16, 2015 at 9:46
  • 1
    Unfortunately, us three all have different managers. They guy that managers these managers is the some, though. Commented Sep 16, 2015 at 9:48
  • 2
    @Kilisi It is. Robau: the recommended approach to take here is to discuss this with your manager, though I'm guessing you're asking this question because you don't expect that to help much or that you want to work it out yourself. A reasonable manager should be able to at least offer advice in this situation though, even if a real solution is out of his hands.
    – Lilienthal
    Commented Sep 16, 2015 at 10:22

3 Answers 3


Since you don't have authority, you need to go to someone who does. These sorts of issues (how do we do X in both parts of the system so it's consistent and maintainable) typically fall to an architect, not a project manager or leader of people. If you have an architect, go and ask what to do. The architect will be able to make a good choice and enforce it.

Assuming that you don't have an architect on your team, you need to go to the people manager and explain your situation. Do not tell your "people manager" your own diagnosis of the personality types of your coworkers. Simply say that in the past, they've each implemented things differently, and they rarely agree. Explain why you feel it's important they agree in this case. And then ask your manager for something: probably in this case, it's permission to be the architect on this issue and choose a solution they both must implement. Your "people manager" can then direct both of them to understand the situation as it applies to their system, and design an approach to be delivered to you. There can then be a meeting between you, both of them, and the "people manager" in which a choice is made and the "people manager" directs them to implement it.

If you do this well, you may end up the architect. If you let it bog down in pointless arguing with each of them implementing their own incompatible thing, with the result being a permanent pain point and impedance mismatch in the project, it could be a blot on your record at the firm. So make sure this really is your battle to fight before you wade in to force them to be consistent and play nice.

A third option is to go to your manager and use this situation as an example of why you need an architect. There are even freelance architects available who will come in and "whip things into shape" for a while, then be available for quick questions and problem-settling later as required. It's something I do from time to time and I've seen the enormous difference it can make. The majority of managers will reject this option because architects are expensive, but perhaps yours will be willing to consider it.

  • 2
    Kate makes a good point. The source of this problem is that you're trying to build a house by pointing two carpenters at it. Without an architect, it is inevitable that your house will be rickety. I would be willing to bet that the source of the conflict is that one has a long-term architectural vision and the other wants to just hack something in that meets the short-term requirement. Been there, done that, don't even want that tshirt. Commented Sep 16, 2015 at 15:59
  • 1
    @AmyBlankenship you'll win the bet :) Commented Sep 17, 2015 at 7:16
  • Ah, then in that case you also have the option of agitating for the one with the vision to become the architect (if that colleague would be better than you at it) which will meet your needs without catapulting you into a role you're not ready for. Commented Sep 17, 2015 at 10:29
  • Just as a word to the wise, the "other" guy was put in charge of the project I'm on now, then left when he realized there was no path between our codebase and increased requirements without a total rewrite. I have been unpicking that stuff since March and I'm only scratching the surface. Making the "other" guy happy will cost you big time. Commented Sep 17, 2015 at 14:49
  • If it really is a case of one having a long-term vision and the other not, why not start by getting them both to write up a design document describing their long-term vision and indicating why their particular approach to this problem supports that (yet still is reasonable in cost in the short term)? Ideally, have them support this with evidence from the existing code base: how well their previous decisions worked in the long term, where problems arose, and what those problems were.
    – cjs
    Commented Jun 5, 2022 at 11:25

I would call a meeting and discuss what I need and hash it out. Listen politely for a while to both arguments then just tell them what I want. I guess it really depends on the projects. I can usually structure the task requirements to get the desired result. At the end of the day whoever is in charge dictates requirements, not the developer.

I'd rather have them agreeing that I don't know what I'm on about and working together to appease the taskmaster, than for an inefficient situation to continue.

This is assuming you actually have that authority of course.

  • 1
    I don't have authority; I have a clear result I want to achieve. I can get either one to work on it, but the other will probably dislike the solution. I'd prefer a shared solution. I guess you are saying that they should decide who will do it and leave it be? Commented Sep 16, 2015 at 9:51
  • in that case I would choose the better style ie,. the one which is most formal (usually between two programmers one will do everything by the book, the other will take shortcuts and call them optimisation) there is very little you can do without authority.
    – Kilisi
    Commented Sep 16, 2015 at 9:57

Working with different personalities isn’t always easy. You can’t change how someone behaves but you can use some strategies to overcome these issues. Asking one of them to write up a solution and ignoring the other isn’t going to help either in my opinion. You could involve someone from higher up the hierarchy like a “manager” that has some authority. If you want to handle this on your own the following points might help you devise a shared solution.

Step 1. Keep emotions in check. Remind yourself you only need the employee's professional skills so you don't respond to his strong-headed behavior in an emotional way. For example, if he insists there is only one way to complete a project, do not yell at him or behave rudely if he is wrong. Negative behavior on your part will make reaching a compromise more difficult.

Step 2. Write down tasks you need completed in specific words. Deliver the instructions before meeting with the employee to discuss the project. Giving the employee instructions in writing before speaking to him limits prolonged contact and sets clear expectations for both sides.

Step 3. Listen to the employee's ideas objectively. He may insist there is only one "right" way to do something, and while that may not be true, he might have valid points in his argument. Go over his points and calmly explain what you agree with and what you don't. Give solid reasons for your position so he does not feel ignored.

Step 4. Talk to stubborn employees in private and in person if a problem arises. Do not use telephone or email, as both are impersonal and less private, and he may misunderstand.

Step 5. State points once. Repeating yourself is likely to make you emotional, and a strong-willed employee is unlikely to listen no matter how many times you say the same thing.

(Source of above points)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .