As a technical lead, how can I resolve conflicts between two junior engineers?

Question

I have recently joined a team as a technical lead. It's a 4 member team that includes two junior developers, myself and my manager. I am on good terms with the manager. However, this is the first time I am working with the two junior engineers. I have about 9 years of experience developing software in the software industry. The two junior engineers have less than 1 year of experience each. The manager is twice as experienced as I am.

There has been a history of conflicts between the junior developers even before I joined the team. Some of the tasks assigned to me are for example to ensure that the project is executed successfully, review all technical aspects of the project, set clear boundaries between the two developers so that they don't step on each others' toes, and ensure that they don't get into any more conflicts.

Here is an example of a current conflict I am dealing with.

• Dev 1 implemented a solution to a problem, used Library A and wrote the code. Dev 2 implemented the same solution, but used Library B and wrote different code for it. Both pieces of code co-exist in the code base now. But Dev 1 wants to gradually take ownership of this solution and gradually convert Dev 2's code such that Library B can be gotten rid of and the entire solutio can be written with Library A only.
• Dev 2 has expressed earlier already that he does not like Dev 1's approach of removing code written by Dev 2.
• But Dev 1 also has some valid reasons to support his behaviour, e.g. there was no need for Dev 2 to introduce Library B (which was redundant when Library A was already being used), uniformity in coding, code clarity, minor performance improvements, etc.
• Personally, I don't care whether Library A is chosen or Library B. The pros and cons for either are minor and don't affect the larger objective of completing the project successfully. One can't go wrong by choosing either library and discarding the other.

Most of these conflicts began before I joined the team but now that I am here, I want to minimize conflicts between them and resolve them amicably.

Some of you might think that should be the manager's job and not mine, and the manager should have dealt with this already but that's not the situation I am in. I have to and I want to take responsibility and resolve this conflict. I want to face this issue head on because it would help me to grow as a leader which I think is a very important skill along with software engineering.

How can I resolve and avoid these conflicts going forward?

Answer 1

The real problem here is that it was allowed to get to the point where both pieces of code were ready to implement with out figuring out the library conflict existed. The choice of which 3rd party library to use should have been decided before any coding involving it began. If your company does not already have a standard of which library to use then you or your manager should have been the one to make the decision if they could not, and even if they did you should have made sure it was the correct choice. That is the usual role of the lead.

In this case Dev2 caused this problem by introducing a new library when there was already a library in the solution that would have solved the problem. I would be sorely tempted to direct Dev1 to fix Dev2's code and remove library B from the solution entirely. And then counsel Dev2 on adding third party libraries to the solution without permission. Then find something for Dev2 to work on that will not overlap with Dev1's work.

However you are presented with an opportunity for team building. Were this my problem to deal with, and assuming there is not already a company standard, I would have the juniors sit down together and determine which library the project is going to use going forward. Give them a reasonable but limited amount of time to make the decision, and if they fail then they will each be responsible for rewriting the others code with out the benefit of any library.

Ideally this should force the 2 developers to try to work together instead of against each other. And if they fail to come to a solution then working with each others solutions to implement them with out the library will give them another chance. They are going to need to talk and ask questions and work together to get them together and integrated. Then you go through the code with your red pen and mark it up with where things need to be optimized or refactored etc, Make them pair program those solutions.

What you should have done originally and should do going forward:

You need to have daily scrums with your juniors so that you all understand what each other is working on and address any conflicts in their work before they get to the point where the conflict is causing problems. You were tasked with avoiding the conflicts and that is what you need to do. You need to try to foresee potential pitfalls and problems and navigate your team around them. I would also start doing regular code reviews. I would do them without the person who's code your are reviewing being there and then you be the one that communicates what needs changed to that person.

I would also consider trying some team building activities where you can pair them up together and set them up to succeed. One thing you might consider is get them to work together on establishing coding standards for your group if they do not exist already.

Answer 2

Personally, I don't care whether Library A is chosen or Library B.

Professionally, you need to care. When you are in a lead role, it is your job to make decisions. In this case, a second library should never have been introduced unless removing the first library was also included as part of that work. That should be clear going forward.

One can't go wrong by choosing either library and discarding the other.

But one can and will go wrong by keeping both. Make a decision, come up with a plan to fix it. Make it clear that it's unacceptable to have duplicate solutions/libraries/methods/classes/etc. You add code and libraries to solve known problems, otherwise use what you already have. More code = more complexity = more problems. Keep it simple.

