Slashdot Mirror


Should Failure Be Rewarded To Spur Innovation?

Lucas123 writes "Paper products maker Kimberly-Clark drove the morale of its IT infrastructure group into the ground after massive firings and outsourcing. When they hired a new VP of Infrastructure four years later to turn things around, he implemented a program to spur innovation. The VP took a venture capitalist approach where any employee could submit an idea and if accepted, make a pitch in 30 minutes or less. If the idea had merit, it received first, then second rounds of funding. If not, the employee's idea still got lauded on the company's internal Sharepoint site. As he puts it, 'Failure is simply the opportunity to begin again, this time more intelligently. It's about what we learn from the failure. Not the failure itself. We celebrate that learning.'"

2 of 146 comments (clear)

  1. Re:Better phrasing by Anonymous Coward · · Score: 2, Informative

    Absolutely spot on. Rewarding failure doesn't encourage innovation. Not punishing failure does to some extent. Acknowledging taking initiative does so even more.

  2. Re:Is this a joke? by discord5 · · Score: 3, Informative

    The fact that this is modded Insightful makes it that much better.

    I guess it's time for me to fetch that cup of coffee and test my theory. ;)

    In all honesty, I think it's okay to fail every now and then when testing and experimenting with things. We learn mostly by doing, and the most valuable experiences are always the ones where we fail and learned something in the process. There are scenarios where failure is not an option, and at those times it's for the best to have the experience of knowing what won't work. The thing is, it's part of the "creative/innovative process", and I don't believe your employer should pay special attention to it other than giving you the opportunity to do so every now and then where it doesn't really impact anything critical.

    The whole sharepoint thing seems like one of those management decisions in a company where "innovation" has become a buzzword. A few months ago I attended a meeting where management had suggested that we should make room for innovative projects. They decided that people were free to come up with ideas and suggest them to management, providing there would be an acceptable planning and feasibility study, etc etc. Sounds like common sense right?

    The whole thing got bogged down in red tape of course. The few ideas that bubbled up in "creativity workshops" have become so twisted and bloated in scope that they would require several manyears to achieve, which is impossible on the shoestring budget they set aside for it. I'm not lamenting the whole budget thing, nor the fact that management kind of wants to track the process itself, it's just the way they're doing it.

    They've got the sharepoint thing, and they've added tons of overhead, including documenting and reporting your progress in a fashion that would make bureaucrats roll their eyes (similar to ECSS standards for those familiar, which is way overkill for the whole thing anyway). For every hour you're spending on trying something you're faced with at least an hour of paperwork. So most people who had this small interesting idea, are now saddled with a full blown project that exceeds the scope of "scratching an itch" and working from there, up to a point where it's interfering with actually getting stuff done.

    So the end result will most likely be (fairly costly) failure. It's more than okay to shoot yourself in the foot sometimes when trying out something in an environment where you can't do any harm. But people are going to be far less inclined to pull the trigger if everyone sees it giving opportunity for people to use it against you with an extremely well documented failure. I hope that explains why my previous post was rather cynical.

    I personally tend to experiment a lot in the early stages of projects where we are considering various solutions to a problem. And I do so most of the times by breaking the stuff I've built several times, fixing it and in the end picking the solution I feel most confident with. While I'm experimenting I just take short notes, instead of documenting everything. Fully document the solution you pick and the reasons why you feel it's the best solution, not the minute details of the process of experimenting itself. So far that approach has worked for me and I don't think adding more oversight or overhead to that initial process contributes anything useful.