All Posts in Office Politics

|In: Office Politics|Last Updated:

I love golf.

I wandered through a golf show a few weeks ago, looking at gadgets, daydreaming of long, straight drives, and pondering the game as a metaphor for managing IS (not for the first time, either — see my July 8, 1996, column on the subject).

The obsession so many of us have with long tee shots is a good example. Just as most of us would be better off playing a five iron off the tee and practicing our putting, so many CIOs worry about aligning IS strategy with the company’s goals and vision while ignoring the real big-money issue — poor project execution.

So it was that I visited a booth selling custom woods (actually metals, good persimmon being unavailable these days). The purveyors of these fine clubs had a killer sales pitch: Rather than fix my slice-prone swing, they would sell me clubs that compensate for my deficiencies.

For a significant price, of course.

These clubs provide us with a lovely two-sided metaphor. On the one side we have executives who think nothing of spending a sizable fraction of their annual bonuses on these very same custom golf clubs and a supply of titanium balls, but who cheap out when it comes to providing a reasonable set of tools for IS. They believe better tools will help their golf games, but not their businesses.

On the other side we have IS weenies who are convinced that if they just had better tools, they’d suddenly become the ultimate code warriors, able to create magical applications in periods of time so brief that quantum effects predominate.

Examples of the former are easy to find: Data center managers who lack funds to implement network management, developers whose request for source management software is denied, even project managers who aren’t given basic project management software.

Examples of the latter are just as readily found: A friend of mine bought a PC-based Cobol compiler a few years back expecting to develop and unit test mainframe applications on it. A few minor problems cropped up after the money was spent: The systems it was purchased to support ran on top of a proprietary transaction manager and used a proprietary data compression system, neither of which would run on anything other than an MVS mainframe. Oops.

Then there are the fifty-buck tools that solve five-buck problems. In the early days of Unicenter, for example, Computer Associates boasted of its ability to stop batch jobs if available storage filled up, roll off some files to tape, restart the job, and restore the files at the end of the process. The sole design flaw: For the price of the software, you could have bought enough scratch storage to run any batch job you could imagine. Sometimes, brute force can be more appealing than elegance.

Business executives often complain about our buying technology for technology’s sake. The complaints are, for the most part, groundless. The applications IS deploys and manages invariably have a business purpose.

Except for tools, that is. Let’s face it: A lot of us have a yen for the latest and greatest software tools, just like some stereotypical husband with a workshop who wants a table saw or drill press.

How to make sense of requests for expensive tools? The answer is to eschew (gesundheit!) the use of broad principles. They won’t help. The only way you get a handle on this issue is to figure out your core processes first. These usually are (in order of importance): data center operations; applications maintenance; end-user support; system selection, customization, and integration; software testing; and application development. Understand your processes first and you’ll quickly understand which tools you need and which ones may be wonderful, but just don’t fit.

Oh yeah, just one more thing: While you’re busily giving your developers killer workstations with dual overhead cams, fuel injection, and turbochargers, also give them Pentium 133s with 32 MB of RAM to test their works of art. The P-133 is an important developer’s tool.

You’ll be amazed at how much having to use one will improve a typical developer’s code.

Comments

|In: Career Management|Last Updated:

Dear Bob,

I know this is a rather odd question, but I need your help with ManagementSpeak. No, it’s not translating it, it’s me translating to it!

I’ve been told that although I speak very well to and/or with end-users, I need to work more on talking with upper management. Three different managers have suggested this, so for the sake of my career and IS survival, I’m taking them seriously.

I’m pretty sure the very thing my manager wants is what you lampoon in your columns. Do you have any suggestions on learning how to translate into ManagementSpeak instead of your normal practice of translating from it? Just as important, can you tell me how to not snicker while I’m doing it?

Dancing around issues and trying to put a positive spin on everything, even when they are potential issues that need to be addressed, seems rather hypocritical. However, in the interest of my career, I have to at least try to overcome this particular “weakness.” Any suggestions, thoughts, or comments would be greatly appreciated.

– Talkin’ Trash in Tennessee

Dear Talkin’,

Here are a few suggestions that may help out. They may sound cynical, but they’re intended to help you be more persuasive, not manipulative. Use them with restraint, or you’ll go home every day feeling like you need a shower.

Rule #1: Never say “no.” You can present alternatives and estimate costs. You can explain that you don’t have the authority to say “yes” on your own. You can “see what the committee thinks about it.” “No” wrecks your image.

Rule #2: Never argue. “I think you’re wrong” just entrenches your opponent. If possible, make your own idea sound like a simple modification to your opponent’s moronic notion. If that isn’t possible, you can usually get away with, “I used to think the exact same thing. Then I ran across a book by Irving Slobodkin, and it made an interesting point.” That way you aren’t arguing — it’s Slobodkin who’s arguing.

Rule #3: Never present an idea as new or original. “I’ve read that some other companies are doing this [this being your great idea] when they’ve found themselves in this situation,” is far better. Why? First, new ideas are risky; “others are doing it” reduces the hazard. Second, nobody inside your company is allowed to be an expert. Why? That would make them better than the rest of us — who do you think you are, anyway? By quoting the experts rather than presenting yourself as one, you maintain the appearance of humility.

Rule #4: Find the upside. There are, after all, no problems, only opportunities. To avoid the cliche, make it a question: “How can we turn this to our advantage?” Many problems really are opportunities in disguise. Most are solvable challenges when faced with the right attitude but disasters when faced with the wrong one. (Don’t be asinine, though. The atmosphere gets icky when managers say brainless things like, “Don’t think of it as being unemployed and unable to feed your family. Think of it as an opportunity to broaden your horizons.”)

Understanding why you should follow these rules should help you keep a straight face and stay inside the fine line that separates diplomacy from stupidity on the one side and simple deception on the other.

Management has a lot in common with chess strategy. Each move you make has more at stake than achieving a single objective. Each should help you build a strong position as well. That means your speech should enhance relationships and alliance while avoiding the creation of antagonism or antagonists.

If all you want is to be right all the time, fine — just forget about your management aspirations. Being right is for staff. Leadership roles require you to be effective as well. Among the many skills this requires is the ability to present intrinsically unpleasant notions in ways that make them seem palatable.

Think of it this way: Somebody once figured out how to make raw oysters sound like a delicacy, not a pile of slimy goo. Sometimes, when you’re leading people, you have to achieve the same, seemingly insurmountable goal or nothing good will ever happen.

Comments