In the beginning was Electronic Data Processing (EDP). In EDP we wrote computer programs to automate business processes. Ignorant about methodologies, we just talked with the people who were going to use the system, figured out together what it should do, and tweaked things until everyone was satisfied. Eventually these programs turned into legacy systems.

Like baseball managers, most of whom once played the game, the guy who ran EDP was a former programmer who could talk to the company’s business leaders without scaring them. A lot of his conversations started, “Didja know …” as in, “Didja know we could automate that and save you a lot of money?”

Then database management systems happened, and some genius decided our real job was to manage information – a clear case of confusing means and ends. EDP became Information Systems (IS), the person in charge became Chief Information Officer (CIO), and theorists inflicted bulky methodologies on project teams. The result? Long delays before the writing of actual code, and an organizational hierarchy to separate programmers from the people who need their product.

Along the way we gave up on the baseball manager theory of CIO selection. Instead we focused on the need for “business knowledge.” If that wasn’t bad enough, we defined “business knowledge” as “understands how to perform a Return On Investment (ROI) analysis”. We got what we asked for: Late, bloated projects, fictional ROIs, and a management-fad orientation leading to the belief that late projects and fictional ROIs are fine so long as we “satisfy our internal customers”. Mired in these time-wasters, most CIOs missed the Internet. Oops.

So now we have Chief Technology Officers (CTOs).

Sometimes the CTO is the CIO’s peer, with the former focused on the Internet and the latter on everything else. This is worrisome from the organizational design perspective because it has strong potential for dividing accountabilities.

If your company insists on having both titles, minimize conflict by giving the CTO application-layer authority only, but responsibility for all customer-facing applications, not just the Internet. Why? If your CTO owns the Internet, your Telecommunications Manager (presumably re-titled to “CVO” for “Chief Voice Officer”) will own your interactive voice response and call centers, another bizarre title will own sales force automation, and the chance customers have of getting consistent service across all channels is exactly zip.

In most companies, though, CTO is the new title for “the person we hold accountable for all of our computer stuff”, accompanying a name shift from IS to IT. “CTO” implies rejection of a lot of the intellectual baggage we’ve accumulated since EDP first changed its name.

Like the EDP manager, but not the CIO, the business wants its CTO to have a strong technical focus, because that’s how you figure out what the business can do today that it couldn’t do yesterday. And where EDP lacked formal methodologies, in the CTO’s world they exist but they’re pretty lightweight, because the ones we’ve been using are way too slow. Mostly, programmers work with whomever to design the customer interface, then work backward to design the system’s innards.

Best of all, CTOs reject the whole, ridiculous concept of “internal customer”. They’re far too busy worrying about real ones.

Risk was popular in college. A realistic game of global geopolitics, winning it depended on alliances, betrayals, and favorable rolls of the dice. I was never very good at Risk, and instead spent most of my time playing chess or bridge, at which I achieved adequacy.

I did win one game of Risk, though. It was against the two best players in the dorm, too. How? My friend Steve and I agreed in advance to not attack each other. The simple expedient of a reliable alliance outweighed all other considerations. We divided the world in half and quit, to the chagrin of our defeated opponents, who, irony of ironies, described our simple tactic as cheating. Apparently honoring a commitment violates the rules of Risk.

It also violates some of The 48 Laws of Power, the unwholesome but highly useful reference recommended in last week’s column for anyone who wants to achieve influence in a large organization. While considerably more shallow than Machiavelli’s The Prince, Sun Tzu’s The Art of War, or even Anton Jay’s Management and Machiavelli, The 48 Laws of Power has the advantage of painting-by-numbers: It’s formulaic and easy to follow.

If the book is so unpleasant, why is it important? Simple: As a wise man once said, the only thing worse than having to play stupid games is losing at stupid games you can’t avoid playing. Even if you eschew these techniques yourself, if you can’t recognize their use by others you won’t be able to nullify their effects.

The book is missing something important: An indicator … a thermometer bar perhaps … to indicate which laws are novice, intermediate, and advanced techniques. This would be helpful because many of this book’s suggestions require significant finesse for success.

Let’s imagine for a moment that you have no scruples. You buy the book, study the laws, perfect your technique, and so begin your meteoric rise to the top of your company. Chances are good that even as your career advances, your ability to lead will decline.

Evaluate each Law on its own merits — to be fair, some are the essence of leadership. Laws 28 through 30, for example, recommend that you “Enter action with boldness,” “Plan all the way to the end,” and “Make your accomplishments seem effortless.” This is good advice: Timidity is worse than inaction, you should always define the goal before taking the first step, and you should never let anyone see you sweat.

Other laws, though, impair your effectiveness as a leader. For example, concealing your intentions and saying less than necessary — Laws 3 and 4 — may confuse your rivals and prevent them from preparing a defense. Regrettably, it also confuses those you lead, and confused soldiers rarely win battles.

Taking credit for the work of others (Law 7) and creating a state of terror (Law 17) are also dreadful leadership techniques. They lead to sullen teams with no initiative or drive.

The very techniques that help you achieve power prevent its effective use.

The worst aspect of The 48 Laws, though, are their potential for poetic justice. Follow them yourself and you encourage their use by those around you.

And some of them will be better at the game than you are.