All Posts in Leadership

|In: Industry Commentary|Last Updated:

In all the world, there’s nothing more irritating than someone stating obvious, widely accepted, and often wrong or misunderstood conventional wisdom as something profound.

“People need to take personal responsibility for their actions!” I recently heard an acquaintance declaim to a group of us in terms that left no doubt this was a Highly Original Thought (HOT).

Other statements that are currently HOT:

“We should build this application using a thin-client architecture.” (Usually said by people who have no idea what a thin client really is.)

“The mainframe is just the biggest server on the network.” (No, that’s just one of its roles, unless you no longer run batch jobs on it.)

“Our technology investments will be driven by business needs … we’re not going to invest in technology for technology’s sake.” (Gee, do ya think?)

This last statement usually comes from technophobes who wouldn’t recognize the business benefits of technology if those benefits were listed as a line-item on the profit and loss statement, or by defensive technologists conditioned to cringe by years of dealing with the aforementioned technophobes.

And the fact is, it isn’t a very smart statement to make.

It isn’t that the statement is wrong, exactly. Often, inefficiencies or changes in strategy really do lead a businesses to recognize the need for new technology. On rare occasions, that need can drive vendor innovation, as opposed to simply causing IS to buy existing technologies. It can happen.

What this view ignores, however, is that usually new technologies create opportunities for process efficiencies, for improving customer relationships, or for defining whole new markets and marketplaces within which your company can do business, and these aren’t opportunities business executives foresee.

Let’s take a simple and obvious example. In the mid-1970s, world business didn’t approach any of the fledgling PC hobbyist groups saying, “You know, if one of you would just create an electronic spreadsheet program for us, we’d buy millions of personal computers just to run it.”

More recently, Tim Berners-Lee adapted SGML, sponsored by the Department of Defense to facilitate creation of electronic documentation, to the needs of the international physics community. By doing so he invented the World Wide Web and a new multibillion-dollar vehicle for commerce. Business executives didn’t drive the creation of the Web. Most have responded to it nervously, as something they don’t particularly like but probably can’t entirely avoid. Even now only a visionary few recognize it as a huge, still-to-be-defined opportunity.

Chances are high that the requests you get for new technologies and information systems from heads of departments or business units will lead to business improvement if you execute well. That’s important, and not to be taken lightly. It’s only part of the story, though — the part where your company follows others who are the industry leaders. In other words, investing in technology in answer to business requirements is a survival response, not a growth strategy.

A similar principle holds on a macroeconomic scale, by the way. For evidence I offer an extensive analysis in the September 28, 1996 issue of the Economist, which says, “… per-capita growth in output is doomed to be zero — unless the economy is making technological progress.” (Thanks to reader Linda Donaghue for directing me to this fascinating article.)

Business doesn’t drive technical innovation. It only pays for it. Business people usually can’t envision the value of something they’ve never encountered before. That’s why CIOs who wait for the rest of the company to ask for a new technology earn their reputation as sand in the gears of progress.

Yes, technical innovations must create business value. And no, not every technical innovation will create value for your business. You have to be able to recognize what’s really HOT.

That’s what makes the job interesting.

Comments

|In: Leadership|Last Updated:

Everybody reacts to certain sounds in ways that range from cringing to anaphylactic shock. It may be chalk squeaking on a blackboard, fingernails scraping a screen, or even two pieces of corduroy rubbing together.

For me it’s the fingernail/screen combination. If I’m ever captured by an enemy bent on learning all of my secrets (both of ’em!), all they’ll have to do is brandish the screen in front of me. I’ll cave in an instant.

Sometimes whole sentences can cause just as intense a reaction. Many InfoWorld readers react to various examples of ManagementSpeak like those that begin this column. (Me too.)

Another source of acoustic chafing: People who tell you what you’re thinking and feeling (“Don’t get defensive,” is the perfect example, requiring extraordinary self-restraint and conversational dexterity in response). Deal with what I say and do, pal. I’m in a better position to describe my thoughts and feelings than you are.

There’s a new kid on the block that puts the others to shame. It goes like this: “The technology is the easy part.”

I hear people say this all the time these days. These people have never written a line of code in their lives, of course, and that may explain why they’re so comfortable saying it while calling programmers “bit-heads” and “nerds.” For them, technology is the easy part. They get to toss out high-level, fuzzily stated requirements. Then they sneer at programmers who bug them with questions, using the popular put-down: “Clearly you’re not comfortable dealing with ambiguity.”

There’s not much point explaining that it’s C++, not you, that’s uncomfortable dealing with ambiguity. These characters are so busy being self-important that they don’t have the time to deal with a mere technologist, who after all gets to deal with the easy part of the problem.

With a little less arrogance and a bit more patience, these important businesspeople would learn that they do indeed have a very difficult job, which they often shirk. That’s the process of clearly and unambiguously defining what the business needs. Usually, this means creating a detailed picture of a business process that doesn’t exist, along with every resource that process will need to be put into practice.

That’s hard. It requires, time, thought, and patience, so it usually goes undone.

Yes, when business planners do their jobs well they make the job of the technologist easier. Not easy, but easier. Somebody has to take the big picture and refine it into the kind of detail a data designer can translate into a schema and a programmer can translate into code. Too often, the people who end up having to do the refinement are the programmers and data designers, who collar the business planner in the hallway to ask annoying questions.

I’ve known IS programmer/analysts who have been assigned to a new business unit to “create the technology” and instead have designed every key business process along with defining the technology, up to and including the invoice design.

(Which, by the way, points to a solution. Place a programmer in a business area, actually doing the work. That puts the programmer in a great position to envision, and immediately build, efficient, technology-centered work processes. Try making this an endorsed system-design methodology.)

The devil is in the details, of course, and the ultimate level of detail is the actual code. It takes talented programmers to write good code that gets the job done. I guess it’s because the devil is in the details that so many businesspeople simultaneously denigrate and demonize the technologists who translate their “important concepts” to reality.

Comments