What is a harmful employee? You’ve surely met your share in your career. Maybe you’ve been (or still are) one yourself. How can you know?
Usually, instincts will tell you when you are dealing with one and if all of them seem harmful, chances are that you are in fact the harmful one.
Let’s see what being harmful, as an employee, means. Businesses are run by people. The success of a particular business is directly translated into how well those people can contribute to it. Contributing poorly, means the the overall business health is less than it could be.
Considering business goals are rock solid and well communicated to everyone (meaning everyone understands what they need to do), here’s what a harmful employee looks like:
Poor technical skills that don’t improve
What this usually means is that the person does not actually want to do that particular job. Assuming they’ve had proper training and coaching, there is no reason to push them further into doing what they dislike. I call these people passively harmful.
A concrete example: Joe has to learn Python, to cope with the new tool-chain the team has adopted. After a month of study, Joe doesn’t seem to be able to do anything productive with Python.
Ever-present and putting a negative spin on everything
Some other helpful criteria is criticism, know-it-all (yet not helping and coaching), constantly using the straw-man’s argument by focusing on meaningless problems and amplifying them. I call them actively harmful.
These people are very destructive, because they tend to shut team members off, blocking a serious part of the business resources. No matter if they do have some technical skills, overall they are more harmful for the business if they stay. They should definitely go!
A concrete example: Sarah has a senior role (tech lead, architect etc.) within team X. One of her duties is to do daily code reviews for the team. She always adds patronising comments, letting team members know they are not doing their jobs right.
I would always choose the friendly-and-inquisitive over the rigid-know-it-all-senior type.
We’ll talk in a future post about what the “senior” qualifier is used for and what it should reflect, in the context of software development.