Yes, it’s déjà vu: certain topics crop up again and again on IT-related blogs. The age-old question: does a CIO really need to have IT experience?  I’ve touched upon this before, here and here, but it’s time for a full column covering the standard arguments posed in this debate.

I’ve gone through every article I can find on this topic (most of these are listed at the end of this post), read all the associated comments, and culled out the arguments that are typically cited in support of a CIO’s ability to be successful without IT experience. These are:

• A non-technical CIO can surround himself with a capable team who can support him in all technical matters
• It’s the ability to lead that’s really needed, whereby the issue of technical capabilities becomes secondary
• After all, there are some successful business CIOs without technical background
• Even supremely technical CIOs have been known to fail
• Considering today’s rapid pace of change, past IT experience can be a hindrance to many CIOs today as often as it is a help: that experience can make a CIO “unduly resistant to the possibilities.”

As I looked at these arguments, though, I found them all strangely uncompelling. I felt truly puzzled: how could anyone argue vehemently in favor of a lack of experience as a job qualifier, for anything? But as I thought about it, I realized it’s a matter of basic definitions. As in so many debates, this topic has been seriously hampered by many parties failing to define clearly the basic terms: what does “IT experience” or “technical” mean, and what does it mean for a CIO to “be successful”? Without a clear and common understanding of what is meant by those phrases, advocates on both sides tend to drift into “straw man” postulates, where they reach a strong and usually quite self-righteous position based on divergent definitions.

Let’s look at what could be meant by “does a CIO need IT experience”, or, as it’s sometimes phrased, “does a CIO need to have a technical background.” These two things are usually conflated, but they are not the same. “Technical background” seems to usually mean academic qualifications: e.g., a Ph.D. in computer science, or at the very least, deep, low-level understanding of bits, bytes, protocols, APIs, etc.  “IT experience”, on the other hand, may be garnered through years of working on either the development or operations side of information technology, and may have involved relatively little purely technical activity. It’s easy for any given individual to have a great deal of one and not the other. But it should be noted that having more of the first (technical skills) doesn’t substantially improve your ability to cope with CIO-level issues, while having more of the other (IT experience) most certainly does.

What about the notion of a CIO being “successful”? What does that mean? Length of tenure in the position (not getting fired)? That seems like a dubious yardstick. Almost any industry veteran is aware of instances where highly competent CIOs have been let go due to political shifts within a company (e.g., advent of a new CEO), or retained for similar reasons despite questionable performance. Does it mean, perhaps, having measurable achievements? These too often depend on perceptions and political whims: a CIO can, for example, “successfully” roll out a system which works exactly as designed but fails to deliver hoped-for benefits.

A more meaningful definition of success, to my mind, is when a CIO can mobilize both his team and the company at large to obtain measurable value from the investments it is making in technology, and, moreover, gets that team demonstrably exercising continuous improvement in its processes and products. CIO success is not just about sticking around in the position; it’s not just about rolling out systems and supporting an infrastructure. It’s the impact on company results that matters.

If a given debate on a CIO’s necessary background assumes one set of definitions for these key facets, it’s easy to have the resulting arguments and conclusions dismissed out of hand by people who hold different definitions. And often, participants in the debate don’t even recognize the root of their disagreement: that they’re using the same terms for quite different situations.  In reality, they may agree more than they differ.

A CIO must have a good amount of IT experience (not necessarily specific technical skills) to be successful.

So using the definitions that I think are meaningful, as outlined above, my answer is that a CIO must have a good amount of IT experience (not necessarily specific technical skills) to be successful. (Note that citing that there exist occasional anecdotal exceptions to this, aside from depending on a usually unprovided definition of “success”, may be interesting but isn’t necessarily useful; Steve Jobs and Bill Gates both dropped out of college and still achieved prominence and prosperity, but they’re not examples one would logically use to formulate a general rule about the path to becoming CEO of a multi-billion dollar corporation).

