How to get two strongly opinionated colleagues to work together?

Question

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!

Answer 1

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.

Answer 2

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.