I’ve written before about how I value Twitter’s ability to fine-tune one’s personal information gathering, selecting people to follow who, over time, prove to be the most useful, interesting, and stimulating. I commonly refer to the people I follow as my “personal Algonquin Round Table,” in homage to the well-known literary group of the 1920s.

More simply put, though: I value Twitter because I fundamentally believe in consulting others, picking their brains, observing what they find useful or funny, enjoying their (often differing) perspectives, and learning as much as I can from them.

To my frequent surprise, however, this basic belief in the value of consulting others turns out not to be universally shared. In fact, it can even be scoffed at. That disconnect came glaringly to light recently in the aftermath of the death of Steve Jobs. Basically put, the burgeoning legend of Steve Jobs rests in large part on how, in his path to multiple successes, he fundamentally rejected the value of consulting others.

Particularly in the days immediately following Jobs’ death, an incredible spate of adulatory articles and posts emerged, lauding this legendary refusal to compromise (“Machines and robots were painted and repainted as he compulsively revised his color scheme” ), his attention to the most minute of design and implementation details, his insistence on molding every aspect of his company’s products and culture.  It was widely quoted how he scoffed at the idea of focus groups and obtaining user feedback:

• Caron Carlson, “A novel look at the CIO’s need to lead”

• Elliot Ross, “Book Review: Haunting The CEO”

Novels are harder than most technology-oriented people typically realize. The backbone of a good novel is character development, meaning that the character learns and grows — which makes it easy for especially amateur novelists to start off with a character who is, frankly, little more than a one-dimensional dolt. This is an even more dangerous pitfall when it’s a “novel of IT”: the temptation is almost unavoidable for the author to create as protagonist a stereotypical technology leader, clueless as to what is really important or how to be effective, who is then gradually enlightened by wiser individuals as the novel progresses.

There are three IT-related novels I’m aware of, all relatively recent, that fall essentially along those lines.

• fruITion: Creating the Ultimate Corporate Strategy for Information Technology, by Chris D. Potts
• Adventures of an IT Leader, by Robert D. Austin, Richard L. Nolan, and Shannon O’Donnell
• Haunting the CEO, by John Hughes

All of them are worth reading, but I had majorly different reactions to each. While I’d intended to cover all three in one blog post, the complexities involved in discussing the first, very problematic example have led me to divide this discussion into more than one post.

Not everyone is a fan of fiction, though: why read any of these novels? In my view, the veneer of fiction, of semi-realistic dialog and interaction among the typical players in business-IT situations, promises a degree of engagement and entertainment, as well as the chance to obtain a deeper understanding of how and why the involved parties interact they way they do. Ultimately, I’d want such a book to provide me with insight, in a “show not tell” kind of way, into what motivates the typical players in these business scenarios, and to depict a healthy growth of character and role that lets me understand my own situation and how better to foster collaboration, synergy, and business effectiveness. Beyond the superficial, the events of a novel and the utterances and interactions of its characters can eloquently illustrate various approaches and philosophies, often more forcefully and meaningfully than would a straightforward treatise.

As a CIO, I’d want to be able to hand the novel to my CEO or CFO.

In fact, a fundamental purpose of quality fiction is to enable the reader to live and understand another perspective. So primarily, I would want such a “novel of IT” to help all factions (inside and outside IT) come to see the other side’s perspective and arrive at deeper understandings of common problems and disagreements. Otherwise, it’s sheer polemics. As a CIO, I’d want to be able to hand the novel to my CEO or CFO and have everyone’s reading of it help us find common ground in how we approach our goals.

(One small aside: before I begin, I should note that none of the novels I’m going to cover can compete, as artful fiction per se, with what I consider to be the best IT-related novel: Ellen Ullman’s The Bug. Unlike the three novels I will cover fully, The Bug is intended primarily as art, not as a fictionalized essay designed to make points about how to run IT. Highly recommended.)

Let’s start with FruITion, by Chris D. Potts.

This book, which has been generally praised, depicts itself as essentially contrarian, as describing “what happens when corporate strategists decide to ignore all the IT strategy orthodoxies.” It’s meant to reveal “indispensable messages about the next generation of strategies for information technology,” as one of the blurbs on the back has it. The key distinguishing feature of the book, arguably even underscored by the implications of the photo on the cover, is that it’s intended to turn the conventional view of IT on end.