Being a CTO/CIO is not about technology — I’ve stated that consistently, starting with my very first blog post. It is, however, about leadership and experience. The notion of an individual able to provide outstanding leadership but lacking a solid foundation of related experience doesn’t fly well in any situation or arena I’ve ever seen. Time and again, I’ve gone into turnaround situations at companies where IT matters have been completely bungled by having no CTO/CIO or otherwise inexperienced IT decision-making.  Bart Perkins’ recent excellent piece points out numerous specifics of what happens when there’s no CIO at all: business unit-centric decisions, standardization impasse, lack of new enterprise applications due to business unit parochialism, factionalism, and decreased economies of scale. I’d extend that: many if not all of those same situations tend to occur even with a CIO on board, if that person is inexperienced and thus unaware of these IT-specific pitfalls.

So again, my answer: to be a good CIO you don’t need to know, necessarily or specifically, what a left outer join is, or be able to reel off the seven layers of the OSI network protocol stack. You don’t need to know, necessarily or specifically, the difference between Java and JavaScript or to be able to have your way in either vi or emacs.  But, you’d better understand deeply the basic roles that IT elements play, how processes fit together to provide business value, and where the pitfalls may lie as your team goes about that fitting together.  You’d better be in position not to be easily swayed by a slick vendor or even a convincing pitch from one of your senior lieutenants; part of your job is to know when to push back. And that judgment comes from experience, not from some innate abstract leadership ability alone.

After all, IT changes radically every few years, and specific technical knowledge is of fleeting value in and of itself.  Only actual work experience, grappling with juggling priorities, making tradeoffs, and satisfying multiple constituencies, tends to teach people how to maximize the value from IT-related investments made by the company.  And there aren’t any true shortcuts. Again, the saying applies that I’ve cited here before: “good judgment comes from experience.  Experience comes from bad judgment.”

Lagniappe:

• Nick Lansley, “Are the best CIOs from non-technical backgrounds?”
• Arun Gupta, “Are the best CIOs from non-technical backgrounds?”
• Chris Curran, “Can a CIO be Successful Without IT Experience?”
• Kate Bulkley, “Will your next CIO be a non-techie?”
• Scott Wilson, Can a CIO be successful without IT experience?
• Michael Fisher, “How Technical Should The CTO Be?”
• Richard Hunter and George Westerman, “Should Your Next Job Be CIO?”
• Chris Curran, “CIO Background Check: IT Experience Mandatory?”
• Thomas Pelkmann, “CIOs müssen keine Ahnung von IT haben” (in German)
• Bart Perkins, “The Fortune 500′s disappearing CIOs”
• John Julius Sviolka, “The #CIO: The duck billed platypus of the C-suite”
• Sharon D’Souza, “CIO career query: Does your background make or break it?”

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.

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.

Think about it: you can’t really tell the difference, on a day-to-day basis, between a car that has had its oil changed every 3,000 miles and one that has had its oil changed every year or two.  Only eventually.

Similarly, the stability of most IT departments proves very difficult to discern from outside.  Even insiders within IT can have myopia.  And non-technical senior management (CEO, COO, CFO)?  They usually can’t really tell either; they often don’t even know the right questions to ask, and their gut instincts on IT matters can actually run dizzyingly counter to best practices.  In short: to many or most people, it can look like things in IT are going pretty well, but in fact it’s all getting shakier and riskier every day.  Truth is, if a company is passionate about excellence, IT has to function well both on the surface and to the careful trained observer. IT is a service organization, and getting a few key things wrong means that the entire company suffers as a result.  Eventually.

My claim here sounds like an admittedly rather pessimistic one: that your IT department may be in much worse shape than appears to the eye. Yet, industry statistics indicate that’s probably the case. Having worked for and/or consulted to a lot of companies in the past decade, I’ve walked into a lot of “opportunities”, places where there was a lot of unchanged oil, so to speak. In fact, I’d be willing to bet that most companies have at least one, if not several, of the situations I’m going to describe in this post.

On the optimistic side, though, there are identifiable common root causes, all of which can be addressed, over time, by the appropriate focus and leadership.  As people always say, the first (and often hardest) step is simply recognizing that there is a problem. Let’s dive into the specifics, at a high level.

