If you’ve been in the information technology industry for a number of years, certain jokes tend to pop up again and again. Why? I’d say it’s because their underlying premises, the things that make them applicable and funny, continue to occur. So even if you’ve heard these before (and that’s probably the case), it’s worth taking a few moments here to look at them again and consider what makes them timeless.  Remember, even jokes have morals to the story. Sometimes especially jokes.

1) Just what they asked for but not what they want
Something that’s been drifting around the Internet for decades, it seems, are various IT versions of the famous poem, “Twas the Night Before Christmas,” usually called “Twas the Night Before Implementation.” I won’t include the whole text here; most notably, the poem ends with the “super programmer,” akin to Santa Claus, swinging into action and saving the day.  And yet, the final two lines read,

Who in IT can’t relate to this eleventh-hour disconnect between what the user “wants” and what IT has arduously created and delivered? Why does this phenomenon keep happening? A lengthy serious answer here would derail the intended levity of this post, but consider the following:  the long-standing industry practice of pure, unadulterated “waterfall“-style requirements gathering before design, build, test and deliver tends to lead to such disconnects. That fact certainly presents an argument for greater agility in the process, greater involvement of stakeholders throughout, and resistance of “big bang” approaches to systems delivery.

2) I had a truck like that once:

This joke almost always comes to mind whenever I hear IT people blissfully bragging about the complexity or size of their infrastructure, latest system, etc.  For example, most recently, my friend Gunner was telling me about his current development project, just entering User Acceptance Test: “Our programmers have gotten a total of 8 hours sleep in the last three days!”  “Yes, Gunner,” I replied. “I had a truck like that, once.”

Size, complexity, and lack of sleep are sometimes unfortunate realities, but they are rarely great things to brag about.  Don’t let your enthusiasm for what you’ve accomplished make you forget that simpler is nearly always better than more complex, smaller almost always better than large, and sleeplessness leads to bad decision-making in the trenches.

3) What you just told me is technically correct but of no use to me whatsoever

Rackspace, a prominent managed hosting provider, recently incurred a massive outage. Even though this is a company that prides itself on “fanatical service,” (and to be sure, is praised by many of its customers for providing such), on the day of the outage, it sent out a “customer incident report“, featuring sentences like, “The generators experienced a subsequent excitation failure forcing transition of cluster A back to the primary utility feed prior to the completion of UPS repairs.” Rackspace’s incident report is an amazingly bad example of jargon-laden, un-customer-oriented IT communication. There’s no discussion of real root cause (the breaker tripped, but why?) or specified action plan, just a bunch of seemingly nervous technobabble that lets no one understand what really happened, why it happened, and what they’re doing to ensure that it won’t happen again.

In other words, everything in their report is technically correct, but it’s no use to anyone. Sure, they were still in the throes of diagnosis, but that doesn’t excuse the plethora of excess detail and their failure to address what customers really are interested in. This kind of approach inspires negative confidence among one’s customers, needless to say.

4) Difference between a methodologist and a terrorist
This joke has also been around for decades. I stopped telling it for a few years after 9/11, but it continues to make a needed point:

I’ve frequently noted that some IT folks latch onto a particular methodology (Rational, Agile, Lean, whatever) and come to see it (and it alone) as representing pure, unvarnished guidance and truth.  If not brought back to earth, they can drift into a discipleship attitude that there’s really only “one true way” of approaching systems and projects.  If confronted with a failure in a project using their “one true way,” they’re quick to claim that the methodology wasn’t fully or correctly implemented (“If it doesn’t work, you aren’t doing it right.”).  This “one trick pony” perspective, a sort of tunnel vision that lacks introspection, creates a rigidity that’s almost always detrimental.

In fact, it tends to put you into situations where joke #1 is relevant.

I promised a while back to write more about some of the pet peeves I’ve developed in the CIO/CTO role. So here are a few more.

We all have pet peeves. Working as an executive in IT seems to present a lot of opportunities to develop a long list of these. They’re minor grievances, to be sure, but they also really matter, in that they drain away little smidgens of productivity or create frustration. And most are easy to address, so in the interest of enhancing the world’s productivity, I’d like to list a few of these. I’ll confine myself just to the ones that crop up at least once a week in the course of my workday. Consider fixing these a high priority to show good business etiquette and professionalism:

Pet peeves:

• Email aliases that aren’t of the form first.last@company.com

