# How to negotiate with uncooperative senior engineers after they've been given new laptops they don't want to use

I'm a manager at a mid-sized engineering firm. We recently implemented a mandate that everyone has to now use a Windows laptop with various security tools installed on it for auditing, backup, and legal purposes. A new software tool for how we write code (i.e. a Visual Studio) also now has to be used.

This has gone over well with most of our engineers (about 60 in total), but 5 particular senior engineers are objecting to this. They have some common setup where they do almost everything from the command-line and using some console text editors. We considered their requests to let them keep using their existing setup on the new laptops, but everyone must now do development in Windows. If they want their Linux setup, they can create a virtual machine, but coding must still be done in Visual Studio.

After finally having their laptops replaced, their productivity as a whole has dropped off a cliff. I've asked them several times why, and they make a point of dramatically typing slowly or going through pages of dialogs/menus with the mouse, blaming nearly everything on Windows, Visual Studio, and having to use a "rookie" text editor.

The engineers in question are senior level and smart, and I think this is just their way of resisting change, but I need them to get back to business as usual.

How can I best work with them in order to help them follow the new standard?

• It's not about whether Windows and Visual Studio are better than Linux and a text editor. It's about the fact that they can no longer use the tools and environment they know well and are comfortable with and have been using for (presumably) decades. How much warning did you give them before you took away their computers? – David K Jan 9 '18 at 18:02
• Changing tools will almost always lead to a significant drop in productivity while people learn the new tools. There are ways to mitigate this. What did the communication regarding this policy and the rationale look like before you started enforcing it? What did you do with respect to training on the new tools before and after the rollout? Do they actually have technical concerns about how they are building the product now (I would if I was told to use Visual Studio to build products for Linux)? – Thomas Owens Jan 9 '18 at 18:03
• I'm really curious how you came to a decision with technical ramifications like this. It seems to me like you didn't consult the right members of your staff to evaluate your options and make technology decisions that are appropriate. I'm sure that there are options for Linux that would allow for the same security controls, auditing, and backup that you have in your Windows environment. It seems like you expect them to be controlled. The business should never be making technical decisions without involving the people doing the technical work, and I think you now see why. – Thomas Owens Jan 9 '18 at 18:23
• Who mandated this policy? IT or security? You? – Mister Positive Jan 9 '18 at 18:32
• OP: What makes you think that Emacs or Vim are "antiquated"? That seems to be an important assumption in your reasoning, but doesn't align with the fact that Emacs is actively maintained or with the fact that countless extensions are written for it every month, often anticipating the excellent MSVC. In my opinion, you should re-evaluate that assumption. The idea that "command line is antiquated" also clashes with the emphasis placed by Microsoft on PowerShell, launched in 2006. – Tobia Tesan Jan 10 '18 at 6:35

If you truly want the developers to be back to their old level of productivity, then you need to start being more sensitive to their concerns. At the moment, you (or you company, it doesn't matter, you represent the company on this) have told a bunch of creative folks "we're taking away your favourite tools, suck it up". Instead of trying to work with the developers, you are instead belittling them by using words like "antiquated" and "pouting"; even if you haven't used those words directly, I'm pretty sure your attitude towards this is obvious.

As a manager of developers, you are (or should be) aware that a decision like this was going to cause resentment among at least some of your staff. Explain to them that you understand their concerns and want to work with them to minimize the pain this decision is causing. Explain to them the business justifications for this change, and that you appreciate that you've made their jobs worse, but the company needs this change to happen. Work with them rather than against them - is there a bone you can throw them in exchange for having messed up their development environments? Definitely, definitely stop arguing (as you're doing in comments) about whether their preferred development environment is better or not.

Alternatively, haul them into a disciplinary meeting and give them a written warning. At the same time, you may as well talk to HR about your need for five (or maybe more) new senior engineer hires because nobody's going to want to work for a company with that kind of sucky attitude towards creative talent.

• You missed "discipline", "smartening up" and "get back to business as usual". – paparazzo Jan 9 '18 at 18:48
• The OP hasn't really explained adequately on why they need to force developers to use windows. It sounds like they want to install productivity monitoring apps on it and something like that would be beyond the control of the manager. Either way it sounds unusual to me they'd go from something that has been working to forcing devs to learn "approved" tools. – Dan Jan 9 '18 at 18:49
• @Dan Yes, the decision was almost certainly beyond the OP's control, but that's part of being a manager - sometimes you have to implement other people's decisions. A good manager will work with their staff, understand their concerns, and make them feel valued even when implementing unpopular decisions. – Philip Kendall Jan 9 '18 at 19:05
• Yeah, besides telling your best experts how to do their job, haul them to a disciplinary meeting, that should work well. What are you trying to accomplish, that all of them fire themselves at once? You are dealing with smart people, not housemaids or cattle. – Rui F Ribeiro Jan 10 '18 at 11:00
• @RuiFRibeiro I hope it was obvious that I thought that wasn't a good idea. – Philip Kendall Jan 10 '18 at 11:51

