The perils of HR

Every working adult and their cats would have a story about how much they dislike, nay, abhor, HR (and in some places, things are so bad that even HR folks have their own HR story to tell and I kid you not). So is it a wonder that someone actually writes “Why They Hate HR? [http://www.fastcompany.com/magazine/97/open_hr.html]”.

Just like everyone else I have my story to tell and I also have my own theory why HR just doesn't work. Mind you that this story is not my worst brush with HR, but it demonstrates, with simplicity, the abysmal state of HR.

This happens to me on one of my previous job. The story starts when my project team applied to go to this one training. You see, my team uses this software platform in our project. The platform (let us call it Platform X) is ubiquitously present all along the system we are developing. I.E. the GUI guys would be interacting with Platform X as much as the database guys or the middleware guys. Due to that, we all applied to go Platform X training and guess what, we got rejected because... wait for it... the policy says only one person from one project can go to a particular training.

Apparently, a few years ago (before I joined the company), a group of 5 employees from the same project applied to go to a 5 day training. Now instead of staying for the whole 5 days, each one of them would take turn to go to the training while the others enjoyed a 'paid vacation'. The HR director found out and decrees a law that 'hence forth, thy projects can only send one soul to training’. I guess, in some projects in makes sense, furthermore it does save the company a few cents on training expenses. But in my case (and I'm sure the same goes with many other projects) this law just doesn't make sense. If we send a GUI guy to the training, as much as he would like to understand how Platform X interact with our distributed multi agent based high performance cache system, I don't think he can. The same goes if we send a middleware guy, he would be clueless on how Platform X interact with the GUI stuff. Now to make matters worse, there was a change of requirement and we now need to include mobile devices components in our project and guess what? The mobile stuff are also ... going to interact with Platform X.

We wrote an appeal letter to HR saying that if we don't get this training, there's a high probability that the project will fail. The lady officer assigned to our case informed us that there's nothing she can do, apparently the decreed law has made its way into our HR system as a 'business rule' and it'll take a whole lot more than our collective pretty faces to change that. Sure we can make the appeal go all the way to the CEO but that'll take too much time and that is a luxury we didn't have.

All and all, due to the importance of the project, the client agreed to sponsor the training (with a huge reduction in fee and a large red line going through our Gantt chart cutting our timeline by almost half) and it was worth it. The training went well, we learnt a lot about Platform X but things could be better. Due to the reduction in fees, we had to let go of a few engineers (some of them are quite good) and due to the reduction in time, we need to rush like crazy. (In fact we were a bit off schedule in the end) What if HR would just swallow its pride and help let us go to that training we asked, Ok so what is some of our project team skip a day of the training... I'm sure that would actually cost less that what we have to 'pay' in the end.

And herein lies the problems with HR.

1) Business Process Over-Automation

How many times have you been to HR to complaint about something and they would simply dismiss you by saying 'it is already in the system, I can't do anything about it'. Well, if you're anything like me, that is almost the single most quoted excuse ever... OK, I lied, the single most quoted excuse is actually 'The manager's on leave' but 'it is the system' excuse must be one of the top 10 if anything.

I call this over-automation. Don't get me wrong, I'm all for automation but when the business rule goes something like: 'If the employee has been working less than 2 years and the project's duration is less than a year and the employee's mother is a keen supporter of Manchester United and the employee don't like sushi, then deny him any access to training'. You know that there's something wrong. Over automation is when rules 'hard coded’ into the HR system just doesn't make sense and yet it is religiously enforced because it's 'policy'. Now, over automation in itself is still OK, what makes things worse is over-automation plus paranoia. This brings us to the second problem.

2) Assuming the worst in your employee

How are HR business rules created? Simple, they just observe the employees, find the worst thing that they can do, assume everyone else will also be as bad and create rules against that.

Stupid HR rules is all about assuming that you are evil somehow, that you will abuse the system and you will run the company bankrupt with your lofty 'paid vacations' and 'non-cost-saving' attitude. Will there be abuses? Sure. Will the collective cost of failed projects and low morale make up to the cost of those abuses? I don't know; in fact, don't ask HR, they won't know either. And therein lies a problem. To concretely study each business rule in the system and find out its actual cost has never been attempted. In fact, everyone assumes that HR is omnipotent and will not make mistakes. Well, here's news for you HR does make mistakes, again and again.

Now what should HR do instead? Shouldn’t they have business rules? They should but HR officers should be given enough authority to make exceptions. In fact they should be encouraged to make exceptions because we are all different! We have different talents and different needs. Ned in accounting has a baby boy who suffers from thalassaemia. He should get more 'emergency leave' than Sue from engineering who is single. Consideration should be given on a case by case basis because HR stands for HUMAN resource and not HIGHLY AUTOMATED resource.

But how do you avoid abuses? Now since HR has this system in place, couldn't they measure how much a decision improves or not a project for example? You cannot improve what you cannot measure so HR should start making exceptions and start measuring if things are really abused or if it is just plain paranoia of some lonely HR manager still clinging tightly to his pillow, scared stiffed that the boogeyman is going to come out of the closet tonight.