Here’s a reverse top-10, David Letterman-style, loosely ranked list of IT “anti-patterns“. I’ve actually seen companies where all of these situations existed. How many hold true where you work?  These gaps represent failures at meeting important best practices; like canaries in the coal mine, you should consider them to be potent indicators of looming instability in one or many of the dimensions where IT needs to serve the company.  Each of these deserves a separate post, or more, to treat fully; in some cases, I’ve already written posts on the item, so for those I provide a link below.

• 10. There’s no published record of system uptime and failures. IT departments that don’t monitor, measure, and publish their operational success rate probably aren’t doing all that well, and although people may suspect that’s the case, they have no facts-based way of truly knowing.  And what you don’t know will hurt you here.
• 9. Development doesn’t separate maintenance work from new development. Combining maintenance and new development in the same set of developers is a pretty guaranteed way of neglecting one or the other, often on an alternating basis.
• 8. Developers are performing production-level operational tasks on a regular basis. If you want to deliver new work consistently, you can’t afford to have your developers worrying about production tasks and issues. As with #9, one or the other, or both, will be neglected. Worst example of this? Having your developers push code live into production.
• 7. There’s no crisp handoff of new production code to the operations group, and no formal Operations Acceptance Test (OAT). Putting code into production needs to be a big deal, with metrics established, gates in place, and confirmation required prior to doing the deed itself.  As I’m fond of saying, the most destabilizing thing you can do to a software/hardware system is to change it.  You need a well-tuned system of checks and balances to avoid problems and instability.
• 6. Capital expenditures aren’t well planned or tracked, and often there’s a “last minute purchase order” frenzy. This is a CIO-level gap, often, compounded with CFO tolerance or lack of awareness. There should never be a situation where anyone needs to run to the CFO or CEO waving a purchase order, usually with no documentation or justification attached, insisting that it must be signed before close of business or systems will fail.  Nearly all expenditures, with few exceptions, should be in the context of a pre-established, signed-off plan.  Discipline (and accountability) in how IT spends money is a key hallmark of excellence.
• 5. The IT desktop/laptop inventory is murky, with no clear and published unit replacement plan.  What you don’t monitor, you can’t measure; what you don’t measure, you can’t control. Lack of discipline here not only costs money, it’s indicative of general lack of due diligence.
• 4. Development and test environments are all different, with no clear change control for new builds or tweaks. Without adherence to an airtight process for installing new code, software environments inevitably diverge, and at that point, chasing bugs can be quite frustrating.  A dogged drive to keep environments consistent with one another is a key benchmark of world-class development shops.
• 3. There’s no published list of projects underway, along with commitment dates: a public report card. If IT isn’t formally and publicly accountable for delivery, that’s the first step down the road to chronic slippages in schedule.
• 2. Projects are begun one-by-one. Estimates, if done at all, are unrelated to actual resource allocation. Without a project portfolio approach, projects fall prey to the “oh, that’s gonna take us three months” throw-off estimate which gets cemented into a commitment.  Without doing the math (figuring out competing projects and actual resource availability), you’re stacking up the dependencies and the likelihood of frequent failure to deliver.
• 1. The business doesn’t sit down regularly with IT to do a formal prioritization of major projects. Most critical of all: what gets worked on needs to be constantly examined and revisited, with the priorities set, the resource commitment understood, and the trade-offs recognized by business stakeholders.

You’ll notice that the most important (last) three items all deal with project management. That’s because strong project management, handled on a portfolio basis, is the most critical success factor facing an IT department, and the most common place where IT organizations are pressured to cut corners and “just get it done.”  Again, ensuring that you have that kind of project management will require focus, as well as active, informed leadership inside and outside IT.

This has been a scary post, perhaps.  You know what’s even scarier? This list could actually have been much longer than 10 items — these are just the most potentially damaging of the situations I’ve witnessed, but they are by no means the only canaries to look for.

Just a heads-up for readers: CTO/CIO Perspectives was mentioned this week in an interesting article in CIO Magazine, titled “20 Things You Can Do In 20 Minutes to Be More Successful at Work“. Not all the tips are spot-on, in my view (and I commented to that effect in the comments section), but there are definitely some gems there worth considering. All of us juggle a varied and heavy workload, and have frustrations about maintaining our personal productivity amidst the fray; lots of things in this article can help. Check it out!

