Once upon a time, corporate IT people usually had only "the System" to worry about. The distinction between hardware, operating system (O/S) and application (app) was not so stark. Often your mainframe only ran one visible app, which made heavy use of O/S-specific features and the O/S relied heavily on particular features of its hardware.
Whether the System was largely homegrown, or bought commercially, it was around for a while and its minions learned to tend it faithfully. There were even gurus who actually knew just about everything there was to know and who could extend the system if that were required.
As time has gone on, the typical corporate IT infrastructure has become vastly more complex and vastly less stable. It is less stable in both senses of the word: it changes rather frequently and it often behaves in ways one would not have chosen. By this, I mean that its behavior is the sum total effect of all those parts and the net effect was not planned or specified, it just happened.
Because it is often my job to deploy custom-made technology to bridge gaps between existing pieces of the infrastructure, I am frequently in the position of exercising existing pieces in new ways. This is rarely a happy place to be: current IT comes in chunks so big and so complicated that it is rare to find that anyone knows what will happen when configurations are changed and previously inactive features are turned on.
When things do not go as planned, I am frequently in the position of asking in-house staff to investigate issues and perhaps even resolve those issues. There are two happy endings to this story and one unhappy ending.
The first happy ending is that the in-house staff are expert in the particular technology and they either get it to work or tell me how better to interact with it.
The second happy ending is that the in-house staff have a good relationship with the vendor and the vendor is competent to support their own products and the vendor either gets it to work or tells me how better to interact with their product.
The unhappy ending is that the in-house staff do not feel ownership of the offending piece of IT and they just shrug when I ask. In other words, they feel that the malfunctioning infrastructure is someone else's problem (SEP).
Once we feel that something is SEP, we are content to just shrug or, almost as irritating, sympathize but do nothing else.
I suspect that the SEP effect is, at least in part, generated by the Big Purchase phenomenon which I have discussed in a previous posting.
I am pretty sure that "wrong sizing," whereby a workforce is reduced below feasible levels and people are told 'do more with less,' is also a major cause of the SEP attitude. Unclear lines of responsibility, overwork and under appreciation certainly do not help.
But I am not sure and I am not sure that it matters. Once an environment is permeated with SEP, it is very hard to get anything done. Specifically, SEP leads to the following situations:
- The in-house staff, unwilling or unable to contact the vendor, bombards me with half-baked theories and half-baked solutions, hoping to get me to go away.
- The in-house staff points me toward some documentation or irrelevant email from the vendor. See, here's your useless answer, now go away.
- The vendor invites me to a conference call during which they try to convince me that I should not be doing whatever it is that I am doing. This is like the old joke about lazy doctors: Patient: Doctor, it hurts when I chew on the left side of my mouth, what should I do? Doctor: Don't chew on the left side of your mouth.
Once I find myself in any of these situations, I have only one strategy that works me: relentless but polite pursuit of well-defined, simple goals. In my case, this often means taking up medieval quests:
- actually wandering around an organization to follow up emails
- camping out in people's cubes
- talking anyone upon whom I am fobbed off until they send me down the line
- filling out whatever forms need filling out
- taking whatever conference calls I need to take
- disproving whatever theories I have to disprove
Even though I can cope with it, there is an aspect of this situation that I find tragic: I am watching formerly motivated, useful IT types become deadwood as SEP seeps into their careers. As they become comfortable saying the following tired phrases, they don't realize that their coworkers are writing them off as useless:
- "I don't know anything about that and I don't know who to ask."
- "We just set up the database, I don't know how the data gets in there."
- "We used to do it all ourselves but now the Networking / Security / Server / Database group does that."
No comments:
Post a Comment