How to negotiate with a stubborn coworker?

Question

I work in small team of 8 developers and we do not have direct management because of our small numbers. We are more or less self managed.

We make heavy use of version management, IDEs and all sorts of conventionally popular and well known tools and platforms. For example, we use VS Code and git for everything. This allowed us to compromise between Windows, Apple and Linux users, and almost everyone is happy.

However, we have one member who ostensibly refuses to use same tools as everyone else. He uses command line editors, cmake (manually writes scripts), perl, and some other obscure and outdated tools. He also does not follow the team coding style.

This was not problem until lately because he had separate workflow. He mostly maintained some java code and worked independently. But after a COVID related layoff, there is way more work on our shoulders and having stubborn teammate really takes toll on our productivity and efficiency. Now that we inherited pretty big C# and managed C++ code bases, having proper IDE is more important than ever. Everyone who didn't use windows dual booted it or uses our preset VM snapshot. But our teammate refuses to use windows, claiming that it is spyware. We tried to negotiate with him. One of my coworkers even offered to lend him his laptop which is set up for task, but he refused to take it. We went to upper management but they can't do anything to him because he maintains some important codebase unrelated to our team. But they can't remove him from our team either because he must fill work hour quota specified in contract.

Edit: We already missed several deadlines because of him and he's constantly lagging behind. We are unable to help him because he uses tools unfamiliar or less familiar to us. We once had a urgent need to fix back-end code he had worked on while he was taking a day off. We had about 3 hours at most, so we called him and he told us password of work laptop. It did not boot properly. After a lot of confusion, it turned out that he didn't have desktop environment or something along that lines. We found ourselves in a very ugly situation afterwards. There was some solid damage to company, our team will be disciplined, and, god forbid, we may even be sued. None of this would happen if he used the same tools as others.

How to approach this person and reasonably negotiate with him?

Answer 1

You'll have the most luck persuading your co-worker to recognize their contributions to the collective problem, when you start by recognizing your own.

Case in point:

having proper IDE is more relevant than ever

That would actually be a severe misunderstanding of the basic norms of sanity in modern software development.

Modern projects utterly rely on the ability to have an automated build server which uses command-line type script tooling (itself maintained under version control) to automatically perform builds. Even if no testing of the build result is done (as it really should be), simply verifying that the build can still be done after the latest round of changes is key. In a sanely run project, the IDE is never the official build method, only a shortcut developers use to make initial builds for debugging - releases and their candidates always come from the build server.