In the future if a debate comes up, time box it. Allow some discussion to hear opposing views, decide and move on. Time is your enemy, indecision is it's friend. A non-optimal decision is still usually much better than no decision.

Last, In a sense, you need to treat them like children and give them "turns" or whatever. Just like kids don't always like their parents, your devs may not like your decisions. Pay attention to how often each one "gets their way" to keep things "even". If they argue or can't get along, send them to "time out" by setting the argument aside and telling them to spend a few days "thinking about it" while doing tech debt, grunt work, etc.

Jr devs can learn to be professional by your example. Treating them with respect, but as your junior will help you get results. Don't be concerned with avoiding mistakes. Focus on responding to current issues and problems.

Answer 3

If the two libraries are technically matched, then find out which one seems to be supported better, and eliminate the other. That's good business.

If nothing else, flip a coin, and choose one. Somebody's implementation will stay, and someone's will go. All and all, you can't be afraid to be the bad guy.

Answer 4

Some of you might think that should be the manager's job and not mine, and the manager should have dealt with this already but that's not the situation I am in. I have to and I want to take responsibility and resolve this conflict.

This is a good responsibility to take up and prove that you have managerial skills apart from technical ones. Just be careful not to rub people the wrong way, or to lose your technical skills in the process.

Some of the tasks assigned to me is to ensure that the project is executed successfully, review all technical aspects of the project, set clear boundaries between the two developers so that they don't step on each others' toes, and ensure that they don't get into any more conflicts.

There are many ways to approach such a situation. A lot of this depends on your personality. The general strategy I would employ would be give subtle, verbal and non-verbal signals that fighting is not appreciated among the team. This would include letting the people concerned know that it would impact their appraisal negatively -again hints rather than threats.
You should be able to carry this off for it to not backfire.

Most of these conflicts began before I joined the team but now that I am here, I want to minimize conflicts between them and resolve them amicably.

One way to look at these conflicts is to pretend (takes time and effort) that they are merely technical problems rather than the personal, ego-based issues that they are. Assuming you have the time or can take some out, call get everyone's inputs, and tell them you will take a decision based on the respective merits of the library.

Option A:
If having two libraries is not a maintenance issue (the code does not give you too much trouble) simply let both lie and tell both people concerned there are many more important things to do - discuss pending Quadrant II deadlines here. Get them involved in those.

Option B:
Let both people that you are looking at cross-domain skills, and you will decide on a library - but the person who has earlier worked on the library will not be the one doing the implementation, the other person will. This is slightly nasty, but should tempers cooled down pretty fast.

For the long run, create the impression that you do not want to discuss specifics, are not interested in personal arguments - but do want to help the person grow as a whole. They will eventually stop complaining.

In general, never literally get into a fight between two subordinates and take sides - as in when it is actually happening.

Answer 5

Make it collaborative with a mandate to achieve.

Sit down with both developers at the same time (or in your daily standup/scrum meeting). Iterate to both that the team should only have a single implementation of the code. Enumerate the benefits: less duplicated code, easier to maintain, smaller working set, etc... Iterate any additional requirements (e.g. must use only 1 mb of memory, run at 60fps, or can be re-used for an upcoming feature). If there's any pushback on the requirements, remind both that the team will be maintaining the codebase for many years that now is the best time to avoid future maintenance headaches. There really shouldn't be any argument against this.

Now ask them both the best way to get there.

Either one of three things will happen during this brainstorming session:

1. They'll both agree with a solution. In which case, your job is done. Dispatch one (or both of them) to get the right solution checked in.

2. One will present a compelling solution to have a single code base while the other is just stewing and being defensive about not deleting his work. In which case, the answer is "sorry Bob, we need to go with Allen's unified approach". Redirect the developer who's upset about this to work on the next feature. He'll get over it.

3. They both present reasonable, but different solutions. In which, you have to make a decision. Afterall, you have more experience than both of these guys combined and could probably write a better version yourself. So if your team can't decide, you must decide for them for them and then direct each on what to do next.

Welcome to being a project lead.

Answer 6

Find an objective pros and cons of each solution and then decide which is to stay.

Things like which piece of code is shorter, cleaner and/or more usable in future, which just does jobs better. If both are equal then leave one that was written first.

Also make your decision final and in future don't allow such situation, where two persons write same piece of code, to occur.

But I think you have much greater issue with those two fighting eachother and that's something to solve quickly.