As I mature (or maybe just age) I increasingly divide the world into things-that-are-my-problem and things-that-aren’t-my-problem. Earning enough to pay my share of the mortgage and groceries is my problem. Figuring out how other people should live their lives isn’t my problem.

Keeping close track of what isn’t my problem has proved to be a wonderful stress reducer. Sadly, while this has worked very well for me personally, it isn’t an attitude that scales very well. Whether the subject is foreign policy or running an IT organization, any number of not-my-problem subjects turn into my-problem subjects with distressing but predictable frequency.

Foreign policy I generally leave to others, at least until a round or two of some conversational lubricant increases my perspicuity and persuasiveness. How to run IT is another matter.

And when you run IT, trying to make anything that happens in the enterprise not-your-problem is suicidal. One way or another, it all ends up on your desk.

Boiled down to its essentials, traditional IT is composed of operations, which runs the applications already in place; and programming, which develops, installs, customizes, integrates and maintains business applications. IT operations is, of course, entirely about supporting the rest of the business. As for programming …

If there ever was such a thing as a programming project, there isn’t anymore. Projects are always about business change. And while business change requires information technology, it’s merely a necessary condition for success, not a sufficient one. If nobody thinks through how the business should operate differently, new technology just won’t accomplish very much.

Which leaves IT with two choices: Include how the business should operate differently among the things-that-are-my-problem, or become a disinterested supplier to the rest of the business, content to deliver software that on paper adheres to the specifications regardless of whether it actually does something important.

Just an opinion: You’re better off choosing the former, largely because if you don’t, business change won’t happen and you’ll get the blame no matter what really went wrong. And you should. “The software worked. It isn’t our fault if they didn’t use it,” is, after all, an awfully flaccid excuse.

Business change only happens if someone is responsible for making it happen. IT is where the entire company’s operations meet in one place.

So if IT doesn’t take responsibility for business change, who will?

What should you do yourself and what should you delegate?

A few weeks back, Chad Dickerson and I disagreed in print about the importance of 802.11. Finding something we disagreed about took quite a bit of work, too — I hope you appreciate the effort.

We didn’t, by the way, disagree about whether 802.11 works. (I’m using it right now as I write this column on my deck. It’s downright nifty.) What we disagreed about is what’s worthy of a CIO or CTO’s time and attention. 802.11 is infrastructure, and when you’re leading IT, infrastructure is, in my view, something best delegated while you focus on strategic and tactical matters.

Chad didn’t disagree with this point. He disagreed with my definitions, stating that, “… anything that contributes to the profitability of an enterprise should be considered strategic.”

Military planning recognizes three complementary disciplines: strategy, tactics and logistics. To oversimplify a bit, strategy is about which battles to fight; tactics is about how to fight them; logistics covers procurement, maintenance, and transportation. These are military concepts. Their business usage is metaphorical, not exact, even if we agree that business is war.

At least as I apply this vocabulary in business situations, strategy describes the broad principles through which a company defines its choices, usually in terms of how it must change to meet the demands of the future. Tactics has two meanings — the specific actions through which a company plans to achieve its strategy, and its short-term plans for winning on today’s business battlegrounds. They’re complementary uses in that today’s wins should be structured to move the company into the future, as well as helping it survive until the future arrives.

I personally prefer the term “infrastructure” to “logistics” when talking about business planning for a simple reason: In business terms, infrastructure seems to say it better.

So why, when you lead IT, should you delegate infrastructure? Let’s go back to the military metaphor for guidance. As we all know, armies travel on their stomachs, so logistics is clearly important for winning wars. That doesn’t mean the great generals focused their time and energy on the details of bringing in grub, tents, and the other minutiae of logistics. From Khan to Napoleon to Rommel and Patton, winning military leaders left, and still leave that to others.

Winning generals focus on which battles to fight, and how to fight them.