• 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/.

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?”

The bear says, “You see? It really does work.  Now make yourself light again.” Whereupon the hedgehog quietly retorts, “How about you doing something once in a while?”

Midnight Train

“Don’t write about that,” I’ve been told by several colleagues, when I’ve mentioned that I was working on a post about how best, as the senior technology executive, to negotiate with vendors.  “You’ll give away all your tricks!” they’ve said.

Well, actually, no.  Here’s the main trick: this particular CIO doesn’t have any “tricks”, if by tricks you mean ways to outfox the opposition, or anything else that is best kept secret.  In fact, I’m not a natural avid negotiator. I’m not one of those people who looks forward to buying a new car because of the thrill of haggling with the salesperson.  But I’ve learned over the years how negotiations can best be structured for the optimal outcome.  Like cryptography, where greater obscurity isn’t equivalent to greater security, successful negotiation isn’t dependent on tricks or subterfuge.

I’m quite content to tell any vendor or salesman how I go about negotiating, because doing so doesn’t provide them any kind of advantage.  If anything, it’s beneficial to me and my company that all parties in the negotiation understand clearly the basic principles and approach that I’m using; it cuts a lot of the normal gamesmanship out of the equation.

What I’m about to tell you about negotiating actually strikes me as incredibly obvious. Yet, time and again, I’ve come into a new CTO/CIO role and been astounded at the poor technology deals that were cut by the previous executive: inadequate terms, failure to protect both parties instead of just the vendor, unnecessary and undesirable contractual lock-in.  What happened in most of these cases, as far as I can usually determine, is that the executive in charge got swept away by emotional attachment to a specific solution, and tipped his or her hand. Game over: at that point they were putty in the vendor’s hands. I’ve even seen cases where contracts have completely put the vendor in the driver’s seat of actual implementation, including spending authority, to an unconscionable degree.

Make no mistake: vendors are typically much more experienced and skilled in negotiations than most of the technology executives they deal with.  Achieving excellence in negotiation should therefore be seen as a critical part of the technology executive’s skill portfolio.  But, like finance skills, it’s a skill more honored in the breach than the observance.  Your ability to negotiate well can not only protect your company’s long-term interests, but can actually recoup far more than the equivalent of your annual salary to the bottom line. It’s not uncommon for technology executives at even relatively small companies to negotiate deals worth hundreds of thousands or even millions of dollars of capital and operating expense.

So let’s cut to the “secret”. It boils down to this simple principle: give yourself choices. Identify two, preferably three, viable, affordable, achieveable ways to solve your problem or need.  Once you’ve successfully established that viable short list, the power is all in your hands.  If you haven’t fully done that, you’re not really ready to negotiate, so you shouldn’t even start. Power in negotiation comes from not being wedded to a particular solution. Another way of expressing this idea is “always be truly ready and willing to walk away.”

Pay attention here: I’m about to say two apparently contradictory things, both of which are true and key:

1. You need to regard all of the choices on your short list as fundamentally on equal footing, each with its own advantages and disadvantages, but on balance having roughly the same merit as a solution.  Don’t ever go in having already decided which one you really want!
2. Yet, you need to remember that all of the choices are also fundamentally different in their details. For example, one might have 30% greater functionality or come from a more established and stable company than the others, but recognize that this advantage probably comes with a cost premium. The market is generally pretty efficient that way.

Your goal in the negotiation process is to see where you can find “wiggle room” on each alternative’s components (price, terms, features) that will ultimately make one of those choices outshine the other, on balance.  In other words, you are looking to unsettle the equilibrium you’ve achieved in #1, so that one choice comes out on top. And here’s another key: let each vendor know, and remind them frequently, that this is what you’re doing. Usually, there’s no need (or benefit) in letting the participating vendors know exactly what your list of alternatives consists of, but it will suffice that they know that you know that you have choices.

Miscellaneous tips and observations:

• Negotiation, in general, is not simply about money, although that’s certainly a key dimension that can make one of your viable alternatives rise above the others.  Any facet of the deal should be open to scrutiny and discussion: cost, terms, rights to upgrade, SLAs, warranty, etc. You don’t always automatically choose the least expensive option, nor do you always choose the most featureful.