Yes, I know it’s rare that anyone has to actually type an email address from scratch. Nonetheless, when you do, you shouldn’t have to guess. Hmm, is Brian Wilson going to be brianw@xyz.com, or bwilson@xyz.com, or brianwi@xyz.com? Every company should standardize on the predictable, canonical form of first.last@company.com, at least as an acceptable alias. A speaker at a conference I just attended told the audience to contact him at kzw@company.com, and everyone actually had to scribble that down! He thought it was simple, no doubt, since it was only three letters. But the point is, you shouldn’t have to remember yet another token about a person. Even Microsoft, for its employees’ email addresses, doesn’t do this email address standardization right, at least not as a standard across the board.

• Documents (spreadsheets, in particular) that won’t print cleanly

If you make a document, even in this paperless world, assume that someone will probably want to print it, if only to read on the bus or something. Spreadsheets in particular need to be print-previewed and examined to see if they’ll print cleanly. Use the “Fit to” option, and shift from portrait mode to landscape mode where appropriate; use the “rows to repeat at top” option to get consistent headers on subsequent pages. It’s pretty irritating to print a document and discover that its columns are spread across four separate pages, unnecessarily.

• Documents that don’t have titles, dates, authors identified clearly on every page

Whenever I bring this one up to someone passing around an unlabeled, undated document, I always hear, “Oh, that’s because it’s only a draft, you see.” That’s all the more reason to make sure it’s labeled, since there are bound to be later revisions floating around. Excel and Word both have excellent header/footer functionality. Use it. While you’re at it, page numbers are also nice.

• Spreadsheets with empty tabs

90% of the spreadsheets I get sent have three tabbed worksheets: one with data (Sheet1) and two with nothing (Sheet2 and Sheet3). I then exercise my unavoidable and infamous anal retentiveness by diligently bringing up all three tabs to view, just to be sure I’m not missing anything (and every once in a while, sure enough, I discover data in one of the tabs I’d assumed was probably blank). Come on, everyone: the three tabs are the unfortunate Excel default (yes, you can and should change this, instantly, with any new Excel installation), put in place by Microsoft marketing, which spent no doubt countless meetings arguing over the best way to make sure people knew that tabs were a feature. (Count your blessings: the default for a previous release of Excel was 16 tabs for every workbook!) Get rid of empty tabs; they add no value. If you need a new tab, add it then. While you’re at it: if you do use extra tabs, please name them something meaningful.

• Email without clear subject lines

Email is my knowledge repository, often, representing an important trail of decision points and the reasoning/history behind them. I need to be able to find stuff in that haystack. Fill out a clear and specific header! For example, when I’m sifting through that haystack for a particular nugget, a vague subject line of “Question” isn’t nearly as good as “Question on CRM functional requirements deadline”.

• Email from close business associates (people I see at least once an hour) that still have to begin with “Hi, Peter”.

It’s a business email, not a personal letter. Salutations aren’t really necessary. I promise: I won’t think you rude for omitting one.

• Email that doesn’t copy the thread of discussion (when germane) at all

See above point about the need for subject lines. When I’m cruising quickly through email, I don’t want to have to pull up other messages to retrace the flow of discussion on the topic.

Little things, minor irritations, all of these… so why not avoid them?

Just a quick one, this time, in what may become an ongoing motif of describing some of the pet peeves I’ve developed in this role.

For years now, I’ve been unable to answer my desk phone. Or rather, I’ve been unwilling to answer it, at least for calls that I can tell are coming from sources external to my own company.

Nineteen times out of twenty, any external call is almost certainly a cold call from a software or hardware or services vendor. It’s as bad as dinner hour used to be at home, before the advent of the National Do Not Call list. Sometimes I even detect the telltale blank pause that occurs while the automated outbound dialer, robotically jumping for joy at having landed a live one, is routing the call to a real person. The caller is often obviously reading from a script, rapidly.

They want to impart things along the following lines:

• Can they take me to lunch, or coffee, and discuss my upcoming initiatives;
• Am I aware that they can save me many thousands of dollars, if not hundreds of thousands, with their product/service;
• They have a uniquely topnotch, crackerjack, CMM level 5 offshoring team, in Bangalore/Vietnam/Russia/Argentina/China/Dominican Republic etc., that can provide high quality development or tech support or QA at a mere fraction of my current cost;
• They provide flexible staffing and have the best technical folks in town overflowing their rolodex;
• They’ve recently talked to Executive X at my company, who kindly directed them my way, maybe even gave them my number. (Thank you very much, executive X!)

