Wednesday, March 26, 2008

Change is good -- even when becoming "non-technical"

Ever notice the way the paradigm for “job skills” changes?

I spent years as an individual contributor, becoming valuable to a few employers because of intricate, exotic knowledge of the idiosyncrasies of a few applications (whether monthly and daily billing in a credit reporting company, or reading the documentation in Propac and matching it to COBOL code on Medicare reimbursement, or the salary deduction billing and report stacking, or the interfaces between the mainframe and a USPS computer for NCOA processing). The company would depend on me to get through the latest crisis (“end of month’s on fire”, or keeping a skittish client who doubts the accuracy of some tables, or getting through complicated interfaces). Professionally, I would have a unifocal world, and not miss what the rest of the world of work does, although I kept tuned to current events in the broader sense (especially the political issues).

Managers, I thought, were “expendable.” And sometimes, in the 80s and early 90s, with the pyramid flattening and expanded “span of control” that became popular after corporate buyouts and mergers, "middle management" did become layoff fodder. The companies believed they depended on the “super-indians” to keep their shops running. It was important to have those real “hands on” skills.

I have to say this has caught up with me. “Turnabout is fair play,” perhaps. (“Turnabout” was an important classic music budget label for years.) Now, the “skills” are more about integrating a lot of different bits of technical disciplines in order to get my own content ready to sell. How often, however, when there is a problem at my ISP (as with my Urchin stats not running), I find that I feel I know more about how to solve their problem (for example, how automated replication schedules work) than does the tech who answers the phone. If only I had a job there, I could get my own problem fixed! (It’s a tautology: support is support!)

But I also appreciate better, now, why “management” was so often “non-technical.” Right now, in running websites that are content intensive, I find that there just is not time to keep up the intricate hands-on coding skills (in, for example, java) at a level that commercial shops need to require. Early in my career, the pace was slower, and there was “time” to perfect COBOL and JCL, and even then the techniques used (structured programming, whether to do random-access or to sort and process sequentially – usually faster) could get ahead of one’s work and vision. Things just change too quickly. Hence, it’s likely some day I will wind up the shoes of “management,” but hopefully with something that I created.

What do they say: Change is Good!

No comments: