In 2018, a former Cisco employee gained unauthorized access to the company’s cloud infrastructure and spread malicious code that deleted 456 virtual machines that Cisco used for WebEx Teams. The law blocked access to nearly 16,000 WebEx users for two weeks. Cisco spent nearly $1.4 million in employee time auditing its infrastructure and repairing the damage, and also paid $1 million in compensation to users who were denied service.
Situations like this have made employee sabotage an essential and important issue for CIOs. But what happens when personal employee issues unrelated to dirt tech sabotage destroy projects?
Here’s a real-world story to illustrate:
Early in my IT career, I was working as a junior programmer on a large system project. Every week, the project manager updates the progress of the project task, but many of us are beginning to notice that the progress reports that are released were not actually where the project is. In fact, many of the tasks listed as completed were far from complete. Some have not even started!
The head of the information department was not aware of this. He trusted his project manager and was touting to his management that the project was ahead of schedule.
Several of us on the project visited the project manager, but he told us not to worry. We finally decided to take the issue to the CIO. At that point, the head of the information department stepped in.
By that time it was too late. Management was furious, the project failed, the CIO, the project manager, and several members of the project team were fired.
What happened here?
Over his head and fearing for his job, the project manager misled the CIO about the status of the project. It was a deliberate and harmful act – and destroyed an enterprise and many people’s jobs.
Can this situation be prevented?
Yes – if the CIO has done more “manage by walk” and visit with project team members and check the condition in the trenches before the project gets too late – And If the CIO has taken steps to reassign or obtain assistance from the Project Manager at the time the CIO finds out that the project was behind.
This was a case of not doing too little too late by not recognizing an employee who was misled on a project because the individual was afraid for their job and didn’t want to let the project they were running get into trouble.
Employee corruption in IT work can also arise when a technical teacher takes their time to complete a critical path task on a project because they don’t like the project or the people running it.
These are HR issues that often get overlooked when IT leadership fears offending a valuable system mentor whose services they wish to retain, or when they are uncomfortable confronting employees.
Unfortunately, when you sink your head in the sand, the potential for employee personal issues to disrupt projects exists.
How do you create an environment in which these types of employee project interventions are less likely to occur? Here are four options to consider:
- Be aggressive. Talk directly to your key mentors when intentional project disruptions and delays seem likely. Many project managers are reluctant to do this because they fear that they will alienate their teachers and that teachers are still not giving them project assignments. This can happen, but you cannot be let down. There are always outside consultants.
- Stay in touch with staff as well as technology educators and team leaders. The more you keep the pulse of your project squarely and people feel about it, the easier it will be for you to get the project back on track if it loses direction.
- Work proactively with HR and problem staff to resolve issues when problems first arise. This not only helps project deadlines — it lets employees who are having problems know that you and the company care about their well-being.
- Foster an open and communicative environment in which every employee feels valued and heard, regardless of the responsibilities they perform. One of the issues we had as junior programmers when we were on the project discussed earlier in this article was that the CIO wouldn’t listen to us. The lesson I learned from this early experience as I became a CIO myself was not to ignore the words or advice of even the youngest of employees. They are in the bowels of the “project ship” and are more likely to see project problems first.
What to read next:
Dealing with disgruntled employees
The IT Talent Crisis: Two Ways to Recruit and Retain
Don’t lose IT staff during the major resignation