People who are attracted to the creative effort of new technology don't like procedural work. Don't let the desire for new gadgets develop into change for change's sake.
Any field dealing with gadgets and gizmos, from information technology to research science, has a tendency to attract gadget junkies. These folks have a love of new things, a passion for the latest and most innovative applications of man's collective intellect. In fields where pure creativity is the trading commodity, this drive must be fostered, sometimes to ridiculous extremes. In fields where repeatability, alignment with business needs, rapid delivery of services, and coherent responses are necessary, we sometimes have to rein in our inner geeks. More importantly, we have to balance the need to accomplish objectives in a rapid fashion against the need of our employees to be creative.
This conflict acts out along two related lines: the transition from creative to procedural work and the initiation of change for the sake of creative endeavor.
From creative to procedural work
One of my former clients described this transition to me one day. He said, "Shannon, you consultants get all the good work. You come in, play with the new things, explore a new environment, then get to leave and do it again somewhere."
What my client realised, but did not articulate, is that work in IT follows an extremely predictable pattern. All work starts with an unpredictable creative phase, in which we expend a tremendous amount of intellectual effort. During this creative phase, we explore new technologies, imagine ways to apply them, and slowly force our way towards a business answer.
Over time, this activity slows down. The product we create, which in theory answers a business need, moves off into that mythical world called production. It becomes part of the steady overall state, something that we need to be able to repetitively monitor and tweak. No matter how much energy we poured into it, the product is now just another part of our procedural world.
Unfortunately, the kinds of people who are attracted to the creative effort of new technology don't like procedural work. They regard it as dull and repetitive. The long, slow arcs of operational change strike them as being too calculated to be truly creative.
This steady discontent can lead them to simply ignore procedure, guiding the operational organisation down into a world of heroics and constant pressure. In more organised environments, though, it leads to the second axis of conflict.
Change for the sake of creative endeavor
In reasonably controlled environments (development, infrastructure, or telecommunications), people realise that they have to have repeatable procedures. If nothing else, the incredible pressure to be effective over the last few years has driven people to it. They might not like it, but they do try. Their desire to engage in creative activity leads them to the most insidious of all possible activities: the technology "refresh."
These projects purport to provide greater benefit for the organisation by updating the technology behind a specific service. Sometimes they're grand projects with sweeping goals and vision. Other times they amount to nothing more than so-called "incremental upgrades" produced by developers to modify currently working code.
This kind of behavior manifests itself in a variety of ways, including:
- The introduction of new technology over existing, working, and expandable systems. This can range from taking the latest, unknown new software tool over an existing and working system to the purchase of new disk frames when the old ones have not yet reached 15 percent utilisation. These changes are almost always justified as "technology upgrades."
- Constant tinkering just to tinker with configurations. This is one of the oddest phenomena, and one that we just accept as "part of doing business in IT." I wish my clients would pay me for every time I've watched someone explain that they changed something "just to see what would happen." I could have retired by now.
- Obscure operational configurations, designed so that no one knows what the employee is actually doing at any given moment. This allows the operator, consultant, or whomever to constantly reinvent the wheel. I usually hear "but the product is different every time" when I encounter these things. Let's face facts though, generally operational systems don't change that much. If we have to completely reinvent our procedures, tools, and processes every time we perform a simple operational task, change is occurring for some other reason.
Although it may look like it, I'm not advocating that managers distrust their employees. Nor am I saying that all change in information technology is necessarily driven by some obscure psychosis.
What we need to do is ensure that changes are occurring for reasons other than our own desire for stimulation. Valid reasons for change include reducing real operational costs, gaining access to a new feature tied to a business need, or other similar budgetary effects. We might also consider changes that upgrade our productivity (taking a few hands out of an operational task) or shift operations tasks to lower-level employees (reducing their overall cost).
Applying the model
By looking at proposed changes in terms of the employee's position on the arc of creative to procedural work, we can get a feel for how likely it is that he or she is initiating change for change's sake. If the employee's doing primarily procedural work, with a static tool set, discontent is likely to be high. If he or she's working on new products constantly, the inner geek will be well-fed and less likely simply to initiate change for no reason.
When we face change just for the sake of change, we need to ask ourselves:
- Does this change generate any exposure for the organisation? If not, the change probably should go through. It represents a net-zero change for us, with the possibility of generating a positive result.
- If the change generates an exposure (budget, security, or productivity loss), can we justify it? Here we get into a classical risk vs. reward analysis. The lower the risk, the smaller the reward we need to consider.
- If the change generates a high exposure (say, replacing a working database interface solution with a new one), is there some other way we can meet the employee's creative need? Are there lower risk items we can change, or ways that we can engage the person creatively?
Understanding this drive for change as part of a basic cycle allows us to avoid either mystifying it (leading to a vast amount of literature about leading geeks) or ignoring it. IT employees are no different than any other creative group; they just have shinier toys.
TechRepublic is the online community and
information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for
IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis,
downloads, management tips, discussion forums, and e-newsletters.
©2003 TechRepublic, Inc.