Once I’ve taken the bait (i.e., once I’ve actually answered the phone, against my normal habit), it’s at best time-consuming and at worst extremely awkward to gracefully end the call in any manner that constitutes the normal politeness I try hard to muster in the workplace. Some people simply refuse to hear no, even when repeated, even when firm. It’s almost as bad as trying to cancel AOL service. Getting even one or two of these calls, at least when it’s the persistent ones, is almost guaranteed to ruin my day.

I’ve taken to the following strategies:

• No more external calls. Ever. If I want someone to be able to reach me, I give them my cell phone number. Not only do I have more accurate and customizable caller ID capabilities on my cell phone, it’s more likely to reach me when I’m roaming the halls.
• I put a firm outgoing voice mail greeting on my line, in which I explain that due to the volume of calls I get, I greatly prefer receiving e-mail, especially from possible vendors. I also ask that they not leave a voice mail at all, but instead provide me with material via e-mail. And I give out my e-mail address in that greeting.
• Then, I try (not always succeeding 100%, admittedly) to answer each and every one of the resulting e-mails that I do get from people who have called first, even when I’m expressing a complete lack of interest in pursuing their offering. It especially amuses me, though, when people leave a lengthy voice mail message, despite my request, ostensibly to tell me that an e-mail is on the way from them.

All humor aside, I do understand that sales is hard, and making meaningful contact with potential new business must be one of the trickiest things in the profession. But for the sake of my own productivity, I do have to function defensively, and preserve my time and efficiency against these repeated and often insistent encroachments.

I’ve been in this mode, exercising these strategies out of sheer necessity, for well over a dozen years now, at several companies. I can’t imagine that my situation here is really any different from any other IT executive. Which makes me wonder sometimes: just why do we still have desk phones at all?

In honor of the season, I thought I’d share a few recurring nightmares, ones that unfortunately don’t seem to confine themselves to the fall time frame. All of these are chronic worries that have truly kept me up at night; most of them stem from actual real-life situations I’ve encountered.

1. Your CEO calls you and asks you why the web site is down… and you didn’t know it was!

When the company’s web site (or any other mission-critical system) is down, escalation mechanisms need to inform you and inform you fast. Of course, the site should rarely / never be down other than for scheduled maintenance, so putting yourself in that notification loop (subject to calls in the middle of the night) shouldn’t be too common and painful. If you’re not informed of these situations, I’d argue that either your team isn’t sufficiently on top of detecting them, or they’re “sparing you the pain” of being told. In truth, the pain has to be spread around. The onus of notifying management is one mighty incentive to make sure that the need to do so arises as seldom as possible. Don’t tolerate being part of (much less at the helm of) an organization that purposely or through omission sweeps things under the rug.

2. Sudden night sweats: “I’ve spent too much on infrastructure!” Or, just as bad, “I’ve spent too little on infrastructure!”

Do you know for sure that you’re not in one or the other of these situations? Are you really prepared to scale to a degree that reflects with your growth? Do you have metrics and processes that support a methodical capacity plan in general? In my view, the “C” in CTO should stand for “Cheap”, because it’s remarkably easy to be the Expensive Technology Officer, rather than the Cheap Technology Officer. But in truth, the C should also stand for “Commensurate”: i.e., you want to build for your anticipated growth, but not be too far ahead of that curve. Anything else (too little, too much) is the making of nightmares.

3. Your software architecture looks fine now but won’t scale.

This scenario covers the possibility that one day you’ll cross some unknown threshold (data volume, for example) where response time or other key metrics go massively and suddenly south. How do you mitigate this nightmare? Well, the paranoid among us will never lose it entirely, but the best (perhaps the only) approach you can take is to conduct intense design reviews, evaluating for potential performance and throughput bottlenecks that could crop up. Another approach (often ignored) is to plan proactively for data “deadwooding” operations. Example: a high-volume web site that has people register should periodically eliminate those registrants who never logged in again within (say) a year of registering. Business users will often clamor for retaining everything, but there’s a real (and looming nightmare) cost of doing so.

4. The system goes down and you … can’t…. get…. it…. back…. up.

Today’s systems are frightfully complex, with lots of interconnecting moving parts. I’ve had times, while sitting through a middle-of-the-night crisis conference call discussing a badly non-functional system, where this kind of desperation started to set in. No matter what we tried, the system wouldn’t respond. At times like this, you start to wonder if it ever will. Mitigation? Remember that it always does, one way or another. It may not help the nightmare. This one’s a doozy.

