43

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?

173

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.

| improve this answer | |
42

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.

| improve this answer | |
  • 3
    So? This is a good outcome, you warned the bosses so it's not your fault.... he's digging himself a hole. Let him explain to management. – Kilisi Sep 16 at 11:23
  • 31
    @Антон you really need to start jobhunting then, fixing the management from under is usually an impossible task. – Tymoteusz Paul Sep 16 at 15:58
  • 4
    No, he dug a hole for himself. Management risks a lot if they blame a team when it's not their fault. It's incredibly bad for morale. Sacking anyone even more so. Unless your job is an unimportant in which case they wouldn't be jumping up and down. – Kilisi Sep 17 at 8:40
  • 3
    I disagree: going to management is one option, but while that is happening they can also start modernising their devlopment provess per Chris Strattan's answer. They should be doing that anyway, and it may well be that the "difficult" guy would be happy to do that job. – Móż Sep 17 at 9:52
  • 4
    @Móż while modernizing development will help, it's a bandaid for the problem There's a team member whose contributions are hurting the team's output. A build server might reduce the hurt, but it will still be there. Then next year, we can read a question about a bad team member on a team with all the "right" tools. To be fair, a build server might be a workable short term fix. – iheanyi Sep 17 at 15:07
34

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?

| improve this answer | |
  • 8
    Your suggestion to let that person automate the build process is probably the best here! – Daniel Jour Sep 17 at 6:42
  • 6
    I would add the caveat that having more than one person able to do any given task is also bedrock once the company has more than one employee. So someone else needs to work with this person in order that two people can maintain the build system. – Móż Sep 17 at 9:55
22

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.

| improve this answer | |
  • 1
    On your PS, I'm a bit confused. You seem to be countering one irrelevant reference to age with another. On your PPS, I largely agree, but there are a few valid issues, such as that a company will have access to private information such as SSN. – Acccumulation Sep 16 at 21:42
  • 1
    @Acccumulation : if windows is spyware and the company doesn't have a solution, there are far worse problems than the SSN of a single employee. No company big enough to have 8 employees is paying in physical cash, for example, so spyware could lift the company banking access details... – Móż Sep 17 at 9:54
  • Acccumulation: God gave us language to use it as a tool in a multitude of ways. – gnasher729 Sep 18 at 13:33
17

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.

| improve this answer | |
  • 3
    I agree with this answer totally. Even if he uses emacs for programming and compiles everything manually directly, it should still be ok as long as the code looks like all the rest after being reviewed and pushed. – bracco23 Sep 17 at 9:46
  • 3
    As if coding in Emacs is bad... – lvella Sep 18 at 11:24
  • They shouldnt have to log into his machine, but they had to. I would try to avoid the need that anyone has to log into my machine, but OP’s colleague didn’t. – gnasher729 Sep 18 at 13:35
7

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.

| improve this answer | |
  • 7
    +1 for "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.". There's a significant chance that OP's coworker has valid reasons/experience for these decisions, but perhaps isn't good at articulating those reasons (or worse - he hasn't even been asked). – Eric Seastrand Sep 16 at 20:59
  • 4
    About your last bullet point - he wasn't working on the code on his day off, his teammates needed to fix something while he was out of the office. And that exposed a critical vulnerability - this individual's code could only be built on his workstation. This is a significant single point of failure - a huge risk to the business - and needs to be addressed immediately. – alroc Sep 16 at 21:53
  • 4
    I think it's reasonable to struggle a bit trying to articulate why vim/ linux/ cmake are useful tools when confronted by "our official build process is to fire up an IDE on a random Windows box and hope for the best". At least I think so, because I've gone through that with someone who just couldn't/wouldn't understand why "every time I build this program behaves differently even if there are no code changes" could possibly be an issue. – Móż Sep 17 at 9:58
  • @alroc that's exactly why the script-compatible build setup on the co-workers machine needs to evolve into the project's official build server; you shouldn't need any particular local configuration to accomplish a build at all. You might have an IDE-based convenience method as well, but you don't rely on it to be able to build, and you don't ship its local-configuration-influenced result. – Chris Stratton Sep 17 at 15:18
4

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.

| improve this answer | |
1

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.

| improve this answer | |
  • @Tom I upvoted you answer but here's some points to consider from my point of view. Regarding your first point, 100% agree. 2nd, if management thinks he's untouchable AND he's causing multiple deadlines misses, it may be a time for OP to look for a new job. Otherwise he's gonna get blamed for thing out of his scope. 3rd, not everyone is a local superstar who can ignore politics (and I'd argue even superstars may need to conform). 4th, this is the one I don't agree with most - you should work to the best of your ability even if project is uninteresting - that's what work relation is about. – Yuropoor Sep 21 at 13:00
  • @Yuropoor you are actually legally speaking wrong about 4th. At least in my country, by law as an employee you owe the employer a work of average quality. IANAL but I have legal training in the area of employee laws. – Tom Sep 21 at 17:29
  • @Tom maybe, I'm speaking from the perspective of my country, where you are expected to perform your duties "to the best of your ability" (that's actually in the law). Locale varies :) – Yuropoor Sep 21 at 18:53
  • @Yuropoor interesting. Indeed, location is important here. The OP didn't give a location, so it's a guess. – Tom Sep 21 at 23:08

You must log in to answer this question.

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