• Don’t ever tell vendors (and believe me, they’ll ask again and again) what your budget is for this project. They don’t tell you what deals they’ve cut when they’ve sold their product to other customers, do they?  Again, the fact that you are actively pursuing other alternatives needs to speak the loudest.

• Remember, though, that your goal is not to hammer down the price so far that the vendor won’t make any money on the deal. You can do that, at times, but it ultimately means that you’ll get poorer service and less attention when you need it.

• Where possible, involve your legal counsel in the negotiations; don’t just bring them in at the end. The best negotiations for me, in terms of viable outcome, were where I had a tight bond and common approach with my legal counsel.

In the end, it’s all about getting a viable solution for your need, at a reasonable price and beneficial terms for all. It’s not really about “winning”; it’s about choosing. Give yourself choices, and in the end, you (and your organization) do win.

Lagniappe:

• Ward Keever, “Ten Keys to Successful Negotiations”
• Martin Ewing, “5 Can’t-Miss Vendor Negotiation Tips”
• Michael Krigsman, “Negotiation Tips for CIOs”
• Peter Kretzman, “More tips for dealing with IT vendors“

Roger Sessions recently published a white paper on IT complexity and its role in IT project failure: “The IT Complexity Crisis: Danger and Opportunity”.  It’s certainly possible to quarrel with bits and pieces of his analysis, and thereby tweak his numbers, but the overall thrust remains undeniable: IT failures are costing the world incredible amounts of real money. Sessions even sums it up under the dire-sounding phrase, “the coming meltdown of IT,” and says, “the out-of-control proliferation of IT failure is a future reality from which no country—or enterprise—is immune.” And he presents “compelling evidence that the proliferation of IT failures is caused by increasing IT complexity.”  He points out that the dollar cost of IT failure in the US alone is close to the cost of the recent US financial meltdown, and cites indications that the rate of failure is also increasing by 15% per year.

Roger’s paper is excellent and thought-provoking, and I recommend it highly. And I do agree with his view that complexity is the chief culprit in IT failure. That said, I think his argument focuses a little too strongly on one cause of complexity (unnecessary overcomplexity of architecture), to the neglect of other important factors.

To be sure, some obvious contributors to IT failure (poor project management, and lack of communication within teams and from business to IT implementers) aren’t dismissed by Sessions, but he sees their contribution to the crisis as relatively small. I don’t, and I’ve used this blog to write about those factors quite a bit.

Most of all, though, I differ with Roger’s focus on streamlining architecture as being the key to reducing system complexity. One could say, in fact, that Roger’s solution is primarily a technical one, where the bugaboos I see are primarily cultural and sociological.  I see not one, but at least three distinct complexity-related burdens, increasingly endemic, and increasingly bringing down IT:

• Overly complex design/architecture
• Taking on too much functionality
• Poor implementation (technical debt in-the-large and in-the-small)

Roger has admirably dealt with the issue of overly complex design/architecture, at least in terms of a viable approach for simplifying up-front architecture, so I’ll focus here on the other two.

Taking on too much functionality

I recently rented an economy car (the least expensive option) on a trip with my son. (Remember, my self-appellation is “Cheap Technology Officer.”) He was stunned and dismayed that the car didn’t have automatic door locks; he didn’t realize that they even made cars without them anymore. Similarly, my 11-year-old daughter has grown up in a TiVo-ized world where live TV can always be paused. When she encounters a TV without a DVR (and thus no pause capability), she regards it as hopelessly primitive. Indeed, as unacceptable.

Similarly, the general standard for functionality and UI design has been raised by extremely functional PC software.  I now expect to be able to double-click on a number in any onscreen report, and thus “drill down” into the transactional details that make up that number. When I can’t, I feel cheated. Equally, I expect everything on an interface to drag and drop; I get frustrated if it doesn’t.

So as an industry, we’ve raised the bar of acceptability, considerably, in software and technology systems over the last couple of decades.  What that means in practical terms, though, is that across the board, our eyes have gotten bigger than our stomachs. We want more, up front, than it often makes sense to build at the start. And our demands are not negotiable, or so it seems. The first few cell phones I had didn’t even have a ring silencer on them; I used to silence the phone by adroitly disconnecting the battery when a call came through at an inopportune time. Today, most people wouldn’t even consider buying a phone that lacks much more elaborate features, such as a camera, that I would have considered as space-age in nature back in the 80s.

