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.

And as for dialog? I’ve found, through painful experience, that the kinds of questions typically asked at conference sessions are most often designed to make the questioner himself look really smart. They’re often not even real questions, more lengthy expositions. We’ve all encountered that sinking “captive audience” feeling you get when you realize that such a questioner, a zealot of one flavor or another, has commandeered the audience microphone and is out there grinding his or her axe, and that someone is going to have to deal with it. Awkwardness pervades the session until a moderator or a fellow participant finally speaks up and shuts it down. That’s not dialog. That’s not networking. Even hallway conversations at such conferences can be filled with similar self-aggrandizing.

But this syndrome is actually deeper than something you just see at conferences. I would submit that it is unfortunately characteristic (admittedly in the extreme case) of what often plagues IT spokespeople in general, as they present before senior management or their board. We all want to be valued and highly regarded, and somehow, many of us decide that the best way to achieve that is to tout the bright side of our coins and leave any dark sides unmentioned or glossed over.

Let’s look at an example, in the form of a recent article about the fabulous success of Agile approach at eBay. Read the article; you won’t find a single wisp of a thought about any downsides, any blemishes, that occurred along the way. It was all golden, apparently. You see only references on how “to out-think and out-execute the competition”; or, “deliver useful information in days instead of months.” Can you say “silver bullet”?

Presenting any complex endeavor in nothing but glowing terms is to willfully forge an illusion, of course, not just at a conference or in an article, but at a board meeting as well. Somehow, the “case study” style of presentation tends to feature just that sort of dubious strutting, an implicit declaration that “everything went great.” Yet recognize that the people you’re presenting to are accustomed to piercing through that sort of bullpucky every day from vendors they deal with; you’ve lost your audience as soon as they figure out that you’re of similar ilk. It’s a similar deaf ear to the ones that teenagers turn when their parent tells them again and again about trudging ten miles through the snow to get to school, uphill, both ways. It’s a fish story.

The broader issue of how to present to one’s own management is something I’ve discussed elsewhere. But on the specific issue of finding a better solution to accomplish most of the goals that people hope to achieve by attending conferences? Local peer groups with regular meetings. Well-facilitated and attended peer groups, in my experience, can provide benefits that most conferences can’t or don’t: far greater continuity, candor, dialog, and, yes, screening. Most are participation by invitation only. And in such a setting, people stop having their principal goal being to impress others, and turn to looking to glean and impart useful information and tips above all. The best of the ones I’ve participated in adopt a tenet of “what’s said in the room stays in the room,” which greatly encourages candor and maximizes the true practical utility of the discussion.

Case studies and anecdotes are interesting, but my point is that conferences typically consist of lots of these, all golden, implausibly strung together back-to-back. And as I’m fond of saying, the plural of anecdote is not data. Many conference presentations are, at least in some sense, nothing but elaborate sales jobs. And if you really went to the conference for networking and learning, you want dialog, not sales.

Just a quick, personal post this time: I was recently interviewed by CIO Magazine on the topic of “How CIOs Can Stay Tech-Savvy“.  Since (as is normal) only a portion of my conversation with the reporter actually made it into the article, I thought I’d expand briefly on the topic here.

My remarks were two-fold, consistent with what I’ve written before on this all-important topic:

• It’s critical for the IT executive to “keep his or her hand in” by doing some hands-on work and experimentation with new technologies
• Your purpose in doing this hands-on work is not to become a viable technical resource in the area, but rather to get some deeper understanding than you’d obtain by just reading an article or two.

As mentioned in the article, I estimate that I spend 5-10 hours a month doing this kind of hands-on dabbling, sometimes with more success than others.  Let’s look at the kinds of things I do, large and small:

• Obviously, I administer my home network (four machines running three different operating systems, plus other home networking devices) and provide advice to neighbors and friends.
• I administer my blog, including configuration, changing WordPress templates, and even custom-coding PHP callbacks at times.
• I also actively seek out “early adopter” opportunities with new technologies, or technologies that are simply new to me.  I currently have four virtual machines that are launchable on my Mac: Ubuntu, Fedora 11, Windows 7, and Windows Vista.
• I have an ongoing Javascript dev project I work on that analyzes my iTunes music library and helps me identify gaps in metadata and lyrics, so that these can be corrected. That Javascript also dumps all the lyrics in my music library out into XML, to get them out of the proprietary world of iTunes.
• At the beginning of each year, I list out the technologies I’d like to delve into more deeply that year, in terms of reading and experimenting.  This list is based purely on what has intrigued me as I’ve scanned blogs, feeds, and Twitter. For 2009, my list included Amazon EC2 and S3, Ruby, Heroku, and CouchDB.  I’ve not gone as far as I’d hoped with a couple of these, but hey, 2010 will have a list too.
• In a given year, I might do some coding in Javascript, Perl, PHP, and Ruby. Admittedly, I usually need to look quite a bit of stuff up, but that’s mostly a factor of doing this only an hour or two a week.

As I emphasized in my remarks for the article, the point here is not to become a player on the field. I’ll never be as skilled in any of these technologies as the people I’d hope to hire with that expertise, should the need arise.  And that’s a good thing: the temptation is always there, particularly for someone who rose up through the developer ranks, to micromanage.  But at the senior executive level, it’s far more important that you stay focused on process improvement and strategy than on nuts-and-bolts techniques. Any of the experimenting I describe above should be viewed as self-education and a hobby, not a serious endeavor.

But you can bet that my self-education practice lends me a deeper insight into any of these technologies than if I’d sat back and simply read magazine articles on them. And oddly, I’m one of the few senior IT executives I know who still do this sort of thing. Granted, it will always feel to me like it’s too little, but not doing it at all is, well, not an option.

Are you among those who believe that if you don’t follow someone back on Twitter, you’re being snobby and arrogant?  Then this post is meant for you. My purpose here, quite candidly, is to persuade you that reflexively following someone back is not only a habit which encourages spam, but is in fact a major contributor to making Twitter a thriving spam platform.

For those who reflexively follow, in other words, I ask you to consider the ramifications of your behavior to the greater community, especially when multiplied by the thousands or millions of Twitterers who may behave likewise. Basically, you’re helping the spammers win.

First, let’s think about this: why does anyone follow anyone else on Twitter?  Three main reasons come to mind:

1. The follower believes that the person he’s following has interesting things to say, and wants to read those interesting things;
2. The follower is hoping that the person he’s following will follow him back, for one or more of the following reasons:

1. so that the follower’s count will increase
2. so that the follower’s messages will then have broader distribution/marketing power
3. so that the follower can send Direct Messages (DMs) to that person for even greater exposure and attention.

3. The follower is reciprocating being followed, out of politeness, sense of obligation, or idealism. Often, there’s a belief that following back will “strengthen the relationship.” You can “transform them into a fan with your valuable tweets“! Or so goes the claim.

I’m arguing here that the first of these behaviors is useful, the second describes spammers and marketers above all, and the third is a well-intended but unfortunate fulfillment of the spammer’s hope, one which encourages their continued activity.