In general, I highly recommend following the content published in CIO. As with all things, not everything is of equal value, but the range of topics and discussion is absolutely germane to anyone in an executive IT role in particular.

Joining some 89 million of my fellow netizens, I’m starting a blog. But there will be no pictures of my dog here. Instead, this one will concern itself with what I’m calling “Intensely practical lessons learned in the CTO/CIO trenches.”

Despite my considerable and immutable youth (I assure you that this is true), I’ve had a 25-year career in information technology, serving as a senior executive at Internet companies for the last ten or so of those years. I’m a strange combination, I think sometimes: a CTO who rose up through the ranks of software development, then got “religion” on project management and operational issues, and who maintains an extremely strong interest in and affinity for business issues, particularly those revolving around customers. I’m also a bit of an amateur “internet sociologist”, fascinated by what makes such companies succeed and fail, rise and fall. This admixture will make for some odd, but I hope interesting, topic choices at times.

I searched around the blogosphere (perhaps rightly one of the top most hated words on the internet), looking for something similar to the kind of blog I envisioned, and frankly, I couldn’t find it. Listed at the bottom of this post are links to some of the CTO/CIO blogs I did find, and I welcome people’s comments that point me to useful blogs that I might have missed.

One thing I’ve learned as an executive is the value of stating one’s goals at the outset, so here are mine for this blog:

• address what I see as common information technology issues / problems, ones that span just about every company;
• bring in real-world experiences and anecdotes related to the topic, with names changed to protect the guilty;
• provide “meaty” posts on the topic at hand, instilled with personal perspective;
• post at least once a week;
• provide useful topic-related links in each posting (what I’m calling my Lagniappe section).

This blog will be all over the map of the technology executive experience: I have at least 50 topics already jotted down, just off the top of my head. I plan to cover such things as vendor management, managing expectations, metrics, working with senior management, keeping up with technology, hiring and firing, application portfolio management. I’ll be writing a lot about what I regard as the key p-p-p-pillars of a CTO’s purview: People, Process, Product, Projects, Performance. There won’t necessarily be a logical progression of topic from post to post; I’ll just see where the spirit moves me.

So, what won’t this blog be about? It’ll of course be CTO/CIO-oriented, but one key thing that I have discovered from doing those jobs is that technology itself is really only about 10% of the job. So you’ll see only about 10% of my posts, at most, covering purely technical topics. Unlike one CTO blog I found, you will never see lists of instructions here for configuring hardware or software, with phrases like “Mount the Longhorn x86 Beta 3 ISO image on the VM, and boot the image.” That stuff certainly has its place, but it just won’t be here.

As does just about every blog, I hope to inspire a certain quantity of quality dialog on the topics I cover, but that will probably have to wait for a bit of traffic to build. Whether you agree or disagree with my stances, please consider chiming in with your own personal experiences regarding the topic. And remember I’m new here to the blogging world, so I’ll be learning tools and tips as I go.

Lagniappe:

Other CTO/CIO-oriented blogs: I was aiming for relatively generalist (not product-specific) blogs of this nature, ones that are still being kept current, with typically at least three posts a month. As I noted, though, I didn’t find very many of these, so not all of the ones below fit that criterion. These are not listed in any particular order (and were updated in November, 2009; for a more accurate look at current top CTO/CIO blogs, consult my blogroll):

• SoCal CTO, by Tony Karrer: http://socalcto.blogspot.com/
• Candid CIO, by Will Weider, CIO of Ministry Health Care and Affinity Health System: http://candidcio.com/
• CIO Mind, by Felix Enescu, http://ciomind.biz/
• CTO Blog, from various authors at CapGemini: http://www.capgemini.com/ctoblog/
• CTO 2.0, by Antonio Chagoury: http://www.cto20.com/
• CTO blog, by Lars Struwe Christensen: http://www.giritech.com/int/Giritech/CTO-Blog
• CIO Blog, by Peter Birley: http://www.cioblog.co.uk/