So our increase in expectations, alone, has added considerably to the functionality of systems we tend to build. There’s more functionality in and of itself, and usually more interface points to other complex systems. In fact, integration testing—where you connect new code into a working environment where it has to interface correctly with other systems—has become a frequent and major sticking point in launching information technology projects.  In essence, we’ve fallen into the “nuts” dilemma, both in large and small ways.  We want so much, and attempt so much, that we increase our risk of failure considerably.

Technical debt (in the large and in the small)

Any software developer will tell you that their first stab at implementing a given piece of functionality is often (if not usually) much more complex than turns out to be needed. Only after exploring the problem domain, with experiments and backtracking and restarts, do developers usually realize that their code can be pared down, simplified, combined with other modules, etc. This is usually called “refactoring”, and its importance is a relatively recent insight in the software development discipline.

A key insight about refactoring, though, is that it means improving the code without changing its overall results. There’s often no immediately obvious payback to this undertaking: it’s a roof project, in essence. To the extent that refactoring isn’t done (no time, no inclination, no recognition of a simpler approach), the end product is left with vestiges of unnecessary complexity. The greater the time crunch, and the greater the aspiration for the functional depth and breadth of the software to begin with, the more likely it is that these vestiges linger. And one ancillary aspect of the raised bar in expected minimum functionality is that it causes the time crunch to get ever greater.  It’s no longer about delivering just a solution that will work, it’s about making sure that the solution includes (metaphorically speaking) a 5-megapixel camera too.

Couple this unnecessary but accidental complexity with what often amounts to a rush job on design for the sake of meeting schedule (creating “technical debt in-the-large”). An example I’ve used here before: choosing a different core DBMS to implement a given function, simply out of expedience, and failing to take time to modify previous functionality to use that new DBMS. Supporting two DBMSes within the same product represents significant technical debt: every subsequent system change and addition will entail “paying interest” on that debt, which not only increases schedule and manpower costs, but increases risk of failure as well. And that’s just one example; the technical debt cascades, feature upon feature, release upon release. Technical debt, until paid down, can be equated to a invisibly rising substrate of complexity, and it contributes massively to an increasingly wobbly, risky system. And lately, I see more and more organizations “pyramiding” their technical debt, never taking the time and cost to pay it down, with disastrous results. As Hemingway said about going broke, it happens slowly, then all at once.

What now?

Roger’s analysis, to its large credit, outlined an important aspect of complexity and posed a solution (an approach he calls SIP, or Simple Iterative Partitions).  The aspects that I’m presenting (taking on too much functionality, and the pyramiding of technical debt) are, as I’ve said, cultural and sociological within companies. The answer is not nearly as simple or as neat as a specific technical solution (although I am certain that I will get comments on this post, perhaps rightly, from devotees of Agile).

To my mind, it’s engaged, savvy, forceful leadership that alone can address these issues, slow down the demand train, stop the madness. If anything, I think that there is an increasing lack of leadership in IT circles that can suitably recognize and address these factors, as well as educate their peers. And that’s what needs fixing most of all.

Lagniappe:

• Kevin Schlabach, “Agile East 2009 by Thoughtworks”
• Martin Fowler, “Technical Debt“
• Eric Ries, “Embrace technical debt”
• Johan Lindberg, “Painting With Hands and Feet: The IT Complexity Crisis”

Just a quick, personal post this time: I was recently interviewed by CIO Magazine on the topic of “How CIOs Can Stay Tech-Savvy“.  Since (as is normal) only a portion of my conversation with the reporter actually made it into the article, I thought I’d expand briefly on the topic here.

My remarks were two-fold, consistent with what I’ve written before on this all-important topic:

• It’s critical for the IT executive to “keep his or her hand in” by doing some hands-on work and experimentation with new technologies
• Your purpose in doing this hands-on work is not to become a viable technical resource in the area, but rather to get some deeper understanding than you’d obtain by just reading an article or two.

