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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Long answer :

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...

Answer 7

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.

Answer 8

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.