Novels of IT, Part 1: Turtles All The Way Down

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.

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.

[Read more…]

Three IT behavior patterns seen in the wild

Assumed Omniscience, Chooser’s Remorse, and Fixation

With all due respect to the many fine folks I’ve worked with in the career I’ve spent decades pursuing: we IT types can be an idiosyncratic, even odd, bunch.  That’s actually well known to us all, and it generally makes great fodder for this blog.

I find the sociology of the profession—how people interact with one another—as fascinating as everything else about it.  Here are three interesting behavioral syndromes I’ve observed over the many years of IT projects and teams I’ve been a part of. And as with most of my observations of this nature, I’m not presenting them from “on high”: no, I’ve been at times as susceptible to these behaviors as anyone. They’re common, and easy to fall into, but all of them are things I strive to avoid. And all of them have a common thread, as you will see.

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…]

Mending Wall: Matches and mismatches in IT stakeholder expectations

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

Case in point: I was shown an astounding list of generic stakeholder expectations a while back, drawn up by an obviously frustrated group and titled “USER REQUIREMENTS FOR IT”.  The list is most interesting in what the items reveal between the lines. Let’s examine what probably caused this group to write down these specific but very abstract needs.

User requirements for IT

  • Must be adaptable to business situation
  • Must be able to employ multiple SDLC (Software Development Lifecycle) techniques as the situation dictates
  • Must be able to work in a highly parallized (sic!) environment
  • Must be able to accept and adapt to last minute scope
  • Should have multiple channels for functionality development both in terms of large releases and off cycle enhancements that occur in parallel.
  • Must provide the ability to externalize functionality to external teams to quickly develop new functionality
To most IT professionals, these come off as “unreasonable” demands at first examination. But they’re both understandable and revealing, if you take the stakeholder point of view, and if you remember the oft-cited adage that all progress depends on the unreasonable man.

Business impact and transparency: expressing system availability

“System availability was 99.83% last month!  That’s up from 99.75% the previous month!”

Sounds kind of good, no? I mean, that’s a high number, right? Right?

Actually, no.  It’s not a very useful number, in and of itself. In fact, I regard the publication of uptime metrics like that as a regrettable symptom of IT focusing on technical aspects, rather than business impacts.  Here’s a discussion of why I see it that way, followed by a presentation of an alternative focus providing much more business value.

So, what’s wrong with a time-honored metric like “the system was 99.83% available”?

  • The number is deceptive. Few people can mentally translate “99.83% availability” into a more meaningful real number, such as “system was down for 1.3 hours last month.”  Even fewer can tell you the real difference between 99.3% uptime (also sounds pretty good, right?) and 99.8% uptime.  Both 99.3% and 99.8% look (to the vast majority of business people) at first glance like pretty good numbers for uptime, but the first represents more than three times the number of “down hours” of the second.

[Read more…]

One CIO’s “lessons learned” in managing others

Here’s a shocker: none of us has failed to fail at times.

We’ve all screwed things up on occasion, and I’m no exception. And that’s especially true when it comes to managing others, which I believe is very much a learned skill. In that spirit, there are a number of things about people management (call them reminders, admonitions, lessons) that I’d especially want to tell my younger self if I had a time machine. Each one arises from a situation where I’ve learned a lesson the hard way over the years, either from mishandling something myself, or from watching a peer, colleague, or my own manager mishandle it.  As the saying goes, “Good judgment comes from experience; experience comes from bad judgment.”

So here are a few things to keep in mind when managing others.  These lessons have arisen from (largely) IT situations, but their scope and impact is hardly limited to IT.  They’ve become a capsule summary of how I want to manage, and how I like to see people around me manage others.  In fact, when I encounter an instance of “bad management”, or think back on my own missteps, I can almost always point to a deficiency in one or more of these specific areas as the underlying root cause.In no particular order:

“ASAP” considered harmful

When do you want it?  “As soon as possible”, comes the ready answer.

Everyone says it. Everyone knows what they mean by it, in essence, and it seems fairly harmless.  But more often than not, I’ve seen it overused as a substitute for real thought and real leadership.

Especially in this new era of “internet time”, the declaration of “I want it ASAP” has often turned into an excuse not to plan, a rejection of due diligence and careful preparation, or even an intentional ignoring of previous lessons learned.  Taken to an extreme, it can represent the triumph of pure testosterone over diligence and caution.

Meg Whitman, former CEO at eBay, writes in her recent book, The Power of Many: Values for Success in Business and in Life about how one positive performance differentiator of individuals at eBay was their sense of urgency.  “eBay never would have prospered as it did without a team with a strong bias for action,” she states.  Having worked in a couple of places that were unnecessarily and infuriatingly slow in their decision-making, I too tend to generally applaud a bias towards action in business.  It reflects a philosophy that an imperfect plan executed right now is usually better than a perfect plan executed next year.  Or, as Seth Godin puts it in his book Linchpin: Are You Indispensable: “Real artists ship.” Or, as a tweet I saw recently had it, “if you’re not embarrassed by the first launch of your product, that means you waited too long.”

However, one can take a bias towards action too far.

[Read more…]

Bears, hedgehogs, and Gladys Knight: parables of IT leadership

For years, I’ve had two framed items hung on my office wall throughout my various stints as CIO, CTO, etc.  I like to think of them, both individually and together, as reflecting certain truths or ironies I encounter as a technology executive, particularly in the realm of leading others.  They serve as cautions to me of leadership potentially gone awry.  So let’s talk about what they show.

The bear and the hedgehogThe bear and the hedgehog: “Vielleicht kannst du auch mal was machen”

The first is a decades-old cartoon taken from a German calendar, preserved from the years I lived in Berlin.
Two animals are playing on a seesaw. One is huge and bear-like, the other a small critter like a hedgehog.  As you’d expect, the bear outweighs the hedgehog, who dangles on the high end of the seesaw. The large one says to the small one, “Now make yourself heavy.”  The little one says “OK”, and voilà: the next panel shows the seesaw reversed, contrary to gravity and logic, where the hedgehog is now outweighing the bear.

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

[Read more…]