Well, I’m going to be a contrarian to the contrarian. Simply put, I think the fundamental thrust of the book is wrong-headed, divisive, lofty, unnecessarily diminishing of the importance of the role that IT plays in a business, and ultimately not helping disagreeing factions find common ground, or showing useful ways that IT can truly provide value to business.

As Twain famously said, history may not repeat itself all the time, but it sure does rhyme a lot. Or, as Yogi Berra said, “you can observe a lot just by watching”. Or, in Potts’ own words, “the language you use is taken as evidence of your mindset.” And, just by carefully watching the interactions and language in FruITion, my unavoidable observation is that Potts’ mindset is particularly, astonishingly, and blatantly ill-disposed towards IT.

Ian, the protagonist and first-person narrator and CIO, is a straw-man-stereotype kind of IT person. He’s tentative, focused on technology, set in his ways, reactive, defensive, a bit paranoid. Conversely, the novel presents the non-IT executives (the CEO and her delegates) as wise, fast-thinking, and a bit mysterious in their uncanny insights into what’s not working. They’re a little inscrutable, and more than a little threatening: Ian is constantly fretting about whether he’s about to be sacked, and the strategists are constantly making subtle and not-so-subtle references as to whether or not he’s “getting it” and whether he’ll even be around for the next go-round.

It’s “us vs. them,” in other words, in spades. Ironically, one character, presented as particularly insightful, is introduced positively as being “fed up with the ‘us and them” and ‘we know best’ attitudes of some IT people towards the rest of the company.”

Yet IT is presented mainly in the negative (indeed, with disdain) at every turn.

Yet IT is presented mainly in the negative (indeed, with disdain) at every turn, characterized repeatedly and triumphantly as “delivering no value on its own”, and it’s emphasized that “no one values what IT does.” Everyone else in the novel sees things clearly except for the IT people, who “execute their strategies at arms length from everyone else rather than by collaborating.” In one characteristically heavy-handed moment in the novel, Ian’s “IT Strategy Manager” views with excitement the chance to participate in a key software vendor’s new beta release: “It could change our whole strategy,” he enthuses, not realizing how narrow that statement shows his notion of strategy to be.

Face it, we’ve all known people in IT that exhibit those small-picture tendencies. But I don’t believe that it’s useful or accurate, in this day and age, to trot out such stereotypes and thereby blast the entire discipline. One “strategic” character in the book even tells Ian, “we want you to break loose, join the gang, help us turn the tables on those bastards in IT.” In the end, Ian escapes (ascends?) into this strategic realm, away from IT, but all the future pesky technical decisions are then relegated to a Technical Services Manager whom they elevate to “CTO,” and whose stated job it is “to get the IT we wanted to use delivered reliably well, economically, at an acceptable level of risk, and with economies of scale and synergies. Nothing else.” Simple, eh? (Note the amusing similarity of this new “CTO” role to what the role of the CIO was also thought to be, way back when. As the old joke has it: from here, it’s “turtles all the way down”).

In essence, it’s “technology bad, strategy good”: this novel presents an overly simplified, frankly offensive, and ultimately detrimental dichotomy. The book seems, quite intentionally, to consider current-day IT as a mere exercise in procurement: “All in all, our people now know enough about IT and how to use it not to need an executive to make those decisions for us. All we really need is someone who can source the IT services we want to use.” Really? We know what we want; IT just needs to get it for us. Order takers. How many years/decades ago did we all collectively figure out that that’s a counterproductive approach?

In short, if there’s any book that actually fosters the “us vs. them” rift that’s too often characteristic of how IT fits into a company, this would be it. It’s simplistic, dismissive, lofty, and ivory-towerish; in the end, despite its contrarian nature, it delivers next to no new practical insights. And one sad aspect of its dismissive nature: those who point out its failings will almost certainly be accused by its proponents of “not getting it.” (Witness this review of Chris Potts’ interview with Claudia Imhoff). I think I “get it” quite clearly, though, and I simply reject it as misguided, naive, and ultimately counterproductive to the needs of a modern organization.

