IT Employment

Don't let standards impede employee innovation

If users want to use one-off software tools or hardware, IT pros might want to think twice about saying "no." Jay Rollins says being too standards driven can be counterproductive to employee innovation.

If users want to use one-off software tools or hardware, IT pros might want to think twice about saying "no." Jay Rollins says being too standards driven can be counterproductive to employee innovation.

-----------------------------------------------------------------------------------------

I find it interesting when I hear my IT colleagues make a joking comment such as: "Computers would work fine if it wasn't for users!" When they do, I always try to look a little deeper to see if there is anything to these comments.

When you think about this in context, the main point is that IT standardizes the system to do certain things. We secure volume license agreements so everyone can use the same software. It's logical; we need to share documents and spreadsheets throughout the company, so we need to standardize all the applications. Then, we get mildly annoyed when some department wants to install a one-off graphic design software package.

In IT, every day we focus on providing a stable computing environment. We resist one-offs because we understand that introducing variation into a stable system can make the system unstable.

In innovative companies, standardized tools may not be the way forward when generating new ideas or prototypes for new products. For example, W. Edwards Deming used to do an exercise called the Red Bead Exercise to demonstrate the stability of predictive systems and how they can sometimes limit innovation.

Here's the setup: You have a small box. In that box, you have about 100 white plastic beads and about 20 red ones. Additionally, there is a little spatula with 10 holes on it that hold 10 beads perfectly. The point of the exercise is you have two people come up to the middle of the room, and you give each one their own box of beads and a spatula. You also bring up two more people from the audience who serve as supervisors for these workers.

The moderator acts as the CEO of the company and explains exactly how the workers should perform their tasks:

1. Hold the spatula in only one hand

2. Dip the spatula into the box

3. Remove exactly 10 white beads

"That is the process. Do not use another hand and do not deviate from this process. Perform this standard procedure exactly."

The spatula comes up with mostly white beads, as well as several red ones. The CEO writes down the number of white beads and the number of red beads (defects). One "worker" will usually have fewer red beads than the other eventually. At this point, the CEO comes down and talks to the supervisors. "You need to get your employee in line. We produce white beads. Sally pulled up 9. Your worker only pulled up 7. What seems to be the problem? We provide all the tools needed to do their job, and yet they continually pull up red beads. There must be a problem with the employee or your supervisory skills. Fix it or you are fired."

The exercise points out very succinctly that empowering the worker to come up with a way to do their job better will produce the desired results. Some folks will dip the spatula in and pick off red beads; others will go through the entire box of beads and take out all of the red ones first. You get the idea.

The lesson I get from this is not to be too strict with "foreign" software tools or hardware. Being too standards driven can be counterproductive when it comes to employee innovation. IT can add value to the business by providing an environment to allow for innovation instead of putting up another roadblock.

Get leadership tips in your inbox TechRepublic's IT Leadership newsletter, delivered Tuesday and Thursday, features blogs, white papers, and other resources for IT managers and CIOs. You'll receive advice on staffing, morale, dealing with day-to-day challenges, and much more. Automatically sign up today!
7 comments
caroline.mouton
caroline.mouton

How about using something like the Continual Improvement process (ISO/IEC 20000, ITIL, etc etc) that cunningly uses Demming's other contribution, the Demming Cycle, to ensure that innovation becomes a way of life but also supports the business strategy? It is a common mistake to look at misuse of toolsets and applications as the result of misplaced innovation. Misplaced innovation is the result of poor IT Management & IT Governance. Process before technology - always! Caroline www.carolinemouton.com

Osiyo53
Osiyo53

