Why Does H.R. Too Often Kill Innovation?

"Whatever you do, please don't mention this to anyone in HR, they will kill it". That quote may sound odd but it is real. The 'it' being kept secret from HR is an innovative learning program. I am sure the same thing happens with all sorts of HR innovations, not just learning. When HR hears about a manager who is doing things a little bit differently their first reaction all too often is to want to kill it outright or wrap it in a deadly python of bureaucracy.

This article was written with Phil LeNir and David Creelman.

One client spent two or three hours on cross-continent video conference calls trying to decide if they would try one 90 minute session. Another leader reported he was going to have to write a business case to justify spending $1,500 to continue a small pilot.  The literature on innovation recognizes the value of small experiments; but even though HR tends to be aware of this kind fact, they tend to treat experiments with considerable distaste.  There are good reasons for this, as well as bad ones, and these need to be disentangled before we can get to the meat of how to improve innovation in HR.

The obvious bad reason is simply that HR wants to protect its turf; if it's an HR related effort they want to control it and any associated budget. This is however linked to a good reason which is that organizations don't want managers running off doing things that are risky or ill-considered.

We often see the same thing in IT. Managers may have experienced the wrath of IT when they try to bring in a Mac into an organization that has standardized on PCs. There are both good and bad reasons for IT's inflexibility. They need to prevent any actions that would undermine the security of their system and also they need to protect themselves from the user demands that can arise when someone has an incompatible hardware setup. They may also just be difficult for the sake of being difficult. But the right steps are relatively clear.  A good IT department will look at the issue, assess the risks, see if there are reasonable steps to mitigate the risk, and if it makes sense then allow the user to go ahead with the non-standard system.

Read full article: Forbes, January 23, 2012