Next up: two more novels of IT that I believe show a (much) more even-handed, useful, and insightful approach.

Lagniappe:

• Colin Beveridge. Book review: Fruition. http://www.colin-beveridge.com/index.php/book-review-fruition/.
• John Gøtze. FruITion. http://gotze.eu/2008/08/29/fruitio/.

Oil and water? Some days, the disconnect between stakeholder expectations and IT capabilities (and sensibilities) seems staggering.

It’s time for me to speak up.  Not that I haven’t before, here and here. But sometimes I just have to shake my head. I read certain IT-related articles on the web, or tweets by some colleagues, and they’re so out of sync with IT reality that I feel like it’s Opposite Day.

Here’s what I mean.  Let’s look closely at the latest item of this ilk that has spurred my head to swivel: this rather stunning recent Forbes interview with Mark McDonald, group vice president and head of research at Gartner Executive Programs. At core, McDonald is touting and praising, and with much reasonable-sounding eloquence and assurance, an abandonment of common long-standing lessons in IT.  In fact, such an abandonment is being presented as the only path to goodness, success, and truth; traditional areas of focus for IT are deprecated as being either of lesser importance, or even as the veritable hallmark of a clearly backward CIO who just doesn’t get the new order.

This isn’t to pick on Gartner alone. As I said, similar views can be found every day. Sometimes this view is couched as IT needing to take a “journey” through different “generations” — where the stated ultimate goal is to actually to eliminate the need for an IT strategy altogether. In the Gartner interview, the terminology used, however murkily, is that of CIOs being “rich” or “poor”.  Underlying this deprecating and generally anti-IT attitude is the belief (explicitly stated by Gartner) that business people are superior to technologists: “It’s always easier to teach a business person technology than a technology person business.” So to Gartner, not only is the very educability of the technology person at question, but these hapless tunnel-visioned technologists are even going about it all the wrong way: for example, by misguidedly focusing on properly managing IT resources:  “The poor IT organizations believe they create value by properly managing IT resources.” If they emphasize enabling the business, that’s wrong too: “If you define your IT organization as enabling the business, that’s an indication you’re headed in the poorer direction.” And, it turns out, the real secret to success is to throw over the IT people altogether when it comes to management: “the real determinant [of a “rich” CIO] is that many of [the “rich” CIOs] come straight out of business.” And again, it’s not just Gartner; elsewhere on the web, we can find similar statements, such as “many [IT] projects disappoint because they’re “too focused on timescale and budget”.

If you step back from being sucked in by this golden shimmer of an IT-less future, devoid of drudgery and tedium and all the traditional IT messiness, these haughty, ludicrous statements pretty much rebut themselves.  As one Twitter contact of mine put it in reaction, “It’s only hubris which allows one functional area (IT incl) to think the other’s domain is simple.”

And hubris is the right word here. Yes, much about the underlying recommendations sounds reasonable on the surface: we should emphasize business value above all, and we need to focus on enhancing the revenue, profits, and value of the company.  Those specific points are inarguable, to be sure. But it’s quite revealing, the way that the discussion is typically framed: it’s both enormously judgmental and dismissive, using words like “rich” vs. “poor”, or it makes grandiose claims that “with innovative and enterprising CIO leadership, a company’s strategy for investing in change will come to fruition and not apparently be about IT at all!” Or the statement that “running IT is not a valuable use of [the next generation of CIOs’] time, talents and energy”.

The obvious implication there, of course, is that if one still believes in the critical (indeed, strategic) importance of a well-managed IT function, even amidst a necessary focus on business value, then one clearly isn’t “the next generation” of CIO. This isn’t simply arrogant; it’s flat-out wrongheaded and dangerous. It leaves hard-learned practical lessons behind while presenting a fine-sounding, lofty, but ultimately fuzzy theory that promises to lift the CIO (and by extension the company) above the standard oh-so-trivial concerns of delivery and technology. It redefines basic words in order to depict a kind of transcendence of the mundane and dreary.  Dismissing the importance of basic IT facets such as proper management of resources, or adherence to time and budget, or technology itself, is akin to pitches that promise weight loss without dieting, or language learning without memorization; such pitches feed on the fears of the already discouraged.  Let me be utterly blunt: it’s snake oil; I don’t buy it, and neither should you.

