Employees Maliciously Comply With Manager’s New Policy That Slows The Whole Company Down And Just Watch Him Get Fired
It’s very frustrating when someone at work who’s clueless about your job starts reorganizing it just because they can. And it’s even worse when they dismiss your concerns about the changes they’re making.
When Reddit user and software development team manager Available-Election86 heard that their security guy wants to revoke their entire team’s computer administrator rights, they did everything in their power to stop it.
However, the man didn’t change his mind. So Available-Election86 resorted to the last option — malicious compliance.
This software development team manager was shocked to hear that his staff are losing their computer administrator rights
Image credits: Procreator UX Design Studio (not the actual photo)
But as soon as the staff started complying with the new policy, things at work quickly got out of hand
Image credits: bruce mars (not the actual photo)
Image credits: u/Available-Election86
The company’s (former) security manager was very wrong to completely dismiss everything Available-Election86 said. When Harold “Hal” L. Sirkin, Perry Keenan, and Alan Jackson studied change initiatives at 225 companies, they found a consistent correlation between the outcomes (success or failure) and four hard factors and four hard factors, which they called DICE: project duration, particularly the time between project reviews; integrity of the performance, or the capabilities of project teams; the level of commitment of senior executives and staff; and the additional effort required of employees directly affected by the change.
“If you think about it, the different ways in which organizations combine the four factors create a continuum—from projects that are set up to succeed to those that are set up to fail, Sirkin, Keenan, and Jackson wrote in Harvard Business Review.
“At one extreme, a short project led by a skilled, motivated, and cohesive team, championed by top management and implemented in a department that is receptive to the change and has to put in very little additional effort, is bound to succeed.”
“At the other extreme, a long, drawn-out project executed by an inexpert, unenthusiastic, and disjointed team, without any top-level sponsors and targeted at a function that dislikes the change and has to do a lot of extra work, will fail,” the researchers explained.
Which is exactly what happened with at our Redditor’s company.
Image credits: Ant Rozetsky (not the actual photo)
“Companies must boost the commitment of two different groups of people if they want change projects to take root: they must get visible backing from the most influential executives, who are not necessarily those with the top titles, and they must take into account the enthusiasm—or often, lack thereof—of the people who must deal with the new systems, processes, or ways of working,” Sirkin, Keenan, and Jackson highlighted.
When managers launch transformation efforts, they often don’t realize, or know how to deal with the fact, that employees are already busy with their day-to-day responsibilities.
Because of that managers must calculate how much work employees will have to do beyond their existing responsibilities to change over to new processes. “Ideally, no one’s workload should increase more than 10%. Go beyond that, and the initiative will probably run into trouble,” the researchers said. “Resources will become overstretched and compromise either the change program or normal operations. Employee morale will fall, and conflict may arise between teams and line staff.”
The least Available-Election86’s (former) security manager could’ve done after he went ahead with the new policy was to take away some of the regular work of employees who were affected by the change. Instead, he refused to acknowledge his mistake even when it was growing in front of him.
A lot of people related to the original poster (OP) by sharing their own similar stories
And everyone applauded their nonchalant reaction to this ridiculous demand
My company had a couple of devs based in the UK office. They had full access to everything so after they left without handing over anything, we clamped down so the current devs had a Dev and test server. As one example, one of these old devs created an internal web app that pulls financial information from our main application. However, he made it on a second laptop and told no-one about it. So when it stopped working after he left, I had to tell the staff who used it that I had no idea about it as the guy left without telling anyone anything. Its was after about a month that I found the laptop running this application. They also installed things on different servers seemingly at random. The nature of the dev work in my company means that they did not actually need admin rights to their machines, only the test and dev servers we gave them.
I used to work in Dev Ops, and the devs were used to having admin rights to the test environment. They would merrily tweak things, install patches, change registry settings etc so that their code worked. Naturally they never documented this, it was never done in a checked in script, so when the code finally deploys to production, it falls over in a big heap. Taking away their admin rights actually reduced the amount of production downtime and the number of rollbacks quite dramatically.
Load More Replies...He handled it very well. Wasn't a jerk, followed rules, just made it very clear that it wasn't going to work.
Wow, thought my company was the only one being this shite about access privileges. They literally laid off 90% of our IT team to outsource the work to India. So now anytime we need something technical fixed. We need to put in a ticket, that ticket needs to be approved by our manager, than it needs to be looked at by the IT in India, (which is a completely different time zone obviously so they are only available for half of our working day). And the company is trying to push for people to be "more productive". It really makes you wonder how people this stupid get put into high important decision making roles...
My company had a couple of devs based in the UK office. They had full access to everything so after they left without handing over anything, we clamped down so the current devs had a Dev and test server. As one example, one of these old devs created an internal web app that pulls financial information from our main application. However, he made it on a second laptop and told no-one about it. So when it stopped working after he left, I had to tell the staff who used it that I had no idea about it as the guy left without telling anyone anything. Its was after about a month that I found the laptop running this application. They also installed things on different servers seemingly at random. The nature of the dev work in my company means that they did not actually need admin rights to their machines, only the test and dev servers we gave them.
I used to work in Dev Ops, and the devs were used to having admin rights to the test environment. They would merrily tweak things, install patches, change registry settings etc so that their code worked. Naturally they never documented this, it was never done in a checked in script, so when the code finally deploys to production, it falls over in a big heap. Taking away their admin rights actually reduced the amount of production downtime and the number of rollbacks quite dramatically.
Load More Replies...He handled it very well. Wasn't a jerk, followed rules, just made it very clear that it wasn't going to work.
Wow, thought my company was the only one being this shite about access privileges. They literally laid off 90% of our IT team to outsource the work to India. So now anytime we need something technical fixed. We need to put in a ticket, that ticket needs to be approved by our manager, than it needs to be looked at by the IT in India, (which is a completely different time zone obviously so they are only available for half of our working day). And the company is trying to push for people to be "more productive". It really makes you wonder how people this stupid get put into high important decision making roles...
60
12