I am the owner of a small coding project. I have 3 members and I have a major problem. My two head programmers are having major disagreements. So far one of them has threatened to quit, and I can't fire the other one as I need both of them. I have no idea what to do and I need help! Does anyone have advice on how to solve this problem? Thanks in advance!

  • What does "I have 3 members" mean? You own the company, have 3 employees, and 2 are "head programmers"? Are you a programmer as well? Do you use contract programmers? Feb 2, 2017 at 15:34
  • Yes, I have 3 employees and by "head programmers" I mean they do most of the programming. Yes, I do some programming but not the bulk. No I do not use contract programmers. Feb 2, 2017 at 15:35
  • 10
    Might be time to hire an adult.
    – Snowlockk
    Feb 2, 2017 at 16:07
  • 3
    If they work for you, it's time for YOU to make a decision - take it out of their hands. Ask both of them to write a proposal on the main issues at hand (one issue, one proposal from each person). Then research their results, find out the industry standard (which may not be in either of their proposals), and then TELL them what's going to happen. If one of them decides to quit, that's their decision and you can't affect it - don't give in to blackmail.
    – PeteCon
    Feb 2, 2017 at 18:17
  • 5
    Having a single strong leader whose vision the others are there to implement is far better than having several leaders and no workers... Either you run things or you pick one of them to run things. Quite frankly, I'd go ahead and fire the one that threatened to quit - your company is too small to be dealing with multiple prima donnas.
    – NotMe
    Feb 2, 2017 at 18:18

2 Answers 2


Quick Fix

I had a couple of programmers in this situation once. I took them outside & the three of us went for a long walk around the parking lot. I don't remember how many laps we took but we were out there for a long time.

I made them talk out the issues - what behaviors each was doing that bugged the other, what beliefs (technical only!) they disagreed about, etc.

My role was to act as a referee / arbiter. I didn't choose a winner or loser, but I held them accountable for finding a working compromise.

Longer term fix

First of all, remember that you are the only head programmer. Being a boss isn't easy, and all too often people jump into it without training. Try to find a class (community ed, SCORE, etc.) You took classes to learn to program, so why not take classes to learn to be a boss?

Giving your two devs the fancy title of "head programmer" set them up for conflict. When (not if) they leave, don't use that title until you really mean it (i.e., the single head programmer will be leading a team of 5 or 10 other programmers).

Consider the bus factor - as the head programmer, you should always ask yourself what you'd do if one of your programmers left. "Shut down the company" is probably not the answer you want.

Since you probably don't want to hire a 3rd programmer, make sure the 2 you have are sufficiently cross training and documenting their work. You should have a reasonably good understanding of the entire application - where the source code is, how to compile it, how to find certain functions and features, etc.

One final thought: the title of your question asks about colleagues, but these two are not "colleagues", they are "employees". There's a big difference and you need to hold them accountable to it.

  • 1
    @JoeStrazzere - You're right. I was thinking in terms of their relationship with the OP, not with each other. Feb 2, 2017 at 17:23
  • 1
    "Being a boss isn't easy, and all too often people jump into it without training." Or are thrust into it when they may not want it and/or know they aren't ready, with a "Sink or swim" dictum from upper management.
    – GreenMatt
    Feb 2, 2017 at 20:27

I recall at a conference learning a framework where you started examining the conflict by looking at what the colleagues are trying to achieve, work further up to find why they want to do this and what the goals are, and carry on up as eventually there will be a common goal.

Common goals may be "developing the best software", "making maintainable code", "making a great user experience", "making a product we can sell", "making a product we can be proud of". Somewhere there is a motivation, and then once this can be found, working back down from there to then consider the solutions as ways to achieve this makes more sense.

I have effectively used this in a workplace to get over major disagreements with other motivated colleagues, and found that we were both passionate about doing the right thing, about making a project/system that both delivered and was sustainable, and therefore gained the respect for each other to give more time to consider each others view. It's not that we agree on everything, but that we take more time to consider each others views and use that to feed a more considered solution.

This may require a certain amount of maturity from both colleagues to get here - but they are head programmers - so this isn't an unreasonable expectation.

Beware - this can also uncover a can of worms if a particular individual is not motivated to benefit the team, department, product or company.

You must log in to answer this question.

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