I once wanted to invent an exercise machine that plugs into a standard video game port. The idea was to transform the fundamentally boring process of working out into utter absorption: When Pacman won’t move unless you’re pedal, it’s exercycle or be eaten.

Sadly, the Patent Office has already awarded a patent for this idea. Meanwhile, the intranet has recently rendered the only other invention I’ve ever wanted to build … the PrinterShredder! … obsolete.

The PrinterShredder!, like most brilliant concepts, is obvious once stated: Since most printouts are recycled without anyone ever looking at them, businesses could save a lot of money by eliminating the wasted steps, immediately recycling the output as soon as it is created. (Not to mention the PrinterShredder!’s impact on security — valuable company secrets would never leave the data center.)

But now we have the ability to publish print jobs as HTML directly onto our intranets, where everyone can ignore them at the speed of electricity (about 33% of the speed of light … but I digress).

It has been common practice for budget-driven data center managers to turn off suspect print jobs periodically, turning them back on only if someone complains. Often, this is the only way to find out if a job is needed. But as storage drops below a penny per megabyte, it is now less trouble to just dump everything out there.

This is the same thinking that lead to the Lincoln Navigator. When any resource is overly plentiful, we get sloppy in how we use it, whether it’s gasoline leading to over-sized, inefficient cars, the immensity of the sky leading to atmospheric pollution, or cheap processor cycles and storage leading to “kitchen sink” intranets and Web sites.

When we get sloppy we face unintended consequences. Fuel-inefficient cars increase demand for fuel so gas prices rise … but we still own the Navigator. Atmospheric pollution leads to global warming, ozone depletion, and pulmonary disorders … but our whole economy rests on the processes that generate pollution. And when you just dump reports onto your intranet, you make it that much harder to find anything useful, because you’ve made the signal-to-noise ratio worse … and you probably create new jobs for analysts to sort through the muck.

The problem is that cheap storage is the wrong focal point for our attention. We should be taking advantage of our intranets’ real-time processing and highly visual nature to create “dashboard reports”.

As with so many user-interface issues, your daily driving experience tells you most of what you need to know to understand dashboard reporting. What, after all, does your dashboard display? Exactly what you need to know to drive safely without damaging your car. It isn’t just exceptions, nor is it only summary data. It’s neither entirely graphical nor entirely textual. Nor is it uniform: Some dashboards are designed for more sophisticated drivers than others, presenting both more and more detailed information.

But it’s always what the driver needs to know, while driving, designed for easy interpretation at a glance.

Which leads us to the tough part. Over a span of nearly a century we’ve learned what drivers need to know at a glance, filtered by what we can build into automotive dashboard displays. No such consensus exists for a business dashboard, so you get to figure it out.

Next week’s column will give you some help.

News flash!

In another case of psychologists proving what we’ve long suspected, Justin Kruger and David Dunning, publishing in the Journal of Personality and Social Psychology, demonstrated the inverse correlation between actual ability and self-assessment.

The better employees think they are, the worse they actually are and vice versa.

Armed with this little factoid, I expect battalions of mediocre programmers to immediately try to improve their ability to write good code by adding humility to their conversation. While the humility, however insincere, will be a welcome change, it will start a tiresome variant of the decrepit “You only thought I knew that you knew that I knew that you knew” gag.

But I digress.

I just read another version of the “CIOs need to know the business” article. I think there’s just one article on the subject, and when a writer is feeling tired he pulls it out, shuffles some paragraphs around, e-mails it in, and goes back to sleep. They’re all the same, really. They make the hoary point that businesses don’t want technology for technology’s sake — technology must serve a business need, and successful CIOs will embrace this concept.

Some insights are more startling than others, I guess. But before we go on, let’s all hold hands and chant together: “Yes, CIOs must know the business, and never propose technology for technology’s sake.” Maybe if we say it loud and proud a few times, everyone in earshot will understand that we’ve fully grasped this concept, and we can all move on to the next one.

The next one, made many times in this space, is that “knowing the business” doesn’t begin and end with abstract notions like strategies and business models. The most important part of knowing the business is knowing the interests, hot-buttons (and cold-buttons), pet programs and pet peeves of every important decision-maker in the company. At least half of an average CIO’s time is spent selling. It’s internal selling … to the board of directors, CEO, senior executives, middle managers … but selling nonetheless.

If you don’t like the idea of having to sell internally, find a different word that describes the process of persuading others to adopt your concepts, in the process adding money to your budget.

If it looks, waddles, and quacks like a duck, it’s a duck. If it looks, smells, and tastes like selling, it’s selling.

To sell effectively, you need to understand your prospects on an empathic level. You need to understand the business, formally, politically, and personally.

Why, oh why do so many seemingly sensible people jump from here to the ridiculous notion that the CIO can delegate the “understanding technology” part of running IS to subordinates? Would anyone reach a similar conclusion down the hall a few doors, and figure the CFO doesn’t need to understand accounting, just “the business”?

Of course not. Of course, they’d probably reach the right conclusion for the wrong reason, explaining that at the end of the day … or at least the fiscal year … the money is the business. Robert McNamara, overconfident of his ability (sound familiar?) due to his business resume, used a similar thought process in pursuit of victory in Vietnam, running a metrics-driven war in which relative body counts (profits) mattered more than the formulation and execution of strategy and tactics.

CFOs need to understand finance and accounting because they run that part of the business and they need to understand the discipline. CIOs need to understand information technology because that’s what they’re responsible for. This isn’t a complex concept, nor should it be controversial.

Go back to the idea that CIOs spend a lot of their time selling. What do really great sales people do? They paint a persuasive vision of how great your world will be once you’ve incorporated what they’re selling into it.

What’s the first step? Understand what you’re selling. In the case of a CIOs, that’s information technology. Without that knowledge, no matter how good you are at step two — understanding your prospects’ world — you’ll have no way of progressing to step three: Putting that knowledge and your product together.