Recommended take-aways for the CEO and other senior management:

• Don’t leave the valuable lessons of the past behind in your desire to evolve to some kind of higher plane in IT. The lessons still matter; in fact, they matter more than ever.
• Rather than striving to leave technology behind as a lesser concern, look for ways to integrate it and leverage it in everything the company does, centralizing and standardizing those things that matter as you go.
• Recognize and extend what technologists bring to the table, rather than pushing them back into their own ghetto and belittling their contributions and concerns.
• Don’t reject the need to carefully manage IT resources at a senior level. Despite what you may be told by masters of theory, those resources really don’t just manage themselves, and the risks involved in their mismanagement have become greater, not lesser.  Does anyone really need to debate this?
• Continue to insist that IT spend wisely (and continue to focus) on both new work and ongoing operations. The potential for financial mismanagement, if covered by a blanket excuse of “oh, we’re focusing on value now” is simply huge; it’s unwise and unnecessary to shrug that risk off as passé, or to relegate its oversight completely to junior managers.

In this day and age, the health, revenue, and growth of your company quite likely depend on the degree to which it can successfully leverage technology, both in a day-to-day sense and for strategic initiatives. Effective strategy is critical, but excellence in operational execution can often be a key differentiator. Above all, and for either, it’s not the time to step away from thinking that technology matters.