Good old Deming, a fascinating and interesting character whose ideas are well worth studying. And then re-studying on a routine basis to refresh one's memory. As there is a tendency for individuals to focus upon and adopt a few of his basic principles while ignoring others. Encouraging employee innovation can be a good thing. But is not without it's risks and possible adverse and unwanted results, as viewed from the aspect of the overall, bigger picture of things. This is one of the reasons Deming encouraged managers to try to achieve at least some knowledge of the "whole system" of the business they were engaged in. That is, understanding the overall processes involving materials suppliers, the producers of the goods or services, business's or organization's administrative functions, the sales force, and the end users/customers the of goods and services. The very reason that many of the Japanese businesses, who adopted Deming's philosophy early on, started a system whereby a new employee being groomed for a management position was required to spend some amount of time at each, or at least at most, of the various positions on a manufacturing production line. So that he or she had some idea of and appreciation for what it took to get things done, how that job fit into the overall big picture of things, and why in some cases certain things were done certain ways. Encouraging employee innovation CAN be a good thing, a very good thing. But that does NOT mean that one should adopt the innovation just because it looks good at the first blush. For instance, where I work we had an employee who seemingly always had the "better idea". And many of his ideas did have great merit. And this fellow had management's ear, as he had come to us highly recommended. In fact he'd been hired away from our competition. In the case of some of his "innovations", some of the other employees pointed out flaws and problems with his methodologies. But were overruled and their objections dismissed by management, who favored their "golden child". However, over time it was discovered that numerous of those innovations, once deployed and broadly used, had less than desirable side effects and consequences. They caused their own "bag of worms" problems that caused a lot of later effort to contain and correct. Management learned, and those employees that had previously given a warning got to say "We told you so." Net result is that now, in my field of work, where we work, new innovations are proposed, studied, discussed and examined not by management by but those who actually do the work. It merits and faults looked at. And if it is deemed worth a try, it is employed in a limited and controlled fashion, over time (at least months, sometimes a year or more) before it is again brought to the table for further discussion and examination by those who'll actually use it for some sort of final determination.

Lazarus439
Lazarus439

In a prior life, there was one employee in a division who produced the agency newsletter. The agency was a MS and Dec shopo, btw. He had a typical agency supplied computer with the standard suite of sofrware on it. However, since he never called IT, IT had no idea what he did or how he did it. Only after he was gone, and the division started crying to IT for help putting together the newsletter, did IT learn that the person had been doing it on a Mac at home. We, neither the employees in the division nor IT, had any Macs or any Mac expertise The division had to start from scratch to create the newsletter. This is the hidden problem of slipping something through agency/company standards: what happens when the person who loved the one-off program leaves? There's no corporate memory or expertise to fill in the hole.

Bizzo
Bizzo

The example you give about innovation is a very good one. But I don't think it really fits in with your initial statement. If I have 100 users and all they do is use MS Office, then any application support calls will be MS Office. Easy. If the users are allowed to install their own suite, I may have a mix of Office 2003, Office 7, Open Office, StarOffice etc. Not so easy. Also, I think that if users (especially the not-so-computer-literate ones) are given a choice, then that's where it will again cause issues. Simply because they don't have the knowledge or experience to make justified decisions. For example, if a "user" is given the option to have their account ask them to change their password every 30 days, and have a complex password, or have no password, what do you think they'd choose? Innovative, as it reduces support calls for password resets, but not secure. I do agree with the overall point though, especially if it is just a "one-off" piece of software. Things that are outside of the overall technical strategy, need to be thought about differently. New tools and applications need to be reviewed and then if accepted brought into the fold as "standard" software for that kind of user, or as a supported application for a one-off user. Maybe my views have become a little tainted from working in this corporate industry for so long, but standards are their for a reason, although yes, there should be a little slack for those that need it.

waltersokyrko
waltersokyrko

Adding one graphics package (or any other type of software) on an optional basis is not a problem. The problem occurs when every graphics user wants to use their own favorite graphics package. IT has to step in and do a cost /benefit analysis of graphics packages and choose one which becomes the standard. This takes longer; users will complain but it is the only way in the long run.

Tony Hopkinson
Tony Hopkinson

stepping in the path of innovation, certainly in terms of one offs. If you can make a business case for it, then you get it, if you can't, it's not innovative, and you shouldn't. Admittedly many instances of this sort of thing it's much easier to assess the cost than the benefit. But that's been a tech vs bean counter problem since Mr Abbacus stuck some clay balls on a bunch of reeds. You don't break standards, you change them, preferably for a sound business reason.

adams_john73
adams_john73

Totalitarian standards can certainly cause problems. Helping the business to understand the cost savings standardization provides should be the first goal. A robust and fair chargeback model for IT support is also a great way for business to understand the costs of custom solutions. I tell my business units, "Great, I'm glad you found a software solution that works for you and we would be happy to support it. However, since it isn't part of the standard software roll out, your group will have to pay for support on a chargeback basis." Now most managers will hate this suggestion because it affects their P&L directly. It can make it more difficult for them to make their numbers but it also empowers them to make sound business decisions and the ROI of the custom solution is theirs to own. With that said, your chargeback model has to be fair and easy to understand. It also has to be priced at a level that is lower than what the business unit can purchase from an outside company (if it isn't you have a cost problem in your IT department). When developing a chargeback model we used a research paper written by Gartner, I highly recommend it.

Editor's Picks