I commiserate with all of you who may have experienced these and others. Sominex only goes so far to soften the impact of these nightmares. Rather, careful and methodical risk mitigation planning beats pharmaceuticals every time, in my experience.

Lagniappe:

• Paul Chard, 10 IT Nightmares and How to Avoid Them.
• Deloitte and Touche, The Risk Intelligent CIO: Becoming a Front-Line IT Leader in a Risky World

Enough serious posts for the moment: it’s time for a little bit of humor, hopefully with a moral or two in tow.

About 15 years ago, when I was still a director and not a C-level executive, I worked a great deal with vendors providing services, project management, software development, and so on. In particular, my company chose to enter an extended and extremely expensive relationship with a well-known large consulting firm, which was given near-total management control over resource allocation (meaning their own resources) and an apparently unlimited budget. For the next three or four years, I worked closely with them, Biedermann among The Firebugs, working to maintain a semblance of integrity and direction for the project and for my company’s financials.

In the course of all that, I heard certain earnest promises repeatedly, and came to regard such statements as canaries in the coal mine when dealing (especially in the early sales cycle) with new vendors. At the time, finding some strength in humor, I dashed off the following list, which I’m repeating here with some commentary. If you hear any of these statements from a vendor (not to mention several such utterances strung together in an elevator pitch), my strong advice is FAV: Find Another Vendor.

In true David Letterman style, here’s the Top 10 List of Vendor Statements, with annotations.

10. We want to partner with you.
What do they mean by this? To me, a partnership would mean some kind of true sharing of effort, cost, and risk. Instead, the real meaning behind this statement is usually that they’d like to be your principal (or sole) provider in this area. This kind of “we bill and you pay” partnership is anything but. Probe them for what this “partnership” will entail, and work to make it even-handed.

9. Your company is one of our most important clients.
And talk is cheap. How does the vendor demonstrate your importance to them? There are only a couple of ways: preferential service and/or cheaper rates. Ask for something solid along these lines.

8. We’re barely making any money here.
As defined by what? The big consulting firm that told me this most often (this would be the same firm that was billing my company in excess of $3-$4 million dollars per month, with about 100 of its consultants engaged on site at rates exceeding $175/hour) defined “making money” as when they exceeded an already high (and arbitrary) markup percentage on their people.

7. We give you only our best people.
That’s possible, I suppose. But are they saying this to everyone? This claim reminds me of Garrison Keillor’s welcome to Lake Wobegon, “where all the women are strong, all the men are good-looking, and all the children are above average.”

6. If you don’t like one of our people, we’ll roll that person off the project right away.
Here I’m burdened with history: when push came to shove on this one, it simply didn’t happen, repeatedly. There was always going to be too much impact to the project, or sudden claims of a mere “personality conflict”, etc., and the company’s executive sponsor of the project didn’t jump in to ensure that the vendor acted. In other words, without a near court case about the matter, the vendor’s claim was empty. As an executive, make sure that you back your people up in these circumstances and insist on the removal of the consultant at issue.

5. We’re barely making any money here.
See #8. When these cries get louder as you push back on their fees, well, as the Bard says, the lady doth protest too much, methinks.

4. We’re in this for the long term, not just a quick gain.
See #10. This statement would imply a level of true vendor-side investment in the overall effort, investment that is rarely forthcoming. Ask for specifics that will demonstrate their commitment.

3. One of our key goals is to help you build your organization.
That implies that they don’t want to do the opposite: build in a profound dependency on them. Unfortunately, actual behavior (particularly on the part of big consulting firms and even some vendor professional services organizations) can often be the opposite. Not always, but often: after all, it’s human (management) behavior to attempt to lock in revenue for as long a time period as possible. Hence, any time you use external resources, you need to push hard to avoid long-term dependency, even when that’s painful in the short term.

2. We don’t want our people to work overtime. Really.
Think about it from the vendor management’s point of view: their employee costs tend to consist of fixed salaries, not people paid by the hour or even compensated for overtime. The full rate from any extra hours that their consultants bill to the client thus flows almost directly to the vendor’s profit line. Sure, from a people impact point of view, they have to be careful, otherwise their people will quit on them. But eagerness to get this kind of “pure gravy” revenue often trumps any people concerns.

1. We’re barely making any money here.
It starts to sound a bit desperate, doesn’t it?