If your project is properly configured such that it can be built by a build server (and it sounds like your co-worker's personal build tooling is precisely what would be needed for that), then no, it doesn't matter one bit what your co-worker uses to edit the code.

Once you followed your co-worker's lead in using sound build tooling which makes the IDE dispute irrelevant, you can concentrate instead on finding a compromise resolution in areas which actually do matter, for example:

• Uniform code formatting, because it reduces commit noise. But you should have tooling which can do or check this outside of your personally preferred IDE, because such check should be part of your automated validation flow

• Standards for code style and organization - you've rightly expressed concern here, but that's a subject for guidelines and reviews, not an IDE feature. And it's not an axiomatic given that your preferences are technically best.

• Selected languages - if your project wants python instead of perl, that's as much a political decision as a technical one, but unlike the IDE dispute, commonality actually matters and is worth debating to an agreeable and technically sound group decision.

So, separate your preferences from your needs, review the degree to which your own expectations are out of step with industry norms and then pick your battles accordingly. If code doesn't meet standards, it fails review. If perl isn't an allowed project language, a commit that adds some fails review, etc.

When the asker has separated out and and ceased insisting on getting their way in the areas where they are actually the one creating the "problem", and is left with only the actual problems created by their co-worker, they'll be in a much better position to obtain actual change in those remaining areas, and can point to the previous requests which they have now dropped as evidence of a willingness to find a technically sound compromise.

Answer 2

How to approach this man and reasonably negotiate with him ?

You cannot do more than you have done already. This is a management problem. They just don't want to deal with it. So the best thing to do is take it back to them but with the solution that he works on something in particular that doesn't disrupt the team.

Answer 3

Pulling together some themes here:

• Lack of proper management
• Some division to the team as to effective practices
• An implication that the "stubborn" colleague might have available time
• This person is more comfortable with command line than the rest of the team
• A need to access an individual's machine on order to resolve a problem

As indicated by @chris-stratton and others, there should be an independent build server.

Let me make this really clear: such a thing is not just an element of a modern development environment, it is part of the bedrock.

I am old enough to have worked prior to that being considered mandatory and I assure you it is the one biggest improvement to productivity you can make.

Solution: Ask the "stubborn" person to automate the build and test pipeline, including provision of documentation, automation and configuration of developer environments to ensure common builds.

This builds on the specific skills this person has and gives all of you a win.

Edit: As per the comment by @Móż, do not interpret this approach to mean putting this person in a silo. The whole team should be across the build system, with someone assigned initially to partner and be across it. The OP might well consider that it be themselves so as to build their own technical and team working skills.

Additionally: Effective self managed development teams require strong internal and personal discipline. They take on modern software development practices and constantly strive to improve them. Excellence requires need humility and inclusiveness, and to build on the strengths each team member brings. Does the team spend time ensuring this is true?

Answer 4

This has nothing to do with age but everything to do with refusing to work in a team.

Talk to your management, explain the problem, and tell them that you need a developer willing to work in your team, and that if your manager can’t talk sense into him, then you’ll have to let him go and let him find a position that wants him, and replace him with someone who can work in your team.

PS. If I had posted this question I would have written “I have a problem with a younger colleague...”. Same outcome. If he refuses to do his job, get rid of him.

PPS. There should be nothing private on my work computer, so if Windows is indeed spyware, that’s the company’s problem, not mine.

Answer 5

This answer will include the edit the OP posted.

Let's identify the problems here (as you outline them):

• This dev uses tools he likes
• He does not follow coding style
• He's lagging behind and your team missed deadlines because of it
• His work laptop/PC couldn't be efficiently used by another team member

So, we have 1 non-issue, 2 "sort-of" issues and 1 critical issue.

As for the non-issue, it's about the tools he chooses to use. Unfortunately for you, he's the #1 domain expert on what tools make his work the most efficient - for all you know, making him use VSCode or something would make him work 2 times slower. There's nothing to do here, because that's not a problem.

Let's jump to the 2 issues I outlined with italics.

As for the coding style, it's up to the team (lead) to enforce such standards. You (as in team, not you personally, although nothing stops YOU from being the one to suggest it) should implement standards and enforce adherence to them. Reject pulls until code is of set standard or automate it. This is a decision that should be taken BEFORE any actual work happens (don't start enforcing it 3 days into a random sprint 2 weeks before the product ships - spend a day before the next project and do it then). If it's already in place, then it's a matter of your team lead/technical lead to make sure he follows them.

The situation with his work machine - why were you even logging into his machine? Why his code isn't committed to repo, or at least to some staging/Dev build? You shouldn't ever have to log onto someone else account to get the resources, that's the whole idea. Again, this is a "process" fault and your lead should be responsible to get him to check everything in (especially if he goes away for some days).

If this is a case of "only he knows how this whole thing works", it escalates to a critical issue, because you have a bus factor of 1, and should take steps immediately to remedy it. At least one other person should have knowledge of how to set up/work/expand whatever he's working on. You PM or Team lead should set up a training session after the project is finished for him to pass the required knowledge onto person/s of his choosing.

Now let's focus on the big one.

You are missing deadlines and you tell us it's because of his work. It doesn't matter if it's because he insists on coding in notepad, he takes 50 minute breaks for 10 minutes worked or he just lacks the skills required. This is his concern, not yours. Your only concern is missing deadlines:

Is the team and team managers aware of it? They should be, you should point out "I finished A and B, work on C is halted because I'm waiting for D from Bob. I will do E in the meantime." during whatever project communication happens within your team. If it doesn't then here's another issue for you to solve - you cannot wake up on the last day of project and find out Bob is 40% done.

If the management is not aware of it, then they rightly blame the team as a whole for this issue. It should never reach the stage of "Bob is away and he didn't finish this task and also we have no idea what he's working on".

In conclusion

1. Leave his personal choices regarding work environment alone, that's not your concern
2. Set real coding standards in place, and if they are there, start enforcing them seriously
3. Stop having "this one guy who is the only one who knows how to work thin thing". Make him pass required knowledge.
4. Never log onto someone else's machine, you should have access to all his work without it. Enforce regular commits and set a Dev environment if you don't have one.
5. Either start highlighting your problems during the actual project, before it's too late or if you already do so, it's up to your management to take action on it In short, your guy should have a talk with whatever higher-up he answers to and be told to step-up or ship-out.

The truth is, nearly everything is out of your hands as a non management person. From your side, just keep highlighting blocking behaviors and stick to the guidelines set by your company/team lead. This problem is your superiors to fix, not yours, provided that you supply them with relevant information.