I recently had the privilege of being interviewed, along with other experienced senior technology executives, by CIO magazine for my thoughts on communication mistakes still made by CIOs. Some great ideas came out in the article, but when it comes to communication (see tip #1 below), there’s always more to say. So here goes.

• Communication can always be worked on and improved. I was at one company where we did a semiannual employee satisfaction survey. Even better, the company was admirably dogged about implementing specific measures to address areas of dissatisfaction that emerged from the survey results. But in every single survey, the number one vote-getter was the need to improve intracompany communications, no matter what initiatives were spawned to improve them. Communication is an ongoing challenge and necessity.

• Don’t just communicate upwards. Communication with your team is every bit as vital as your communication to management and to peers. You need your team to have a clear and common understanding of the goals, as well as getting their active contribution and buy-in on the necessary approach to getting there. You can’t go it alone.
• Hierarchy is actually helpful; use it actively. Do your best to avoid providing explicit nuts-and-bolts-level direction to staff members other than your direct reports. Jumping in and telling people at all levels what to do confuses people mightily, undermines the authority of your direct reports, and increases the likelihood of mixed signals. And it’s just plain inefficient. Early in my career, I was a director responsible for a major week-long software rollout in one of my company’s regional offices. The project manager of the initiative was one of my direct reports. But then, the stakes were high enough that the CIO decided to fly down, and of course, the regional VP of IT was there as well. So for a week, we had four management-level people all sitting in every meeting, each trying to actively demonstrate they were in charge and look good to the others. Or, there’s out-and-out, from-the-top, intentional bypassing of the chain of command: Amazingly, I’ve seen cases of a CEO setting up a task force without involving or even informing the people who managed the members of the task force. Talk about undermining!
•  Be clear about what’s actually a directive and what’s just an exploration. Dawn Lepore, CEO of Drugstore.com, recently spoke in an interview about how she couches her direction to her staff as to whether it’s a “a light bulb or a gun”. “A light bulb means this is just an idea I had, so think about it, see if you think it’s a good one. Either follow up or don’t, but it’s just an idea. A gun is, I want you to do this.” Surprisingly, people often can’t tell the difference on their own. As a leader, you typically want most meetings, particularly at a senior level, to feature open brainstorming, a free exchange of out-of-the-box ideas, but that means it’s all the more important to carefully identify what emerges as actionable initiatives and what things continue to be simply thrown around as possibilities.
• Put it in writing. Supplement the directions you give in meetings and one-on-ones with a clear and succinct written summary. Doing this both clarifies and makes an unambiguous record of what you’ve asked for, and accurately communicates it more broadly than just to the people who happened to be in the meeting. It’s a way of demonstrating that you’re declaring yourself accountable. Doing so is vastly preferable to having your people run around claiming “The CIO wants this.” (And with some, once they discover that such a line grants them all sorts of vicarious power, they’ll tend to overuse it, and at inappropriate points). I’ve seen a lot of ineffective leaders follow some kind of old-school “just tell them” mentality, and they cause significant confusion in the ranks by failing to put things in writing. And it’s no wonder that with this approach, which evolves into a kind of “Telephone” game, they’re often disappointed in what they get.

Oral communication is often vague and ambiguous. Written communication is on the record. Strive to go on the record as much as possible.

• Be utterly clear about who owns the execution of the initiative, and who will be making specific lower-level related decisions. Most notably, avoid having people think that everything needs to be cleared with you at all junctures. For most initiatives, your role is to set the overall goal, not to shepherd day-to-day the specific process of getting there. Lack of clarity here is common, even when everything else is done right.

Common sense, all these tips, no? The thing about common sense, though, is that it’s often frightfully uncommon.

Most senior technology executives have a good sense of the huge value that comes from comparing notes and impressions with one’s peers about industry trends, techniques, project approaches, even vendors. Networking, appropriately handled, can enable you to find out all sorts of “lessons learned” without having to go through the pain of learning them the hard way.

But as with most things, there are effective and less effective ways of going about that sort of networking. For a long time, I looked to industry conferences to provide this sort of connection and exposure to a wider and wiser set of peers. But despite a few positive experiences, I’ve changed my mind in general about the utility of conferences.

Aside from technical exposition and tutorials, most industry conference sessions revolve around case studies. And oh, what cases they are, according to the presenters. Quite typically, everything is golden, nothing has ever gone awry or possibly could. Their own approach is the only one conceivable for success. “This one goes to 11” seems to be their slogan. The presenters seem to think that the more enticingly they portray their project and approach, the greater value they’ll provide to their audience.

And as for dialog? I’ve found, through painful experience, that the kinds of questions typically asked at conference sessions are most often designed to make the questioner himself look really smart. They’re often not even real questions, more lengthy expositions. We’ve all encountered that sinking “captive audience” feeling you get when you realize that such a questioner, a zealot of one flavor or another, has commandeered the audience microphone and is out there grinding his or her axe, and that someone is going to have to deal with it. Awkwardness pervades the session until a moderator or a fellow participant finally speaks up and shuts it down. That’s not dialog. That’s not networking. Even hallway conversations at such conferences can be filled with similar self-aggrandizing.

But this syndrome is actually deeper than something you just see at conferences. I would submit that it is unfortunately characteristic (admittedly in the extreme case) of what often plagues IT spokespeople in general, as they present before senior management or their board. We all want to be valued and highly regarded, and somehow, many of us decide that the best way to achieve that is to tout the bright side of our coins and leave any dark sides unmentioned or glossed over.

Let’s look at an example, in the form of a recent article about the fabulous success of Agile approach at eBay. Read the article; you won’t find a single wisp of a thought about any downsides, any blemishes, that occurred along the way. It was all golden, apparently. You see only references on how “to out-think and out-execute the competition”; or, “deliver useful information in days instead of months.” Can you say “silver bullet”?

Presenting any complex endeavor in nothing but glowing terms is to willfully forge an illusion, of course, not just at a conference or in an article, but at a board meeting as well. Somehow, the “case study” style of presentation tends to feature just that sort of dubious strutting, an implicit declaration that “everything went great.” Yet recognize that the people you’re presenting to are accustomed to piercing through that sort of bullpucky every day from vendors they deal with; you’ve lost your audience as soon as they figure out that you’re of similar ilk. It’s a similar deaf ear to the ones that teenagers turn when their parent tells them again and again about trudging ten miles through the snow to get to school, uphill, both ways. It’s a fish story.

The broader issue of how to present to one’s own management is something I’ve discussed elsewhere. But on the specific issue of finding a better solution to accomplish most of the goals that people hope to achieve by attending conferences? Local peer groups with regular meetings. Well-facilitated and attended peer groups, in my experience, can provide benefits that most conferences can’t or don’t: far greater continuity, candor, dialog, and, yes, screening. Most are participation by invitation only. And in such a setting, people stop having their principal goal being to impress others, and turn to looking to glean and impart useful information and tips above all. The best of the ones I’ve participated in adopt a tenet of “what’s said in the room stays in the room,” which greatly encourages candor and maximizes the true practical utility of the discussion.

Case studies and anecdotes are interesting, but my point is that conferences typically consist of lots of these, all golden, implausibly strung together back-to-back. And as I’m fond of saying, the plural of anecdote is not data. Many conference presentations are, at least in some sense, nothing but elaborate sales jobs. And if you really went to the conference for networking and learning, you want dialog, not sales.

How do we (IT executives) get away from being typecast as technologists, unconsulted on core business issues and approaches? Face it, that’s a common situation and dilemma that we all encounter, early and often, and it’s the grist for a constant mill of articles and blog posts and books on business/IT alignment.

Lately, though, a part of that mill has started insisting that focus on technology should be avoided altogether by what they usually cast as the “next generation” of CIO.  So I’m going to (again) be a bit of a contrarian here: it’s possible for the pendulum to swing too far in the wrong direction. I think that we can at times go overboard in our desire to avoid being seen as the geek with the pocket protector.  Examples: some preach outright denial that there might be such a perception problem: don’t even think of using the terms “IT” and “business”, they urge, and they recommend against ever discussing “alignment” as a goal.  Stop referring to the “business” as something separate, they recommend; IT is just as much part of the business as anything else! Similarly, their advice is “avoid discussing the technology itself.” As if a mere shift in language could solve the perception problem and automatically propel the CIO into the inner circle of decision-makers.

Here’s the gist of how I see it, though: in many (I daresay most) companies, the path of IT from high priesthood to strategic key playerdom has not really been fully traversed: in other words, greater alignment IS still needed of IT with “the business.”

In many companies, there’s still a trust problem. IT is arcane. IT can be as resented as a roadblock as the in-house corporate counsel types who veto certain kinds of corner-cutting.  Of course we’re “part of the business” (and increasingly so), but that doesn’t mean it’s wrong to continue to focus on breaking down the walls that linger.  The walls, in many/most places, are a reality, and it’s going to take steady, relentless, active work, not just a shift in language, to scale them. What especially will not help our effort to do that is if we embrace this odd trend of sneering at technology as a lesser-order concern—basically, positing that we should let someone else do that while we do the important (strategic) stuff.

In other words, I differ (vehemently) with those folks who now look down on such things as the need to align IT with the business, or who don’t recognize the benefits that come from regarding people as “internal customers”, or who recommend even avoiding using the terms “IT” and “business”. While the basic spirit behind those sentiments is of course valid—again, it’s undeniable that IT is part of the business, as much as any other department—it is in fact IT that has a problem in how it’s perceived by other elements of the company, going back to the high priesthood. Let’s be frank: IT folks have often been snooty, vague, cagey even, about what we do, why we do it, and how we’re meeting the company’s business needs as a whole. Deprecating the important progress and mentality shift that’s occurred in the last few years (that is, the high priesthood evolving to a service mentality) is exactly the wrong approach.

And somehow, inexplicably, the deprecators are getting louder, despite years of research and general agreement on the value of approaches such as IT governance, the ongoing need for IT/business alignment, etc.

Taken to an extreme, insisting loudly that IT is part of the business can extend to feeling that IT knows just as much about what’s good for certain business processes (say, manufacturing or shipping or collections or whatever) as the people executing those functions on a daily basis.  From there, it’s just a small but perilous step back into the old sort of IT arrogance, where systems were designed and deployed with little or no feedback from the actual users.  I exaggerate? Quite possibly, but I’ve seen it happen.

IT needs to both know its place and insist on its place, not one or the other. Here’s another example of a truly ham-fisted (even though well-intentioned) attempt to align IT more closely with business: I took over as CTO at a high-profile internet company, in the midst of deep, bet-the-company changes to its main product, a consumer-facing web site. I learned in my first few weeks that my predecessor had initiated a robot project.  His idea was apparently that he’d program this robot to walk the halls of the company, greeting people and thus making them feel more comfortable with technology. As Dave Barry is fond of saying, I am not making this up.  Needless to say, this project swiftly became a laughingstock across the company, representative of IT embracing technology for technology’s sake, completely OUT of alignment with business needs. Meanwhile, systems were crashing, projects delayed, etc.  This CTO somehow thought he was being strategic and business-oriented, but he actually was just being plain clueless, and more tech-focused than ever.

With IT’s background and history, the push towards IT/business alignment is ongoing and needs to be continual, rather than dismissed as something we’ve now evolved beyond. Even more, alignment mustn’t be deprecated as somehow beneath the higher goal of strategy. It’s not an either/or, and it most certainly doesn’t happen through mere declaration. And openly striving for alignment with our peers is nothing that anyone should present as a taboo or a sign of weakness. Additionally, at the same time that we serve as service providers to the company, we can and must be strategic in our outlook. This shouldn’t be either a surprise or controversial; in fact, excellence in tactical delivery is the ante that gets you to the strategic table.

It’s taken decades to get where we are—and I’d say (given, for example, the anecdote I cite above) that most of us are not really there yet anyway. Let’s not risk reinstating the “ivory tower” of strategy, devoid of the reality that comes from grappling with the actual pragmatics of implementation.

So, here are MY three tips on how to help convert your CEO’s understanding of where IT fits into the bigger picture. You’ll notice the emphasis of these points is quite different from the similar list in the piece I’m responding to here: in particular, my points stress a healthy balance between strategy and tactics, technology and business.

• Make sure there’s a rock-solid prioritization mechanism for all projects, where the priorities are clearly set, the tradeoffs carefully examined, and tough choices explicitly made and regularly revisited by the group of senior management, including the senior technology executive, who are jointly responsible for the business success of the company.  Focus on IT governance, Project Portfolio Management, etc.

• Speak up visibly and strongly to ensure that “roof projects” are given appropriate attention and priority. Build for the day after tomorrow rather than just for tomorrow. You in IT are a key advocate for this sort of basic corporate responsibility; you have and need to exercise your equal seat at the table.  And don’t let a misguidedly monomaniacal focus on strategy derail your obligation to keep the trains running on time. Nothing undermines the case for IT to be viewed as having a greater strategic role more than if the company is experiencing ongoing crises in basic delivery and systems.

• Be the straw that stirs the drink. IT, given a leader with appropriate vision and perspective, can and should be a natural cross-functional leader in the enterprise, both initiating business innovation AND espousing tactical responsibility.  They go hand in hand.

Let me end by quoting my colleague Steve Romero, who wrote, “Recognize that the “achievement” of alignment does not mean you’re done. This is where the “journey” analogy comes in. Think of IT-Business Alignment as “getting your head above water.” Once you reach the surface, you are not done. You need to keep treading water or you sink again. IT-Business Alignment is something that must be maintained as opposed to achieved.”

Lagniappe:

• Michael Krigsman, “IT failure? Blame your CEO.”  February 16, 2010
• Steve Romero, “IT-Business Alignment is Not a Meaningless Catchphrase“, October 28, 2009
• Michael Pattison, “Is IT – Business Alignment Meaningless?“, November 6, 2009
• Bob Evans, “Global CIO: Suicide Strategy For CIOs: Aligning IT With The Business“, October 13, 2009
• Fred Cummins, “Is Business-IT Alignment Suicide for the CIO?“, October 21, 2009
• Mary Nugent, “The Four Phases of IT/Business Alignment“, December 10, 2004
• Paul A. Strassman, “What is Alignment?  Alignment is The Delivery of the Required Results“, Cutter IT Journal, August 1998

What is it that sets apart a top-notch IT executive from others of his calling? To my mind, one mark of today’s true professional, especially at the senior executive level, is to be deeply familiar with the seminal books in his or her field. The dilemma for an IT professional, though, comes from the ongoing and increasing flood of books to choose from, and trying to figure out how to walk the fine line between focus on the intensely tactical and focus on higher-level concepts and ideas.

The tactical books do have their place on your shelf, actually, and it would be a mistake to ignore them simply because you’ve moved beyond daily application of your development, configuration, and technical trouble-shooting skills: judicious selection and absorbing of nuts-and-bolts techniques and new approaches will keep your insight into technology and its possibilities fresh.

I started in IT as a developer, and I remain fascinated by the endless possibilities and techniques of the world of software. In the last decade or two, though, I’ve become even more intrigued by a metalayer above the more tactical concerns. True to my ongoing insistence that the biggest challenges in IT aren’t purely technical, I am ever more convinced that the greatest difficulties are presented by “psychology of IT” issues: the human factors in how software and systems are conceived, built, tested, deployed, maintained, and eventually decommissioned.  Here are just a smattering of the eternal, non-technical questions that go far beyond the computer language du jour or the latest hot methodology:

• How do teams actually create and complete information technology projects? What works, what fails, and why?
• Why are some software developers ten times as productive as others?
• Why do some software teams gel and others don’t?
• Why do small companies with very few resources often beat out large, well-funded efforts in the marketplace?
• How technical should managers be?

So starting with this post, let’s embark on a multi-part survey of the groundbreaking, timeless books on such issues. I’m going to pick what I consider to be the top three books from each decade, starting with the 70s.  Each of them deserves not only a place on your bookshelf, but to be read and reread every few years. And contrary to what one might think, their insights remain not only valid after all these years, but have become all the stronger by having been confirmed by the history of the industry since their publication.

• Weinberg, The Psychology of Computer Programming (1971)

Weinberg opens with, “This book has only one major purpose—to trigger the beginning of a new field of study: computer programming as a human activity…. If our experiences are any indication, each [software developer] could be functioning more efficiently, if he and his manager can learn to look upon [him] as a human being, rather than as another one of the machines.”  This book was especially groundbreaking by addressing software development as both an individual and a team effort. Remarkably readable and full of anecdotal examples, it covers virtually every human aspect of the software development “sausage factory”: team formation, individual contributions, goal setting, leadership, estimating.  Weinberg’s “Silver Anniversary” edition of this book contains annotations and commentary for each chapter, reflecting on similarities and differences to today’s environments.

• Brooks, The Mythical Man-Month (1975)

I’ve said it before: if there’s one single book that every IT professional should read, it’s this one. Brooks’ foreword presents it as a “belated answer to Tom Watson’s probing questions as to why programming is hard to manage.”  Brooks’ writing brims with key universal concepts that can be unfortunately non-intuitive to people outside the field, but which ring familiar to any long-time IT practitioner. The titular essay introduces the concept of the “mythical man-month”, his adage that “adding manpower to a late software project makes it even later.” But there’s much more, such as “plan to throw one away”, where Brooks points out that the “first system built is barely usable; … there is no alternative but to start again.” I can’t say enough about this book. As with the Weinberg book, the anniversary edition now being sold includes extra material: Brooks’ later (1986), equally seminal essay, “No Silver Bullets” (see my post on this: “No Silver Bullets. Really!“), as well as some added chapters that revisit the assumptions of the first edition.

• Weizenbaum, Computer Power and Human Reason (1976)

Ultimately, this is a book about the limits of computers and software. Weizenbaum, a noted computer scientist in the early days of Artificial Intelligence research, wrote a program called ELIZA, featuring a script that “enabled it to parody the responses of a nondirective psychotherapist in an initial psychiatric interview.”  In other words, his test subjects would converse with a software program that emulated a therapist. Weizenbaum became horrified by how many people forgot that this was “just” a machine they were talking to, and that the dialog was really just an illusion. Many insisted, to his amazement and despite his explanations, that the computer actually understood them.

IT professionals today can be just as swept away, to a fault, with the potential ultimate power of software and systems as Weizenbaum describes.  I’m inspired and reinvigorated every time I read his sobering, methodical discussion of the nature of programming, the limits of its scope, and the need to consider the social implications of technical projects.

The next time, I’ll be on to the key books of the 80s. I’ve already picked the books I tentatively plan to write about, but I welcome your suggestions.

Lagniappe:

Here are a couple of books that didn’t quite fit in my theme and chosen time frame, but which are still worthy of mention:

• Thomas Kuhn, The Structure of Scientific Revolutions (1962)

Nobel Prize-winning physicist Steven Weinberg wrote that this book “has had a wider influence than any other book on the history of science.”  This book is not about information technology directly, but its influence has been monumental across all scientific disciplines, and it is a book that any technologist should know well.

• Ted Nelson, Computer Lib/Dream Machines (1974)

This was a self-published book in the early 70s, by influential industry visionary Ted Nelson, the man who coined the term “hypertext.” It’s probably different from just about any book you’ve ever read.