Every so often I think about taking the bus. I’d like to be socially responsible, reducing our country’s dependence on foreign oil imports and lowering my personal contribution to atmospheric pollution.

Regrettably, my irregular schedule discourages the practice. After 5pm, the bus runs only once an hour, and if you’ve ever stood outside in a Minnesota bus stop in January, you understand the limits of social responsibility – and of centrally-controlled, shared resources.

Yet Larry Ellison, Scott McNealy, and Lou Gerstner all want me to embrace the network computer (NC) which, bus-like, will impose unnecessary and unwanted constraints on me.

The NC concept rests on false assumptions (FAs, to use the technical term). Among them:

FA #1: The NC and Thin Client are related: Nope. “Thin client” is a software architecture. Three-tier client/server architectures partition applications into independent processes handling presentation logic, “business logic” (a catch-all for a variety of different functions) and database services. You can implement thin-client applications on PCs. Heck, you can run everything on the same desktop PC and still have a thin client. It’s software, not hardware.

By the way, do you think “thin client” would be so appealing if they’d called the alternative a “thick client” or “muscular client”? And would it still be a “fat client” if it ran QNX or Linux instead of something flabby like Windows? I doubt it. This isn’t a dialog. It’s name calling.

FA #2: The NC and Java are the same thing: Well of course not. A PC can run Java code just fine. Not only that, but you can upgrade a PC with a better just-in-time Java compiler, language revisions, bug-fixes, and other stuff like that.

FA #3: The PC has huge hidden costs: This takes more than a one-paragraph tirade. A hint: everything written on the subject is a cost analysis, not a cost/benefit analysis, not a cost comparison with alternatives, and not the only analysis that matters: a cost/benefit comparison with alternatives that provide equivalent functionality.

FA #4: Java is portable: Wait a few years. You’ll have new models of the NC with enhanced functionality. You’ll have proprietary extensions. You’ll have competing, incompatible NC architectures. Suppliers differentiate themselves from each other, because if they don’t they’re selling commodities, and commodities have razor-thin margins.

FA #5: The NC has no hidden costs: Once you buy into NCs you’ll need more bandwidth, bigger servers, and more sophisticated network, server, and applications management.

Why do you think IS installs applications on PC hard disks instead of servers now? It’s the bandwidth needed to download DLLs from servers. Download a DLL, download a Java application, what’s the difference? Java doesn’t magically shrink the size and complexity of a word processor or spreadsheet.

And since the NC is simply a paperweight when the network, server, or application crashes, you need better management of all three. Clue: who wants to sell you the servers and management software?

Here’s why the NC won’t succeed. People bought PCs specifically to gain independence from control-oriented IS organizations. The PC freed employees to do what they chose, not what IS decided they should do.

The claimed benefit of the NC is its greatest hidden cost: With it, IS morphs back into the god of software, arrogantly dictating what end-users can and can’t use. If the NC succeeds, end-users will simply re-invent the disconnected PC or independent departmental LAN, so they can do what they want, instead of what IS lets them.

Technology doesn’t only follow business requirements. Sometimes it creates business opportunities, or leads to unexpected business results.

Adoption of personal computer technology in the 1980s led inevitably to employee empowerment. Look at the arguments in favor of the NC and you’ll discover a thinly veiled attempt to disenfranchise employees again.

As is true so often when you peel the onion a bit, it’s enough to make you cry.

Since sports metaphors are popular among management consultants (yielding grossly inflated speaking fees for washed up sports figures in the bargain) I always love hearing interviews with the coaches of losing sports teams. I’ve synthesized a typical example:

“Ed Jones just didn’t play very hard this game,” complained the coach. “And John Smith demoralized the team with that interview he gave you reporters yesterday. If he’d spend more time trying to hit the ball and less time spouting off, it would give the whole team a lift. And then there’s Jim Johnson. Sure, his stats look good, but he’s grandstanding. He needs to be more of a team player.”

And on, and on. If I had a manager who publicly berated his staff like that I wouldn’t bother firing him.

I’d hire a recruiting firm to sneak him into my fiercest competitor instead.

And then there were the professional football players in the late ’80s, who arm-twisted the concessionaires into supporting their strike. The next year, when the concessionaires went out on strike, do you think the football players supported them? Not a chance.

This may be one of the more useful crossover lessons from professional sports to business leadership — say what you have to in order to get your way, then conveniently forget it when it becomes bothersome.

The first time I was exposed to “employee involvement” our visiting consultant, diluting his sports metaphors a bit, explained how it would transform the role of the leader: from decision-maker and expert to “coach and mentor”.

Now there’s an energizing concept.

You still hear this nonsense every so often, so let me clear it up once and for all: coaching and mentoring are wonderful ancillary qualities for a leader. The job, though, consists of setting direction, establishing priorities, and clearing away every obstacle to success.

Somebody famous once contrasted management and leadership as “doing things right” vs doing the right things. I’m not sure I agree. I think leadership makes sure decisions get made; management makes sure jobs get done.

Making sure decisions get made isn’t the same as making all the decisions, and the most important difference between good and bad leadership is decision style. There are four ways to make decisions: Command (you just make it), Consultative (you ask a lot of people, then make it), Delegated (you give it to someone else to make), and Consensus (you ask everyone involved to make it together).

The worst leaders make a lot of command decisions. Command decisions make sense in a crisis (there’s no time to ask anyone else) and when the leader knows so much more than anyone else that other opinions add no value. Leaders who make lots of command decisions either have lots of crises (bad leadership) or weak, untrained staff (bad leadership).

Good leaders make a lot of consultative decisions. Gather a lot of facts, ask for a lot of competing opinions, and you’ll be a lot smarter about the choice you have to make.

Good leaders delegate a lot of decisions. Figure out the best person to make the decision and give him or her ownership of it. You’ll deal with less detail and the delegatee will grow with new responsibility. (Now, you get to help that person figure out which of the four decision styles to use. In most cases, I’d recommend the consultative style.)

Reserve consensus decision-making for very special situations. Consensus decisions are expensive and time-consuming. Use consensus processes when (a) you need everyone involved to own the decision; or (b) you’re leading your peers to a decision nobody has the authority to make.

If you find yourself trying to do everything by consensus, you’re not leading. Quite the opposite, you’re avoiding leadership, playing it safe.

You’re making sure you can blame the team.