As mentioned in the article, I estimate that I spend 5-10 hours a month doing this kind of hands-on dabbling, sometimes with more success than others.  Let’s look at the kinds of things I do, large and small:

• Obviously, I administer my home network (four machines running three different operating systems, plus other home networking devices) and provide advice to neighbors and friends.
• I administer my blog, including configuration, changing WordPress templates, and even custom-coding PHP callbacks at times.
• I also actively seek out “early adopter” opportunities with new technologies, or technologies that are simply new to me.  I currently have four virtual machines that are launchable on my Mac: Ubuntu, Fedora 11, Windows 7, and Windows Vista.
• I have an ongoing Javascript dev project I work on that analyzes my iTunes music library and helps me identify gaps in metadata and lyrics, so that these can be corrected. That Javascript also dumps all the lyrics in my music library out into XML, to get them out of the proprietary world of iTunes.
• At the beginning of each year, I list out the technologies I’d like to delve into more deeply that year, in terms of reading and experimenting.  This list is based purely on what has intrigued me as I’ve scanned blogs, feeds, and Twitter. For 2009, my list included Amazon EC2 and S3, Ruby, Heroku, and CouchDB.  I’ve not gone as far as I’d hoped with a couple of these, but hey, 2010 will have a list too.
• In a given year, I might do some coding in Javascript, Perl, PHP, and Ruby. Admittedly, I usually need to look quite a bit of stuff up, but that’s mostly a factor of doing this only an hour or two a week.

As I emphasized in my remarks for the article, the point here is not to become a player on the field. I’ll never be as skilled in any of these technologies as the people I’d hope to hire with that expertise, should the need arise.  And that’s a good thing: the temptation is always there, particularly for someone who rose up through the developer ranks, to micromanage.  But at the senior executive level, it’s far more important that you stay focused on process improvement and strategy than on nuts-and-bolts techniques. Any of the experimenting I describe above should be viewed as self-education and a hobby, not a serious endeavor.

But you can bet that my self-education practice lends me a deeper insight into any of these technologies than if I’d sat back and simply read magazine articles on them. And oddly, I’m one of the few senior IT executives I know who still do this sort of thing. Granted, it will always feel to me like it’s too little, but not doing it at all is, well, not an option.

Key question of the day: given the recognized ascendancy of business/IT alignment and business change management as a vital purview of the effective CIO/CTO, should senior technology executives decrease their emphasis on technology, and focus primarily on corporate strategy and change? Should the company just have one role (call it a CTO, perhaps) do all that technical stuff, and move the CIO role into that of predominantly business strategist?

Let me raise my hand for the Nays. That would be the pendulum swinging way too far in the opposite direction. The problem of business/IT alignment won’t be solved by ghetto-izing technology concerns, and/or pretending that an executive is really only part of the senior team if she/he has a mostly strategic orientation and little responsibility for technology. That’s called a backlash, and it’s bound to lead to trouble. Here’s why.

It’s long been pretty close to a received truth that a key success factor for IT is to forge deep alignment with the business.  And that’s been an elusive goal. Indeed, one CIO Magazine article from way back in 2004 referred to business/IT alignment as a “Holy Grail”.  More recently, a Forrester survey discovered that “only 15 percent of IT leaders declared themselves to be fully aligned with the business.”

I’ve posted myself, early and often, on myriad ways to push effectively for IT/business alignment. So I’m anything but a blind proponent for a technology-centric CIO/CTO.  But now let’s talk about the backlash I’m seeing, and use it to reemphasize my point from the last time I wrote directly about “CTO vs. CIO” on this blog: it’s not the title per se that matters, but that a company have a single, key, senior information technology executive who is tasked with shepherding information systems strategy, decisions, and ongoing projects company-wide. Note, however, that as I stated last time, “The important part is to recognize two conflicting truths: technology is all-important in many leading and bleeding-edge companies today; technology itself, however, cannot be the sole, or even the main, focus and purview of the senior technology executive.”  Elsewhere, I wrote that “It is absolutely critical that the CIO/CTO be the chief voice at the senior management table, when it comes to educating and advocating the judicious undertaking of “roof projects” when necessary.”

