IT does the moonwalk: our endless search for absolutes

Scene: I was CTO at a high-traffic social networking site, circa ten years ago. It was one of those times when our site got crushed by unexpected sudden volume, due to being mentioned in an article in a prominent newspaper. My infrastructure manager walked into my office the next morning, ashen-faced. “We’re gonna get killed tomorrow unless we add ten front-end servers to our prod environment,” he proclaimed. A fairly common IT reaction: absolute, adamant, ominous.

Ten new servers? That was a nice round pulled-from-thin-air number, obviously, and by the time we talked through it, we actually found other, more practical, more feasible ways first to estimate and then handle the increased load. But to the infrastructure guy as he walked in, the situation was both dire and absolute, and he saw only one solution that should even be considered.

So now let’s look at another data point on IT psychology. Take the latest iPhone brouhaha: the quick “cracking” of the iPhone 5s Touch ID fingerprint scanning technology.  Amazingly, Touch ID has turned out to be less than perfect. Someone with $1,000 of equipment, plus lots of time, motivation, and patience, could conceivably fool the scanner. Meanwhile, what gets lost in the outrage over this turn of events is the notion that the technology might indeed be “good enough”, or “better than the alternative”. We forget the simple fact that the technology is primarily oriented to people who currently don’t use passcodes at all, and that it vastly improves general security for those sorts of users.  As one article pointed out, “The point of any security system isn’t to be unbreakable – there’s no such thing – but to be fit for purpose.”

My larger point: if there’s a problem or a difficulty or even a nuance to a particular approach’s applicability, a common IT practitioner’s instant reaction is that the approach or practice is absolute junk and should be completely avoided.

Similarly, we often reject fundamental improvements to a situation, simply because they are not perfect. We let “best get in the way of better.” On this general theme, an amusing tweet crossed my screen the other day. @rands wrote, “I find when an engineer says, ‘Less than ideal’, they often mean ‘Complete fucking catastrophe.’”  I laughed at this, of course, but partly because I’ve more often experienced that scenario in reverse: an engineer deciding, and then loudly and profanely proclaiming, that a situation was nothing short of a complete disaster, simply because it was less than ideal.

[Read more…]

Book review: The CIO Paradox: Battling the Contradictions of IT Leadership

It’s a universal trait, it seems: we all want to be understood, want the world to see things through our eyes, want to watch the “aha” light go on when people finally realize just how tough we have it and how magnificently we still prevail.

IT people, and senior technology executives in particular, are anything but exceptions to this longing. In fact, it seems that very few other disciplines have to put up with a constant stream of articles and books questioning our very existence, approaches, purpose, and worth (Does IT Matter?, the death of the CIO , etc.). Even the acronym CIO is commonly and gleefully referred to as standing for “Career Is Over”. And you want a downer? Just try googling “average tenure of the CIO”.

A person could downright get a complex here. No one seems to get it! No one understands how tough a job this is! No one seems to perceive the “damned if we do, damned if we don’t” intrinsic nature of our role. I present this syndrome with all due humor (“against the assault of laughter nothing can stand”, said Mark Twain), but I also mean it: is it utter masochism that leads us to choose this “whipping boy” kind of career at this level?

The CIO Paradox, book cover
That’s why it’s so welcome when a book comes along that effectively presents insight and understanding into the “big picture” struggles of today’s CIO, even combined with empathy and warmth. Martha Heller’s The CIO Paradox: Battling the Contradictions of IT Leadership, just out late last year, brims with “been there seen that” deep insight into many of the standard CIO predicaments.

[Read more…]

Novels of IT: The Phoenix Project

Nerd alert: it’s an exciting day for me when someone releases a new “novel of IT”. I’ve made it my mission to find and review several of these (now four) over the past couple of years, and I may be one of the few people out there who has read and reviewed all of them.

To recap: what do I mean by a “novel of IT”? It’s a term I coined to describe a fictionalized depiction of life in a corporate IT environment, usually bearing a number of intended lessons in tow about IT best practices, approaches, pitfalls. They’re generally not works of serious fiction; their audience is usually the lot of IT professionals rather than the broad public. (For example, I don’t include in this category two fine and recommended works that in fact aspire more to literature than to IT didacticism: Douglas Coupland’s Microserfs and Ellen Ullman’s The Bug).

As I’ve traveled through the fictional scenarios depicted in these four books, I’ve evolved criteria for what makes them successful (or not) in my eyes. In a novel of IT, I’m looking for a book that is both reasonably engaging as a novel and one that accurately portrays a broad swath of the inner workings, nuances, and personality types that are typically part of the landscape of IT in today’s world. Reading the book should provide a window into common dilemmas and disagreements regarding IT issues, lending perspective and insight into all parties’ motivations and interests.

I looked forward for many months to the release last week of The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford,  after meeting and chatting with Gene Kim at a conference back in May of last year. I was greatly impressed at the time with Gene’s general demeanor, enthusiasm, and articulateness. He gave a rip-roaring presentation at the conference on “ITIL at Ludicrous Speeds: Rugged DevOps”: I recommend seeing him speak if you get the chance. I felt certain that his long-promised “novel of IT” would be a worthy addition to the collection of works in this category.

[Read more…]

Novels of IT, Part 3: Adventures of an IT Leader

My long quest for an insightful, broad, and practically applicable “novel of IT” finally met with resounding success, once I got my hands on the outstanding book that is the subject of this post: Adventures of an IT Leader, by Robert D. Austin, Richard L. Nolan, and Shannon O’Donnell.

To recap: I was looking for a book that was both reasonably engaging as a novel and one that accurately portrayed a broad swath of the inner workings, nuances, and personality types that are typically part of the landscape of IT in today’s world. Reading the book should provide a window into common dilemmas and disagreements regarding IT issues, lending perspective and insight into all parties’ motivations and interests. See my earlier posts on Chris Potts’ FruITion and John Hughes’ Haunting the CEO.  Again, my views aside, I should emphasize that all three of these “novels of IT” are worth reading and forming your own opinion.

Adventures of an IT Leader comes by far the closest to meeting the criteria I had outlined for a “novel of IT.”  It opens with an executive, Jim Barton, being unexpectedly tapped as CIO by the new CEO of his firm, after long and successful stints managing other areas of the company.  In short, Barton isn’t an IT person by training or experience. In fact, one reason for his selection as the new CIO is that he has long been the foremost critic of the IT function at his company. And now, unexpectedly, he has to walk a few miles in IT’s moccasins, so to speak. The novel then follows Barton and his numerous IT challenges and crises for about a year.

[Read more…]

Can a CIO be successful without IT experience? Define your terms!

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.

[Read more…]

IT tall tales and why they’re told, or, why I stopped going to conferences

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.
[Read more…]

Must-read books on the human factors of IT — part 1, the 70s

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 supposedly 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.

[Read more…]

Canaries in the coal mine: Why your IT department may be in worse shape than you think

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.
[Read more…]

Mastodon