CIO pet peeves: small drains on personal productivity

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?

“Channeling”: a technique for preparing IT presentations to management

The Skeptic’s Dictionary tells us about a concept called channeling: “Channeling is a process whereby an individual (the “channeler”) claims to have been invaded by a spirit entity which speaks through the channeler. ”

Lest anyone misunderstand, I’m not recommending that anyone get invaded by a spirit entity. But I am recommending that you learn to channel, and that you become a champion of that technique to your IT staff. Here’s what I mean.

The key problem I see in a lot of IT-to-business communication is when IT people fail to consistently anticipate and proactively answer the obvious and reasonable questions that stakeholders will have, particularly senior management stakeholders, including board members. Those questions are simple and almost always essentially the same, as I’ve mentioned before. On any given proposal, stakeholders want to understand these basics:

[Read more…]

More Peterisms: lessons learned on IT practices

More pithy sayings that (at least in my view) I reuse in an attempt to succinctly express key concepts and lessons. Or, perhaps in many cases, to annoy my staff via tireless repetition. I have several dozen of these sayings, most likely (I haven’t actually counted), and for many of them I can no longer remember their origin. The ones this time around, though, are attributable. You are free to draw conclusions or insights about my cultural values from the breadth of sources represented here. Aside from the theme of wildly disparate cultural derivation, though, these apothegms have another common thread to them: they tend to come to mind as you go through the standard back-and-forth negotiations with business stakeholders about features, projects, workload.

[Read more…]

The flip side of common myths: how some are perpetuated by IT

As promised, I’m going to follow up on my last post (Optimism, resilience, stamina: the make-up of the CTO/CIO), covering the myths IT deals with on a regular basis, by talking about its flip side: the ways that IT itself can unfortunately perpetuate or contribute to some of the myths I’ve been discussing.

Here’s a point-by-point discussion of some of the things I talked about last time, the discouraging statements you frequently hear from stakeholders.

[Read more…]

Why the CIO should air the dirty laundry

Trust. It’s important. And a company typically instills a huge amount of trust in its IT department, particularly (as is often the case today) if that IT department is responsible for the operation of systems (such as web sites) that contribute significantly to the bottom line.

I’ve been at the helm of several IT departments that operated the product of the company: social networking or other web sites. And that’s when I learned how vital it is to “air the dirty laundry” internally throughout the company about the stability of the key systems. Too often, I have seen IT staffs that were reluctant to announce that the system was down, in the hopes that it wouldn’t be such a big deal if they could only get it fixed quickly. Of course, often a quick fix wasn’t in the cards, and users started to a) notice the outage; and b) wonder if anyone in IT was even aware of it.

My response to this is to insist on the airing of dirty laundry. Less euphemistically: timely, comprehensive, broad-audience notification of all system outages and impairments. Specifically, emphasize the following:

[Read more…]

End-of-year Peterisms for the CTO/CIO

One habit I’ve picked up as a CTO/CIO, a habit that usually comes out in the many meetings that make up my work week, is that of leading through aphorism. Over the years, I’ve accumulated a number of pithy sayings that, like the proverbial picture being worth a thousand words, succinctly express key concepts and lessons that I’ve learned throughout my career. And I pass those on, sometimes repeatedly. My staff in more than a few of my jobs have started to call these sayings “Peterisms”, although I certainly can’t claim that I’ve invented most of them. So for a light-hearted end-of-year blog entry, in what may become a recurring flavor of post, here’s a few of them, with some discussion about what they connote in my personal Darmok-like management code.

[Read more…]

DWYSYWD: IT and the value of declaring victory

I saw a license plate recently that read DWYSYWD. I puzzled over it for a while (Google wasn’t handy), and then it suddenly flashed on me: Do What You Say You Will Do. I’ve since learned that this is a well-known phrase, used by people such as Colin Powell, among others.

How does this relate to IT and the CTO/CIO? Well, all sermonizing aside about how “Do What You Say You Will Do” is a great mantra in general for life, it particularly fits the rapidly swirling technical project world that the CTO/CIO copes with every day. In that world, as we all know, it’s easy to say that you’ll do things, and you’ll certainly be pressured to say you’ll do more and more. Actually getting them done, however, is a bit harder.

How important is it to Do What You Say You Will Do? I went into a CTO role once where I rapidly observed that I had inherited a team that wasn’t doing. In fact, the team wasn’t saying, either. Astonishing as it may seem, they had been allowed by company management to fall into the pattern of making no commitments for delivery, in anything other than the vaguest of possible terms, most of which had to do with stating noble intentions of working hard. In other words, they weren’t really putting themselves on the line. A major part of my approach there was to emphasize the importance of making, and then meeting, specific commitments for delivery. “Commit, Deliver, Track & Communicate” became the simply-stated, three-pronged “get well plan” in that situation. Easily stated, not so easy to achieve; but that’s a story for a different posting someday.

My major point here, though, and an important part of project delivery (doing what you say you will do) that occasionally gets lost, is declaring victory when the project is successfully launched. This declaration should be a relatively formal, executive-penned announcement of the launch, usually delivered via a broadly disseminated e-mail.

Insisting on declaring victory has a number of important purposes:
[Read more…]

Einstein and the care and feeding of upper management

One area where I feel I’ve learned and grown in my career is achieving a much clearer understanding on how to communicate with upper management. Most advice along these lines tends towards simply warning against overuse of technobabble, and I can’t disagree with that. But there’s a lot more to successful communication than simply that, and I’d like to describe here a few ways to avoid the pitfalls that I’ve seen IT people (including myself) fall into in these situations. None of these ideas is especially new or difficult, but they don’t always seem to come intuitively to IT folks.

When presenting a problem and/or proposal to upper management, keep in mind the following:

[Read more…]

Mastodon