The command-line is for experts:

• It's faster.
• It uses less system resources.
• It allows complex tasks to be carried out quickly (i.e. regex, in-line shell scripts, etc).
• It's more deterministic and repeatable that clicking through a dozen modal UI menus (i.e. I can copy-paste a one-line shell script to perform some esoteric operation, while the UI users get to spend 30+ seconds menu-diving).

As for the editors you mentioned, it looks like you got the first one correct: vim. The other though, is likely emacs, not emux. Similar to the command-line vs GUI argument I posed above, people immersed in the world of command-line and modal "antiquated" editors tend (but are not guaranteed) to be much more experienced than their UI-using counterparts (Greg Kroah-Hartman, arguably one of the most clever Linux kernel developers currently active, uses mutt for e-mail and vim for development; and both are "antiquated"-looking tools). The people with whom I've worked that use such setups tend to be kernel or Linux experts, write their own plugins for code completion and aiding day-to-day tasks, etc. You mentioned that its just senior engineers that are opposed to this: that doesn't come across as a surprise.

It sounds like "the five" are exaggerating a bit when they demonstrate the slow typing and mouse usage like you described, but it isn't likely 100% exaggeration: they're telling you the problem, and you "refuse to believe" it. You have a group of experts, you've taken away the power-user tools they use to excel at their jobs, and gave them one-size-fits-all tools in place of what they were using. The fact that your product is running on Linux and all developers have to use Windows to build for it is puzzling: it just makes no sense.

# Solution 1 (Practical, sub-optimal)

If you can drop the "you must code in Visual Studio" requirement, and let them use virtual machines, you'll probably meet somewhere in the middle, and their productivity will recover (though you'll likely have new issues like VMs crashing, virtual disk files becoming corrupt) cutting into their routine now.

# Solution 2 (Practical, optimal)

Just give them the new laptops, and let them dual-boot Linux and Windows.

• Comments are not for extended discussion; this conversation has been moved to chat. – Monica Cellio Jan 9 '18 at 23:12
• Solution 3, practical, more optimal: cygwin. Solution 4: WSL. Solution 5, limited but low-investment: emacs.exe – Tobia Tesan Jan 10 '18 at 14:40
• It is Worth to note that you don't need to navigate menus in Visual Studio if you don't need to. That tool is extremely customizable and has shortcuts for almost everything. VS also has a customizable and extensible console built in to it, so if you want to use command lines instead of chord shortcuts or menus, just set it up for what you need. It is as much "one size fits all" as vim or emacs. – T. Sar Feb 16 '18 at 16:31
• @T.Sar Not so much, in my experience. In VIM, if I want to do a lexical rectangle selection of text 30 lines down, 12 across; conditional regex-swap some items, and get on with the task at hand, it's about 3-4 seconds, and my hands never leave home row. VS: I'm spending that much time just getting the mouse selection right. VS is a good IDE overall, but its editor is non-modal end encourages the use of menus, so the developer is rate-limited by the tool rather than his/her mental limits. – Cloud Feb 16 '18 at 16:45
• @DevNull You can customize that keyboard shortcuts, but for C# defaults that would be shift+alt+arrow keys to select that, control H to bring up replace, do your thing, then esc to go Back to coding. I agree that it may not be as fast as VIM, but you don't really need to touch the mouse or the menus to do that. – T. Sar Feb 16 '18 at 17:16

Speaking as a power-user with LOTS of experience with Linux and Windows...

1) You just took the tools your engineers told you they need to do their jobs. This is like them telling you they need screwdrivers and you insisting they can use hammers. There are many tasks and niches where Linux is the superior solution.

2) It's amazing how often IT thinks they should control R&D's tools. It's a bad idea because the two groups have very different priorities.

3) Highly likely the whole "having to use a "rookie" text editor" or "going through pages of dialogs/menus with the mouse" is just the tip of the iceberg and what they can easily show you. There are tools they just don't have any more.

4) A new flavor of windows comes out every few years and burns down the acquired experience people had using the old one. Linux, and especially command line, doesn't do that. So a senior person who is used to command line can have decades of experience getting things done, now they get to learn everything over from scratch with a gui. So they're not "experienced" any more.

