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.

Worthington, Minn., claims to be turkey capital of the United States. Worthington has competition, though. Example: In his autobiography, Dennis Green, head coach of the Minnesota Vikings, described his plan to sue the team’s owners if they refused to sell him a 30 percent share of the company.

Since a) privately held companies have no legal obligation to sell themselves to head coaches; b) writing an autobiography when you’re as unaccomplished as he is reveals an ego as big as Green’s waistline; and c) when you play hardball politics you’re best off doing it covertly; Minneapolis gets to include Green in its turkey production total. And at 285 pounds, he compensates for a large fraction of Worthington’s turkey production all by himself.

While you’re in the mood for turkey, here’s another turkey story for you from a reader I’ll call Stan, who worked for “a major US corporation.” The words are mostly his — I’m lightly paraphrasing from his description.

Once upon a time, Stan was a front-line manager responsible for keeping a large number of PCs up and running in five locations. Stan instituted a preventive maintenance program, and logged the results to help him spot trends — information that came in mighty handy on several occasions.

Then his management instituted a new trouble calls process. Instead of end-users’ calling Stan’s department directly, they were directed to call the front desk, which in turn called the help desk at corporate headquarters, which then opened a trouble report and paged Stan’s department, alerting them to a problem occurring probably no more than a several dozen paces away from their office.

Stan’s analysts would then log onto the corporate mainframe, find the trouble report, assign it to themselves, change its status to open, and then fix the problem. Afterward they retrieved the trouble report, closed it, and reported their time (including the “administrivia,” which was usually more time than it took to fix the problem), and what they did to fix it.

One thing you get from an advanced help desk system is statistics. Lots of ’em. And so Stan got some feedback on the success of his preventive maintenance program: Of all the offices, his had the smallest volume of trouble calls.

You know where this is going. Stan’s managers were devotees of the if-you-can’t-measure-you-can’t-manage school of process supervision, but not graduates of the be-careful-what-you-measure-because-that’s-what-you’ll-get college of advanced techniques. They measured productivity by number of trouble calls responded to, and therefore Stan’s office was the least “productive.” Management could not justify paying three salaries for such an “unproductive” office and gave Stan 30 days’ notice. Stan predicts that when the trouble call volume increases for this office (as it inevitably will), management will be able to point to its statistics to show how cutting one salary raised productivity.

OK, let’s be serious for a minute. Stan’s management made two basic conceptual errors. First, it designed its new process around management reporting, not staff effectiveness. Management reporting became the goal of the system, not a desirable byproduct. Problem management systems must always improve convenience for end-users and be unobtrusive and helpful for technicians, or they’ll fail.

Far worse, though, Stan’s management confused internal process management measures with external, business results measures. “Trouble calls responded to” merely measures a departmental sub-process, not a business result. The business result is measured by end-user up-time, however it’s accomplished.

Stan’s management, obsessed by numbers, had no interest in the business result. (No, I won’t name the company. If I did, companies that might do some soul-searching wouldn’t bother.)

Oh well. At least we won’t suffer from a turkey shortage this Thanksgiving.