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

The One True Way syndrome exemplified: the overstated case against code comments

I write frequently, and not without some exasperation, about the perennial search for the “silver bullet” in IT: the holy grail, the end-all, be-all solution to preventing IT failure.

The silver bullet has a very close and similarly pernicious internal twin cousin: the One True Way. That’s a technique or practice that is (usually) adopted by its IT aficionados as the key to overall success, with the important insistence that it will work as long as you follow it to the letter, in all cases, no matter what.

So this post will seemingly be about a specific (and low-level) development issue, but it’s only to serve as an example to illustrate this One True Way syndrome that is so prevalent in IT. At core, my takeaway boils down to the same old message I usually have when it comes to IT matters: be wary of something promising to fix all your problems. Be wary of absolutes. And be especially wary of the combination.

[Read more…]

Valuable vs. fun: learning to love IT Asset Management

My attitude is that if you push me towards something that you think is a weakness, then I will turn that perceived weakness into a strength.

– Michael Jordan

As with so much in life, so it goes with IT: the parts that are fun aren’t always valuable, and the parts that are valuable aren’t always fun. Let’s talk about a hugely valuable side of IT that isn’t really much fun at all. And when it’s not fun, that means that it’s often neglected, and thus turns into a great weakness.

IT assets (hardware, software, systems, services) represent a major investment for most firms today. For “new economy” companies in particular, the cost of such resources (both bringing them on board and maintaining them as corporate assets) often exceeds expenditures in any area other than wages and benefits.

It’s astonishing, then, that firms (not to mention IT management specifically) don’t always embrace the ongoing hard work required to maximize the value of those expenditures and minimize the corporate risks involved. All too often, I see IT asset management (ITAM) neglected by IT executives because, well, it involves a discouraging amount of drudgery to do it right, especially over the long haul. This neglect occurs even more often when an executive succumbs to the latest faddish push for IT to focus on strategy and innovation to the detriment of fundamentals.

[Read more…]

IT entropy in reverse: ITSM and integrated software

Why am I an IT professional? Here’s one major compelling reason: you simply can’t rest on your laurels. You can’t stop learning and growing and examining and improving, in all aspects, or you stagnate and die. The best IT professionals, I’m convinced, work energetically and on an ongoing basis, actively striving to push the scales from their own eyes at every juncture. It’s part of the job.

Last week I had the opportunity to attend what was my first industry conference in almost 8 years, Knowledge12, put on by ServiceNow, a software-as-a-service (SaaS) provider of IT service management (ITSM) software. (See my post explaining why I’ve tended to avoid industry conferences in recent years). And to my surprise and delight, I discovered that it was well worth the time. Let me share my thoughts on why.

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

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

We don’t like that estimate. Change it.

CIO: “We can’t go live in six weeks as you want.  It’s going to take at least three months.”

CEO: “That’s … unacceptable!

One of the most recurring memes in IT, for me, has to be hearing “we don’t like that estimate”, coming from stakeholders, senior management, etc. Depending on the mood and/or semi-intellectual rigor of the person saying it, the conversation then typically devolves into one or more of the following:

  1. identifying and removing any hint of schedule contingency (which is often viewed as padding just to make life easier for IT);
  2. mentioning repeatedly the idea of “what if we double the team size to get it done twice as fast” etc.;
  3. conducting a scrutiny, one by one, of the bottom-up estimates (”it won’t really take three days to test that feature”);
  4. volunteering resources (usually less than qualified) to “help”;
  5. insisting on scheduling full-time work for all remaining weekends and holidays between now and the desired launch;
  6. making frequent use of the phrase “why don’t you just …”
  7. declaring that system delivery must occur by a specific date, no matter what.

[Read more…]