Solutions:

1) Let them go back to Linux.

2) Wait it out. Eventually they'll get better... but that's very much not the same as them getting totally back to where they were in terms of efficiency.

Whatever you do, you should be prepared for one or more of them to quit. This sort of thing creates disgruntled employees. Senior developers with Linux experience are readily employable.

• I deliberately avoided going into the technical weeds of "I can do X" with Linux. I know, "vim", "bash scripting", "piping commands which affect hundreds of files at once", "Linux is thin client", etc but whoever asked the question clearly isn't a software person and wouldn't understand any of that. – Dark Matter Aug 15 '18 at 20:58
• " This is like them telling you they need screwdrivers and you insisting they can use hammers." wellll that analogy isn't quite hitting the mark, after all anything I can make in vim I could also make with VS, and that's not the relationship between hammers and screwdrivers. Perhaps it's closer to telling developers they have to use a space-hopper instead of walking when in the office. Technically possible, but slower, impractical and likely to cause some accidents. The space-hopper also captures how funny it is from an outside perspective. – Clumsy cat Aug 17 '18 at 8:05
• @Clumsycat We have a non technical person describing what tool substitution he forced and it includes the removal of the Linux command line. Command piping and/or bash scripting opens the door to absurd increases in productivity, "change a thousand files a thousand different ways all at once" by having grep/sed/find with an input file inputting the change and the conditions needed. Engineering needs should be driving this sort of thing... and my impression is engineering needs weren't taken into account during this change over. IT is telling R&D what tools they can use. – Dark Matter Aug 17 '18 at 12:28

Based on what you've presented, there is no going back. Development will be done in the new environment. As a manager, you need to face reality. Regardless of what you think, "they" were more productive in the old environment. It's just a fact.

Since there is no going back, you need to make sure they become proficient in the new environment. Have them work with others who seem to be excelling in Windows. Establish an acceptable level of performance and consequences for those who cannot meet them in a certain amount of time.

Hopefully, they'll take you seriously and improve. What you're willing or can do if they don't is for you to determine as the manager. After all, that is your job.

• I am amazed they did not quit on the spot, but they must surely be back on the market now. – Rui F Ribeiro Jan 10 '18 at 10:58
• @RuiFRibeiro - Maybe if they lose one or two people, management will wake up. – user8365 Jan 16 '18 at 16:26
• Doubt it pretty much or they would not be in management... PHBs – Rui F Ribeiro Jan 16 '18 at 23:59
• Rui: No, you don’t quit on the spot. You apply at other places, spend the day moving the mouse around, give a **** about your productivity, take your salary, and when you signed a new contract, that’s when you give notice. – gnasher729 Aug 16 '18 at 7:09
• @gnasher729 that's especially true when the developers in question are senior: it's more likely that they have kids and/or other obligations. They can't just quit on the spot to make a point (like someone still living with their parents might be able to do). – Mike Harris Aug 17 '18 at 1:29

Especially senior level workers have a significant amount of "muscle" memory when it comes to working with their tools and you basically lost all that advantage.

Furthermore, they apparently aren't even familiar with the new tools they're now to use, losing you more productivity.

This significant loss in productivity and sour work climate is your / your companies fault by forcing a completely new work environment and toolset on your employees.

You should have instated a transitional period (ideally between projects) where they could've learned their way around the new software and ease into production.

If you didn't hold training sessions for the new tools you immediately should do so.

You can approach your disgruntled workers by offering them training and cutting them some slack until they are up to speed on the new system. This will take a while, you should have planned for this.

You must have very important reasons why you decided to use that particular software, communicate these clearly to your employees and show them not only the benefits for the company but also any studies that highlight benefits to your engineers.

Make sure they learn to utilize these first to recoup productivity and hopefully make them see the good in the extreme change they now have to chew through.

• Be careful about selecting the training sessions. You don't want to run your senior people through anything like "introduction to programming" courses. – David Thornley Aug 16 '18 at 19:52
• @DavidThornley good point – DigitalBlade969 Aug 17 '18 at 7:26

The best thing to do here would be to work with the development team, operations, security people, etc. to find a way to allow the developers use the tools they want to use will addressing the security and audibility concerns. This may involve more expense and some compromises by the developers and some accepting of greater security risks.

Assuming that this is not possible then you need to explain to development team why you are making these changes. Prepare a talk and a document explaining why you need to make these changes. I can understand why its easer to secure and audit when using one operating system than two. I personally have a hard time imagining why the choice of software delopment tools (except for debugers and network sniffers) would matter. Explain to them why the tools they want to use can't meet your requirements. Explain why Visual Studio must be used. Be open to people's questions.