What I’m seeing recently, as I wade through countless magazine articles and books on IT management matters (let alone hundreds of tweets from colleagues on Twitter), is a movement towards deprecating the need for strong technology leadership at an executive level. If past IT executives have been overly focused on technology and not enough on business value, then the answer must be (per this backlash) that the IT executive should move away from focusing on technology, put that in the hands of others, and move instead toward business, innovation, and shepherding corporate change.  Specific examples of the backlash:

• “There’s no “T” in CIO”. In Chris Potts’ loosely fictionalized (and excellent) narrative, “The CIO as a Corporate Strategist,” he has a CEO reflect as follows: “Maybe it’s the constant reference to technology that’s getting in the way of understanding what the CIO role is really all about. After all, CIO doesn’t even have the letter T in it.  What if we took technology away from the CIO and focused him uniquely on Business Leadership? What then could the CIO role do for us?”  Elsewhere in the same article, Chris writes that “in-house IT management has increasingly become about sourcing and supplier management. Maybe one day, [the CIO] speculated, the company’s sourcing people should do all of that instead.”

• “‘There are no IT projects, only business projects,’ is the frequent imperative of many CIOs and IT leaders.”  A number of us had a raging debate on Twitter about this. While it’s certainly true that all projects must have business justification (e.g., revenue enhancement, strategic impact, cost saving, legal imperatives), there will of course always be projects that have little or no direct, short-term impact on the business stakeholders of the company, yet are critical to do.  See my recent post on “roof projects”.

The backlashers (to coin a word) are right in their emphasis on business strategy and change, and yet they are wrong: they are throwing the baby out with the bathwater. My experience has taught me that technology management cannot be dismissed as purely a lower-level activity, with the senior executives in the company able to take a hands-off approach while they evolve their strategy.  In fact, the problem is that too often, technology management has been placed in the hands of people who had only a lower-level approach and perspective.  Doing that has resulted in exactly what you’d expect: a lower-level perspective. Hence the stereotype of the unresponsive, uncommunicative, difficult IT organization, often working on matters that aren’t congruent with the business needs of the company.  Or, conversely, IT has been “managed” by people who weren’t at all technology-oriented, who have then proved ineffective, open to vendor manipulation, staff disrespect, and a steadily increasing “herding cats” mentality on technology matters.

The answer is not to reject IT as an important purview of a senior-level executive (call that person a CIO or a CTO, as you wish) in a company.  The issue is getting a senior executive who will exercise the right balance between technology and business strategy. Downgrading “pure tech” matters to a non-senior executive leads to the same old rut: tech decisions made poorly, with tunnel vision.  Instead, the CIO needs to straddle a midpoint on the business/technology spectrum, not swing to one end or the other. You can’t have one person (say, the CIO) responsible for strategy and still another (say, the CTO) responsible for technology. It turns out that you need the combination: a senior executive who is part of the strategic definition for the company, and who can ensure that the day-to-day decisions in information technology will be made accordingly. In other words, companies need to recognize that business projects can fail equally through technology tunnel vision or through too little attention to core technology matters by executives who spend their time elsewhere on matters they deem more “strategic”.

In fact, if there is no (or the wrong kind of) executive in charge of technology, one sees effects such as the following:

• technical and applications architecture tends to grow haphazardly, becoming increasingly inflexible and unwieldy;
• no metrics are gathered, much less used for continuous improvement;
• open season reigns for vendors, who then deal primarily with lower-level buyers who often lack the big picture financially and strategically;
• the “dev guru” phenomenon appears, where the company is dependent on one or two individuals and there’s insufficient cross-training;
• no delivery commitments are made—or commitments are made with no factual basis;
• silos appear in Ops, QA, Dev, PM, often at cross-purposes with each other;
• Multiple points of entry into IT abound for business folks. What gets worked on depends on personality, not corporate exigency;
• little process improvement is considered or exercised;
• “IT sourcing” groups emerge that become sheer order takers for stakeholders who’ve been swayed by a vendor demo.