Reciprocal following by rote in many cases does little to further a relationship.  Remember that they call Twitter “asymmetrical”.  Let’s use myself as an example.  I tweet about a fairly narrow range of topics, basically: IT management, cloud computing, and sometimes interesting or amusing industry or sociological matters.  I happen to have a broad list of other interests that I myself don’t typically tweet about but helps me pick whom I follow: literature, languages, music, politics, travel, theater, to name a few. I follow people solely for the first of my reasons listed above: because I want to read what they have to say. Again, it’s asymmetric: my reading interests are not the same as what I tweet about. Anyone who follows me simply because I followed them (i.e., behavior #3) may be taken aback by how uninteresting my tweets are to them.

Let’s look more closely at what happens when I’m followed by people who are unlikely to be interested in the content of my tweets.  If you watch closely, you’ll notice that you are often followed by entities (read: marketers and spammers) because of a keyword contained in something you’ve tweeted.

Just to give some examples: recently, I’ve been followed by:

• @HerbiesHeadshop, because I happened to use the phrase “down in the weeds” in a tweet;
• @BuilderPal, because I wrote and tweeted about what I call “roof projects” in the context of information technology;
• @proxyserver, because I happened to use the term “proxy server” in a tweet.

I’m not interested in any of the services these people provide, so I have no reason to follow them back. But more important: I’d argue that none of the above entities is remotely interested in my tweets. As a matter of fact, I am fairly certain that none of the above entities, or actually anyone who follows people as a result of keywords harvested from the Twitstream, is even reading my tweets, let alone anybody else’s. They just want to be followed back, so that I will then be more likely to read their tweets. They are using Twitter as a means to one end: marketing their services. Advertising. Exposure. Page views. And so they target (however clumsily) people they believe are interested in the products they provide. It’s kind of a new (and cheap) way of generating a targeted email address list.

Let me say it again: people who follow you using behavior #2 usually have NO interest in your tweets and in most cases aren’t reading anyone’s tweets at all. You are just a means to an end.  It’s not about you, it’s about them. If you’re laboring under the illusion that following someone who follows you is a way of strengthening the relationship, you should recognize that that strength is quite often going to be one-way only.

I could, of course, simply ignore any of these follows; most of them will eventually unfollow me anyway, not because of the content of my tweets (remember, they’re not even looking at these), but simply because I didn’t bite: I didn’t follow them back. I didn’t help them meet the sole objective they had in following me in the first place.

How do the spammers win? Spammers really only have an audience on Twitter if people follow them. More followers mean higher positions in search results for their pages and products. Most notably, following a spammer gives them the ability to Direct Message you, which increases the likelihood you’ll see and read their message and click on their links. And let’s be clear: the only reason people follow spammers is this strange perceived obligation that’s arisen on Twitter: follow everyone back who follows you; “it’s only polite,” after all, or it’s “snobby and arrogant” not to. When you succumb to that perceived obligation, the spammers win. If no one followed back, the spammers would go away.

It’s easy to turn behavior #3 (reflexive following) into behavior #1 (following because you’re interested in the person’s tweets): before you follow someone back, simply review the last 10 tweets the person has sent, which turn out to be astonishingly predictive of whether they’re a spammer.

You’re obviously welcome to use Twitter as you please and follow people for any or no reason. But consider the points I’ve made, in terms of the impact on the Twitter community of your actions.  And if you follow reflexively, don’t ever complain about getting spam DMs, because it’s your behavior that got you into that position.

Use Twitter for education, conversation, and interaction. It’s really the only thing it’s there for (other than providing rife subject matter for TechCrunch articles). Unless, of course, you’re a spammer.

Lagniappe:

1. Atherton Bartelby, “FOLLOW FAIL: The Top 10 Reasons I Will Not Follow You in Return on Twitter”

2. Skellie, “How to Follow Everyone Back on Twitter Without Ruining Your Experience”

3. Roger Hjulstrom, “Don’t let anyone tell you how to act on Twitter”

4. Twitter, “Turning Up The Heat On Spam”

5. “How spammers use Twitter”

6. Stop Twitter Spam blog

I don’t want this to be just another post about Twitter, the current hot trend of the Internet.  Rather, I’d like to relate this new Twitter fad to a long-planned important topic here.

Specifically, what can we in technology do to keep current and stay up-to-speed on our various areas of interest and expertise? There’s more out there than any of us can learn, and new technologies come along all the time.  Truly staying current, at a reasonable depth level, would be a more-than-full-time job.

Here’s how I’ve come to grips with that basic reality. These remarks are most relevant to the executive level, but to some extent they apply across the spectrum of roles in IT.

• If you don’t work at the nuts-and-bolts level with a given technology for 8 or 10 or 12 hours a day, you’re really just a dabbler anyway. Don’t delude yourself that you know a technology at the detailed level just because you have read a few articles or a book on it.
• Embrace that certain unavoidable level of dilettantism. Work on understanding what a technology can accomplish, how it relates to the bigger picture of architectures and business value, and how it differentiates itself from other players in that game.
• Recognize that the skill you really need most of all is “just in time” learning. I took a headhunter call a few months back from a company that was looking for a seasoned senior technology executive, but they were adamant that the person have coded and deployed Ruby on Rails applications for three or more years.  And sure, wouldn’t that be great: but there are high-quality executives out there who understand technology at a deeper, bigger-picture level, and can pick up the Ruby nuances in a matter of a few weeks.  And, judging from the other professed needs and gaps of that company, they should have been deemphasizing the specific technologies and searching much more for that big-picture guy or gal.
• As an executive, don’t worry about learning a technology at other than the conceptual level unless and until it becomes relevant to your business needs and goals. That said, you do need to stay current, at a conceptual level, with ever-shifting technologies.

So, there’s a lot out there, and it can be overwhelming. If you want to stay in the game at this level, you can’t just throw up your hands and not keep learning.  So how do you amass that concept-level understanding, then?  My pre-Twitter ways of drinking from the technology firehose involved spending a great deal of time doing the following:

• Subscribe to email newsletters.  Read, follow links.
• Find relevant web sites with content targeted to my interests. Read, follow links.
• Read white papers and technical journals
• Read blogs, follow links
• Use RSS to target my interest areas. Read, follow links.
• Experiment with various technologies (at a light level) on my own

I’m not stopping any of those activities, particularly the all-important last one.  However, I’ve come to realize that there aren’t any really good sherpas out there for this ongoing battle, no effective way of whittling down the massive input stream into just what I need.  So even though there’s nothing wrong with any or all of these above activities, the trouble was that the whole day can go by while I do that.  In other words, those approaches are just not sustainable for a busy executive.

Enter Twitter. Once you get past the common knee-jerk reaction (e.g., why do I care to hear what people had for breakfast?), and actually use it for a few weeks, you realize that it has some unexpected advantages:

• Probably 90% of Twitter users produce little more than drivel. But, you don’t need to follow any of those 90%.
• Messages, by virtue of the 140-character limit, are pithier, hence more scannable. Brevity is the soul of twit. (I can’t be the first person to say that).
• Topic areas are more findable, prunable, and groupable, leading to an incredible and still-growing abundance of Twitter utilities and after-market products to help people divide, search, conquer.
• Twitter, used properly, is much less subject to the incursion of advertising (or pure inanity) that plagues nearly everything else on the net: you can (and should) customize the people you follow for maximum utility. It’s so much easier to simply unfollow someone who turns out to be a spammer or a fool than it is to, say, unsubscribe from a typical email blast stream. It’s your action that does the unfollowing, not theirs.

“Mindcasting” is the term that I find most applicable to Twitter. Through Twitter, I get to tap into the minds of people I find useful, people who are willing to share, via this new medium, their perspective and interests. Those whose tweets prove interesting and useful, I keep following. Those who don’t, get dropped, and that’s OK. Via Twitter, I get to establish and hone the membership of my own private Algonquin Round Table, as it were, of fascinating interlocutors.  It’s more granular than relying on RSS, in my view, in that it’s more targeted and more bite-sized. I can trust the people I follow to give me quality links to read. I can see whom those people are following, and extend my circle to include those folks as well.  As a result of this daily honing and pruning, I get a much higher “signal to noise” ratio in my reading, thanks to my Twitter stream.  And lo and behold, very little of that stream ever relates to people’s breakfasts.

I’ll avoid going into detail about the frailty of Twitter’s offering, operationally (see links below about the infamous “fail whale“, other than to gently point out what should be obvious: that they need a different level of IT management if they are to continue to scale.

You’re all welcome to follow me, if you so choose, on Twitter here.

Lagniappe:
Useful articles on the Twitter phenomenon:

• “Twitter sucks, so change your friends,”
• “Forget the Fail Whale: Twitter Jumps the Shark“
• “On Twitter, mindcasting is the new lifecasting”
• “OMG! Shut up about Twitter already“
• “Brave New World of Digital Intimacy“
• “Twitter Explained In 267 Seconds“

Let’s sail into a stretch of a metaphor this time. You probably know by now how much I embrace metaphors as a way to impart, often via a concrete example, ideas and concepts that are hard to grasp. So let’s go way back and talk about a metaphorical influence from long ago.

When I was in early high school, we would occasionally spend English class watching and then discussing a variety of short subject films, many of them from the fertile minds at the National Film Board of Canada.  Some of these films, described by the NFB as “socially engaged documentary”, bordered on (or transcended) the bizarre; they thus spurred all sorts of avid arguments among teenagers, easily as much as Ethan Frome or Wang Lung, the more literary staples of the curriculum that I can remember from that year.  There was one such film in particular, in fact, that has stuck with me for decades.  After some digging, I’ve finally been able to identify it by name and origin.  The researchers at the NFB have now kindly confirmed for me that the film is titled “I.B.M.”, and that it was directed by Jacques Languirand. When I reflect on it, the film’s staying power with me makes sense, since it not only features IT elements, but also serves admirably and in multiple ways as a metaphor for IT issues.

As I recall the five-minute film, it features an unchanging close-up view of an automated keypunch machine, punching out a series of IBM computer punchcards with a mysterious and incomplete common message. The film shows the cards sliding into place and getting punched, one at a time, then rolling off into the output hopper. Only parts of the full message can be read at first, since some of the letters of each word are omitted or obscured. Little by little, though, over the course of the film’s duration, each successive card that is punched contains more and more of the message, until it becomes clear at the end of the film that the text reads, “Participate in the process rather than confront results.”

Three ways come to mind of relating this metaphor to IT, to its role across the enterprise, and even to effective IT management of staff. They share a common aspect: the duty (and the reward) of emphasizing participation over passive observation.

• The duty of stakeholders. Stakeholders need to be involved in any project, not look in from outside.  Note the recent and encouraging ascent in the industry of certain Agile practices that emphasize the ongoing and deep participation in a software project by its stakeholders, who provide constant input and feedback on micro as well as macro levels.  Contrast that approach with the more traditional, “over the transom”-style, one-time hand-off of supposed user requirements.  Stakeholders, take this to heart: jump in and insist on ongoing involvement in the projects you care about, otherwise the results that you eventually confront may not be entirely to your liking.
• The duty of IT. Equally, IT needs to work on an ongoing basis as part of the business, an equal partner at the table, and not just as IT in a vacuum, reacting to what it’s given.  At its worst, I’ve seen IT become little more than “order takers” for the enterprise — relegated to asking questions that are essentially equivalent to, “oh, do you want fries with that?” and obediently scribbling down the answers.  That approach of course seems cooperative and agreeable, but in truth, treating requirements gathering that way is actually a form of neglect of one’s responsibilities to the greater good of the enterprise.  Ironically, it often leads to long-term failure rather than success.  Don’t let this happen.  Instead, IT people need to be there at every juncture, going full throttle, to challenge and to help mold requirements towards greater viability and cost-effectiveness.  Few people in the enterprise are in as good a position as IT staffers to drive out the appropriate balance between long-term and short-term considerations.  User requirements often come in without context, or without practical weighing of consequences and ripple effects, or with a failure to consider plausible alternative approaches.  Molding and fleshing out those key requirements is a long arduous process; commit yourself to participate in it.
• The duty of leadership. Think about how you behave as an IT leader towards your employees.  Here too, do you participate in the process, or do you tend to just confront the results?  As an IT leader, it’s my obligation to resist falling into the rut of sitting back and mainly evaluating my staff on how well they’re executing.  Instead, I have to make sure that I stay actively and regularly involved in coaching, trend-setting, and occasional course correction, all (of course) without drifting into micromanagement either.  In other words, I need to focus on being a collaborator more than a critic, helping to further our collective agenda.  If I see something that isn’t working, for example, I can’t just ding my employee for the gap; instead, I need to work together with him or her to figure out the best way to regroup and move ahead.  We’re in this together, after all.  Not fully understanding or following through on this key duty, collaboration over critique, is in fact a frequent way that I’ve seen IT leaders fail.
  

But back to the film.  Of course, its main “gimmick” is that the message that it’s communicating isn’t clear at the beginning; it emerges into full clarity only upon successive efforts at articulating and perfecting it.  Who in IT can’t relate to that?  Think about how user requirements constantly evolve, for example, or management expectations, or even industry standards of success.  The message also reminds us of the benefits of “continuous improvement”.  Incremental and tiny improvements end up creating whole-scale shifts over time, and drive everyone to new levels of clarity and achievement.

Finally, thinking about this film helps me realize anew how far we’ve come with all those incremental technological improvements over the years.  After all, I don’t know anyone who works with punchcards anymore.

A few months back, I wrote a post on various “Astounding Sayings” that I’ve encountered in my career in information technology.  It turns out that it’s been one of the more popular posts I’ve written, judging from page views, so in true Hollywood fashion, it must be time for a sequel.  I am retitling it slightly, though, to distinguish it from the Peterisms I post from time to time.  The point of writing about the “astounding” sayings was that they usually reflect misguided energy (or, to put it bluntly: wrong-headed thinking); the point of the Peterisms, on the other hand, is to distill and communicate absolute, undeniable, sublime truth and wisdom at every possible turn. (Hopefully it’s unnecessary, but just in case, <insert smiley face here>.)  Hence, I’m now going to call these non-truthful, unwise sayings “astounding utterances” instead.

Here are two more such utterances, with moral-of-the-story observations for each.  Note: as before, these are true stories.  I may have changed some of the facts, lightly, to make them less identifiable.  They also always come from at least several years in the past, to provide a healthy amount of distance for everyone.

The utterances that I consider to be astounding, in their context, are highlighted for you below in bold.

• Looking out for #1, and, um, that would be ME.
  

Regular and formal goal-setting, to my mind, is one of the key managerial ways to focus and align everyone’s efforts in the business world.  Done well, it ensures that people are working on the right objectives, and are incented to achieve things for the common good of the business. The exercise often also brings to light any number of disconnects (teams working at cross-purposes, etc.) that would otherwise go undetected.

Usually, the way I’ve found this kind of goal-setting works most effectively is to actually collaborate with the employee on establishing meaningful goals for their role.  This isn’t exactly a jaw-dropping insight.  Workers themselves usually are quite expert in what needs to be done in their area; managers can help prioritize, push for improvements, and “ripple down” the larger goals of the company at that particular time.  So, the manager will typically draw up a list of suggested goals, ask the employee to do the same, and then they work together on aligning the two so that it all makes sense.  Goals should of course be “SMART”—Specific, Measurable, Attainable, Realistic, and Timely—but I won’t go into the specifics of that here; check out the links at the bottom for more information.

All of that’s pretty obvious, right?  Well, during one such goal-setting exercise a few years back, one of my managers came to me and reported that one of her employees had gotten upset at the draft suggestions the manager had drawn up for possible goals.  The employee didn’t like seeing specific targets for her work, such as measurable throughput, successful completion of projects, improvement of operating results.  Her response to seeing her manager’s suggestions was to snort, “Those aren’t my goals—those are the company’s goals!”

We can of course laugh at how obviously misguided this person was (just why she imagined that the company was paying her, if not to push for improvements and to help achieve certain company goals, I have no idea).  But I think the incident reveals an all-too-frequent attitude in the workforce, sometimes at all levels.  People who aren’t focused and actively driven to working on achieving meaningful overall company goals will simply hold everyone back. They’re in it for themselves, first and foremost.  If you find someone who doesn’t innately understand that having the company succeed will almost certainly tend to augment their own situation (salary, position, etc.), you need to work with that person quite seriously to see if you can bring them around.

• We wanna do what WE wanna do. Why are you asking these annoying questions?
  

You’ll note a theme, as usual, in this pairing of utterances.  For my second story, I’ll describe just a bit (tip-of-the-iceberg style) about a situation I walked into several years ago, where a development team had gone whole hog, tooth and nail, hook-line-sinker-and-the-whole-nine-yards, into Extreme Programming as their operative model.  Now, my purpose here is not to bash Agile or Extreme Programming, because there are actually quite a few positive aspects of those approaches, and discussing them fairly deserves at least a whole separate post. 

But when I started my CTO role at the company, I needed, as always in a new position, to ramp up quickly on current projects, deliverables, time frames.  And I could find nothing to go on.  Far from being Specific, Measurable, Attainable, etc. in their goals, this team had come to a style of work (and had been allowed to do so) where next to nothing was ever written down, and few goals were concrete other than (it seemed) just getting through the day.  In fact, I’d been hired precisely because top management was growing ever more concerned at how little was actually getting delivered.  I sat the project manager down and asked him how they hoped to know when they were really done, or whether what they were delivering would meet the business needs, or how they hoped to test what they had produced if they didn’t have definitions of what the specific goals were.  Where, in short, were the guiding definitions and documents that would serve as their touchstones during such projects?  He looked at me, arched his eyebrows, and proudly stated, “We’re parsimonious on documentation around here.”

Whatever one thinks about Agile and Extreme Programming (and let me reiterate that that is a complex topic that deserves a separate post), this was clearly a situation that had gone to a bad extreme, one where accountability and purpose had gradually drifted out of the picture.  There’s room for a lot of different and viable approaches in software, but almost completely eliminating accountability and direction isn’t an approach that I’ve seen bear a lot of fruit.

And there’s nothing astounding about that.

Lagniappe:

• http://en.wikipedia.org/wiki/SMART_(project_management)
• http://www.goal-setting-guide.com/smart-goals.html
• http://www.topachievement.com/smart.html

I haven’t given myself the luxury of telling an IT anecdote or two here recently, so it’s about time: here are two, with moral-of-the-story observations for each.  Note: these are true stories.  I may have changed some of the facts, lightly, to make them less identifiable.  They’re also always at least several years in the past, to provide a healthy amount of distance for everyone.

I’d actually like to make this post the first in a recurring motif, a series that I’ll call “Astounding IT Sayings,” for what I hope are obvious reasons.  The saying that I consider to be astounding, in its context, will be highlighted for you below in bold.

• This one goes to 11

There I sat, interviewing for a CTO position.  Of course, these sorts of interviews always go both ways, and I was at least as interested in hearing about the state of the company, its products, its technologies, as they were in seeing whether I’d be a good fit for what they needed.  Without a doubt, the company in question looked solid, and was clearly on the move in their market.  As I talked to various executives and also a number of IT staffers, I heard just a few doubts being expressed about a current major project, but otherwise, everyone I talked to was amazingly upbeat about the technology, the capabilities of the staff, their ability to work together with the business, and the robustness of their processes.

Then came the kicker.  As I spoke to the Director of Technical Operations, I asked him about the company’s software launch processes and how solid they were.  Having been burned any number of times by weaknesses in this area, I was especially interested in hearing how they promoted software from development into test into staging and then finally into production, both for maintenance fixes and for major releases.  I asked, “on a scale of 1 to 10, where 1 is complete chaos and 10 is perfection, where do you think this company is, in terms of the solidity of its release processes?”  Without missing a beat, he confidently answered, “Oh, we’re at an 11.“

I didn’t really need to ask a lot of follow-up questions, since doing so would have inserted a pointless element of contention into the interview: the “11″ had already revealed to me what I would find out. It’s been my observation that nearly all companies have weaknesses in their release processes: e.g., bug fixes break other things; major releases cause old bugs to resurface; rollbacks aren’t well thought-out or fail entirely, and so on.  I’ve actually never seen a company that was even at what I’d consider an 8 on that hypothetical scale of 1 to 10.  More than anything, though, I was looking for an attitude of continuous improvement as the underlying philosophy, and “we’re at an 11″ was the exact opposite of that.

• There is nothing either good or bad, but voting makes it so

It was a bet-the-company project, one that had to succeed: implement a portal web site that would supplant and ultimately replace all the company’s current e-commerce sites with a more sophisticated, more capable, more comprehensive integrated offering.  We’d been working away on it (all new architecture, new approach, groundbreaking innovation in terms of presentation and business process change) for many months, and the launch date loomed before us.  We weren’t ready, and everyone knew it at heart.  Too many glitches, too many unresolved issues, too few successes in our test environments.  Crisis moment.

A new key executive had just ridden into town, was only a few weeks into the job, and he called a meeting of all the project’s principals.  He kicked off the meeting with this announcement: “I’d like to hear a vote on whether we’re ready to launch.” My jaw dropped. No discussion or even mention of metrics, intermediate milestones, or readiness criteria. Instead, a verbal vote.  On a scale of 1 to 10, with 1 being completely unready.

What ensued was actually what one would tend to expect of a group of middle managers in front of the new and powerful key executive, with no one wanting to come across as negative.  “Oh, I think we’re at a 7,” the first person opined. “I’d say an 8,” piped up his neighbor.  We went around the table, with nearly all the votes falling in the range of 6 to 9.  I was among the last to speak: “We’re at a 1 in my view, completely unready, and here’s why,” I said to a chorus of gasps.  I explained that we actually shouldn’t be voting but should instead be nailing down facts-based criteria on which we’d base our launch decision.  I pointed out that we’d gotten precisely zero transactions successfully through the system end-to-end.

OK, said Mr. Key Exec.  Looks like maybe we’re not ready. Everyone is going to work the weekend.  (This meeting was on a Friday).  We’ll meet again on Monday and reexamine where we are.

And that we did.  Lots of hard work, lots of late night pizza and diet Coke.  We gathered together in the same room around noon on Monday.  To my amazement, this is what I heard: “OK, let’s see where we are.  Why don’t we go around the table again and everyone give me your impression of our launch readiness on a scale of 1 to 10?”  And that’s what we did.  “Oh, I’m up to a 9 now. We really made progress this weekend.” “I’m at an 8, but I was at a 6 on Friday.”  And round and round.  When it came to me, I again quietly restated my “1″, pointing out that despite hard work and progress, we had yet to see a single successful transaction.  I said that judging from experience and based on where we were at this point, my prediction was that we wouldn’t really be ready to launch for another three months.

The website launched about three months later.

The key takeaway should be obvious: no matter what the pressures, don’t ever base a major operations decision on a vote, where such voting would serve to substitute for a sober evaluation of facts-based criteria.  Launch readiness is way too important to leave up to pure gut instinct and mass optimism.  Create your metrics and your criteria up front, collect them, and look at what they tell you.  Then act accordingly.  That way, you’ll end up with results, rather than astounding sayings.

Another heads-up to readers: I was recently interviewed by eWeek for my thoughts on the difference between mid-market CIOs and enterprise CIOs.  As these things sometimes go, the interview turned into more of a discussion of career path and how you climb to executive ranks in IT.  I’ve written about this topic before, but if you want to read some more on this, with a little more detail about my own path, do check out the article here; it appeared this week.  The interview also gave me yet another opportunity to make my now-familiar points about some pet subjects, such as IT needing to be a service organization, the importance of being a partner to the business, and so on.

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?

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.

• Don’t let best get in the way of better.

The person I heard this aphorism from originally almost certainly didn’t invent it, but nonetheless, I can never read or say these words without hearing the soft Mississippi drawl of Jim Barksdale.

Engineering anything (software, hardware, bridges, machines) is all about meaningful and careful compromise. For a number of solid practical reasons (time and expense being chief among them), no one in any branch of engineering gets to pull out all the stops and insist on the ideal in all aspects of constructing a product — indeed, I’d argue that much of the thrill of good engineering actually consists of working within limits and achieving maximum effect despite the barriers. Nonetheless, I’ve frequently seen IT professionals fall into the trap of trying to maximize all things, reduce all risk of failure, allow for all contingencies: and that way lies almost certain failure.

Equally, business stakeholders can err on the side of insisting on the ideal. Sometimes it’s because they figure that if they don’t ask for everything up front, they’ll never get it. Other times, it’s feeling that there’s absolutely no utility to a partial implementation of what they want. That stance, too, is self-defeating: it leads to “big bang”-like projects being spawned and undertaken (with a high rate of failure), rather than working iteratively through successive versions and feature releases to get what is needed. For particularly glaring examples of stakeholders feeling that only absolute perfection is worthwhile, take a look at the bulk of the messages left on Apple message board sites after any product release, no matter how stunning that release was. Fault-finding, carping, general dissatisfaction abound — and this is from the fan base!  Another way I’ve heard this aphorism expressed is that “the perfect is the enemy of the good.”

• The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. (George Bernard Shaw)

Aside from the now-dated gender specificity of the above quote, it’s a gem. Being too reasonable and adaptive can lead to complacency and failure to push the envelope. Too much unreasonableness, however, and you’re not going to be successful — your expectations (like the above-mentioned Apple fans) will be so high that you’ll push all chances for success out the window. Note the contradiction of this saying with the previous one, however.

• Don’t make pie crust promises (easily made, easily broken). (Mary Poppins)

A classic way that IT often shoots itself in the foot is to overpromise, usually in response to fervent desires, needs, and hopes (or perhaps a little of Shaw’s “unreasonable man” behavior) on the part of stakeholders. Here’s one that I see time and again: “OK, we’ll get that feature into the very next release, just a week after launch,” usually offered up as a negotiating concession with stakeholders when there’s a late-breaking requirement or the need to descope things to hit a launch deadline. Of course, at that point the “very next release” hasn’t truly been planned yet, and there are probably dozens of features and fixes vying for inclusion, none of which have been soberly prioritized against one another by stakeholders. To promise anyone anything specific on feature inclusion, much less to state a specific short-term time frame, is almost a guaranteed way of disappointing people. There’s no substitute for planning, even amidst the kind of heated discussion that usually happens late in a project.

So, there’s a common theme to these (i.e., they all pertain to the negotiations process on projects), but there’s no single common “answer” that they collectively provide, other than to underscore that it’s important to look at things from both IT and shareholder perspectives: be unreasonable in pushing for progress, yet don’t let a desire for perfection get in the way of generally improving things; and for heaven’s sake, make sure you don’t overpromise. It’s a mixed world out there, and that will never change.