Your development team will also be more inclined to resist these changes if they think there is a chance they will be undone. Make it clear that for the reasons you gave the decision won't be reversed.

You have to stop thinking of the developers as being unprofessional. They are just doing they they think they can to overturn a change they think is a mistake and is making it harder to do thier jobs. They may think you are dogmatic and inflexible. It does nobody any good by assuming that others are not doing the right thing. This is why openness is important.

The company has decided on a particular balance between security concerns and developer productively. You must now accept that deleopers will be less productive. For many developers you are asking them to invest a lot of time and energy in learning new tools. Some will decide its not a good investment and will leave. Worse, they may decide not to learn to tools and stay. You have to plan for what to do when both of these things happen.

Your company just went through a tectonic shift.

Short answer : Let me tell you how it feels for them: Imagine being right handed your whole life, then being asked to draw the Mona Lisa with your left.Yup that's it.

Let me give you perspective from a programmer's point of view.

It is not a surprise that your experienced employees are objecting to the change.

They have become experienced by using the standard tools used in programming and software development community.

These are old tools, and still widely used. This doesn't make them antiquated. They demonstrate the fact that they are apt for software development, and hence has great support for the users. And people love them.

Now, if they are not allowed to use those amazing tools, then do be prepared for reduced productivity and possibly missing deadlines .

Now elaborating on the productivity drop : Your senior employees will be severly handicapped due to the restictions of a new development environment.

As someone who uses Vim and Linux, let me tell you that the mental fatigue experienced by the employee will be more than what you are facing, due to their reduction in productivity.

They want to be productive and it is not just pouting. Imagine having a Formula 1 racecar but only allowed to go at 20 miles per hour.

I am assuming that they are not being paid by the hour and if they don't meet their deadlines, then they may get fired, maybe not immediately but still possibly in the future.

Visual studio is an Integretaed Development Environment (IDE) and a great one at that, you can let them know that vim and emacs plugins are available for them, that would improve the morale and productivity (for a little time).

But here is the most important reason why your employees may be unsatisfied : cmd.

cmd stands for command prompt and is the main terminal for Windows, it is horrible (nicest way to put it). Microsoft however have done a great job and improved their cmd for Windows10. Windows 10 also has WSL feature which allows to run a linux distro side by side and allows installing a lot of important linux tools that are not available in Windows. Maybe you can use Windows 10?

I can't say anything about the management aspect since I don't have that experience. But would gently recommend that before changing the working environment, kindly consult with the team members.

Most of the grievences come from junior employees, but since the senior employees are grieved, it does show a serious lack of communication.

Why were the senior employees not consulted before such a tectonic shift? They should have been the ones helping in deciding which tools to use in production.

That is the core of the issue...

• I've always felt demoralized when my employer didn't seem to care if I was productive (and it's happened a few times). If they don't care, why should I? I don't know how common this attitude is. – David Thornley Aug 16 '18 at 19:48
• The Windows cmd is a complete strawman. You can have lots of options if you want to use the command line, including cygwin which gets you your bash shell etc. – DaveG Aug 16 '18 at 20:38
• @DaveG "power shell" could be an alternative / addition to cmd as well – DigitalBlade969 Aug 17 '18 at 7:34

Any time you ask developers, especially ones set in their ways (young or old really doesn't matter) you are going to have resistance when you 'standardize'. From a corporate standpoint standards makes sense, and once established and the dust settles usually result in cleaner code and better productivity.

So you have a couple of choices here:

1. You can continue to let this group drag their feet and resist the change, undermining your authority and putting the future development of your product at risk.
2. You can be the manager and fire one or all of them. You are not losing here BTW, they are going to quit as soon as their resumes hit the street, which is not going to take long.

The above said. Your company is an idiot. They made this change without consulting the most senior on the team. Instead of formulating a standard around what is working and what is industry standard for what you develop, you picked something that someone in IT thought was the most cost effective and went with it. You have great standard corporate security now though, so you have that going for you, now if you can just find some senior developers willing to work with that crap you are all set.

• Any action like firing the engineers or putting them on a Performance Improvement Plan is going to demoralize everybody. They're going away, but everybody will feel better if they do it under their own power. – David Thornley Aug 16 '18 at 19:50
• They already demoralized everyone by making a major shift in tools and process while not involving those that actually have to deal with it. – Bill Leeper Aug 16 '18 at 21:41