For further examples, consider the points I made in a recent post, “Canaries in the coal mine: Why your IT department may be in worse shape than you think.”  To avoid these and other examples of IT failure, companies need to place at the helm of information technology an active, savvy executive, serving as a peer of the senior executives in the company, and they must look to that individual for leadership, guidance, and day-to-day influence.  Should that person have the title of CIO or CTO? That’s not the right question, because it doesn’t matter.

Related posts:

• “Yes we can, yes we must: the ongoing case for IT/Business alignment“
• “Countering a disturbing bandwagon: rich vs. poor IT organizations”

As I’ve written here before, I strongly advocate thinking of IT in general as a service organization to the rest of the business.

Any service organization needs one or more forms of “feedback loop” to be able to gauge whether it is successfully accomplishing its mission.  However, I’ve observed relatively few IT organizations that actively seek to implement such feedback loops on a regular basis.  At best, the IT executive does it informally by consulting with his peers at the executive table.  But with any such anecdotal feedback, the information gathered that way tends to be fleeting and unreliable, and it is especially influenced by strong personalities and emotions during crisis situations.

Here’s a better, and simple, suggestion, one that I’ve implemented to varying degrees at several firms with a good amount of success: Survey your constituents regularly and then publish the results.

Sounds daunting?  I promise it really isn’t, not in this day and age of easy-to-use web-based surveys.  With less than an hour of work, you can design and initiate a survey using a free service like Zoomerang or SurveyMonkey, and easily gather high-quality results (reports and statistics) in just a few days that can help you gauge (and present) how you’re doing.  Here’s how.

You actually need to think about three broad groups of constituents whose pulse you want to take regularly (at least once a year, preferably more):

• internal customers (your help desk customers)
• peer executives and key business stakeholders
• your IT staff

I’ll focus here primarily on the surveying of key business stakeholders.  For the first category, you need to get a trouble ticketing system that incorporates user surveys after each ticket closure.  For the third category, well, that deserves a whole other post to discuss, since in some ways, it’s the most complicated and pitfall-riddled area of all.

For stakeholder feedback, most importantly, you need to start off (within the first few weeks of engagement in your role) by getting a general “baseline” understanding of current satisfaction, on the part of internal key business stakeholders, with IT in general.  Of course, don’t let a mere survey ever substitute for actually getting out and talking to as many people as possible about how good the service has been from IT.  When you send the survey out, emphasize to everyone that their input is anonymous, unless they choose to identify themselves in their comments. All you will know is whether or not any given individual has completed the survey.

Keep the survey as simple as possible, and you’ll get more responses.  You’ll want to balance free form input (usually just one broad question) with questions with quantitative answers, ones that will let you accumulate metrics over time.  And you’ll need to be prepared for some harshly stated criticisms, so get used to that idea.

Here are some sample questions I’ve asked in such surveys:

1. Compared to other companies you’ve worked at, how would you characterize the overall level of service of IT at this company?
Choices:

2. Of the following areas of responsibility of the IT department, which ones would you say most need improvement? (pick all that apply)
Choices:

3. Of the following areas of responsibility of the IT department, which ones are currently being handled especially well, in your view? (pick all that apply)

4. Compared to six months ago (assuming you were here at the company then), would you say that the IT department’s overall service to the company is…

5. Please give the IT department an overall rating on a scale of 1-10 in each of the following areas, with 10 being perfection.
Choices:

6. What other general comments do you have regarding IT, interaction with your team and department, etc.?

Send out the link to the survey in an email, explaining your purpose and goals in doing so.  Give your stakeholders (hopefully at least 20 people across the business; don’t arbitrarily limit it!) at least a week to respond, and nudge them every few days with reports on how many have filled out the survey so far.

When the survey finally closes, thicken your skin a bit (OK, maybe a lot) and take a good amount of time to look carefully at the results, and to compose a report to the people who responded.  By doing so, you’ll be showing that you take the feedback seriously, and have focused on specific action items as a result.  Then, you’ll want to send out the survey again in no more than six months; your subsequent report there can talk about the specific actions that you took in response to the last survey.

The good will generated by this service-oriented approach should not be underestimated.  Face it: it’s the right thing to do, and people will instantly recognize that.  As Mark Twain famously said, “Always do right. This will gratify some people and astonish the rest.”