Answer 6

It should also be noted that a successful part of negotiating is not just trying to change him, but trying to come to a mutually beneficial agreement. Was he part of the discussion when everybody decided what tools to use? If not, maybe have that discussion again in a productive way. Let people (especially him) talk about tools they would like to use and make decisions from there again. You might be surprised to find that some of the tools he uses are in fact useful and that's why he's invaluable when working on the other project.

In a lot of software companies, developers can use whatever tools they need to get the job done. Him refusing to run Windows shouldn't single-handedly cause your team to not deliver projects on time. However, here's some ideas of how to make sure he can contribute to the code base effectively.

• If he's not following style guides, use an automatic code formatter so that everyone can easily conform to the style.
• If he's pushing errors that break the codebase, make a successful build a part of being able to merge changes.
• If he's not able to contribute code to your projects, let your manager know. Unfortunately, that's all you can do if that circumstance.
• DON'T LET HIM WORK ON CRITICAL PROJECTS WHEN HE'S ON HIS DAY OFF that was clearly setting your team up for failure.

I would also disagree that CMake is an outdated tool used just for scripting. It's actually become pretty much standard almost everywhere that uses C++. C# development can be done in Linux and there are many wonderful tools that help that happen.

Answer 7

If you have explored every avenue with the person and they refuse to cooperate (and you have asked that person to come up with a mutually satisfactory compromise), I would ask for an open meeting between the full team and management. Tell the person that you are going to do this. If management refuse such a meeting and refuse to take responsibility, I would go higher up. This has risks but so does your current situation. Sacking or disciplining the whole team is going to be far more disruptive to the managers than tackling the "bad apple". I personally would find a way of saying this non-confrontationally in the meeting.

Answer 8

I am that stubborn co-worker, in a completely different environment (not software development), so maybe a different perspective will help you:

First, I don't use my personal choice of tools in order to make trouble for others, I use it because it works best for me, because I work more efficiently using it, and because work pressures don't allow me to be inefficient. Don't break my toolchain if you're not paying for the days or weeks it'll take me to adapt to something else.

Which means, there's a need that he satisfies by working the way he does. Not a "want" or "like", but a "must". Especially if there is performance pressure.

Second, while I'm a team player, I am not a team mascot. I think I'm right, and I can afford to walk away if you too aggressively tell me that I'm not. There is a limit of bending I'm ready to do, to adapt to corporate policies and team standards. Beyond that, thank you for playing, but I'll be taking my ball somewhere I like the rules better.

Which means that you should not overestimate the amount of pressure and control you have. Management already told you clearly that he is untouchable. Take a hint. I've been in that position and I've seen the fear in middle managers' eyes who tried to fuck with me and then realized that I'm not even talking to their boss, I'm talking to their bosses boss.

Third, the one thing I'm tired off after a good and interesting career is office politics. I care about solutions. I care about my projects. I don't care about your standards, policies, rules and other silly power games. I have not once in my career caved in to someone trying to push me. I have left companies, I have gone over the head of managers, and at least one person on paper above me has lost their job because of me.

Which means you won't get this person on policies, rules or "this is how we do it here". If I were him and you told me that, I'd tell you that that's all very interesting, but I don't and what are you going to do about it? No, if you want him to change anything, you need to engage in a discussion about the technical merits. In a real discussion, were you are ready to be convinced that actually he is right and you are wrong.

Fourth, the only things that get me moving are necessity and intrinsic motivation. I work even on days I don't feel like it because I need to eat and my family gets cranky too if there's no food. But I work good when I work on something that's interesting, or challenging, or rewarding. No one has ever motivated me with money, or threats - but smart managers have given me interesting tasks nobody else could manage and reaped the rewards of having them completed in half the time they estimated.

Which means you need to understand where the guy is coming from and what he wants. Right now you see him as a difficult obstacle to overcome, someone who causes you trouble. I'm sure some of my managers have seen me that way. Take a better look at how he works and try to understand why. Maybe he is right, at least in some of the things? Maybe it works for him that way. Maybe he doesn't need to use your IDE in order to contribute code? (it's not like the compiler cares).

Once you see the guy not as a difficulty, but as a person, you can negotiate a solution with him, that takes his needs into account as well as yours. You may even find a solution that benefits everyone. Maybe something he does is really good and you can all adapt it. Maybe he will come around to see something you do in a different light. Maybe you will learn skills about working in a heterogeneous environment that will be useful later.

---

Finally, if there's no way, you must go back to the way that worked before. Let him work on isolated tasks that don't require tight integration into the team.