I recently had the privilege of being interviewed, along with other experienced senior technology executives, by CIO magazine for my thoughts on communication mistakes still made by CIOs. Some great ideas came out in the article, but when it comes to communication (see tip #1 below), there’s always more to say. So here goes.

• Communication can always be worked on and improved. I was at one company where we did a semiannual employee satisfaction survey. Even better, the company was admirably dogged about implementing specific measures to address areas of dissatisfaction that emerged from the survey results. But in every single survey, the number one vote-getter was the need to improve intracompany communications, no matter what initiatives were spawned to improve them. Communication is an ongoing challenge and necessity.

• Don’t just communicate upwards. Communication with your team is every bit as vital as your communication to management and to peers. You need your team to have a clear and common understanding of the goals, as well as getting their active contribution and buy-in on the necessary approach to getting there. You can’t go it alone.
• Hierarchy is actually helpful; use it actively. Do your best to avoid providing explicit nuts-and-bolts-level direction to staff members other than your direct reports. Jumping in and telling people at all levels what to do confuses people mightily, undermines the authority of your direct reports, and increases the likelihood of mixed signals. And it’s just plain inefficient. Early in my career, I was a director responsible for a major week-long software rollout in one of my company’s regional offices. The project manager of the initiative was one of my direct reports. But then, the stakes were high enough that the CIO decided to fly down, and of course, the regional VP of IT was there as well. So for a week, we had four management-level people all sitting in every meeting, each trying to actively demonstrate they were in charge and look good to the others. Or, there’s out-and-out, from-the-top, intentional bypassing of the chain of command: Amazingly, I’ve seen cases of a CEO setting up a task force without involving or even informing the people who managed the members of the task force. Talk about undermining!
•  Be clear about what’s actually a directive and what’s just an exploration. Dawn Lepore, CEO of Drugstore.com, recently spoke in an interview about how she couches her direction to her staff as to whether it’s a “a light bulb or a gun”. “A light bulb means this is just an idea I had, so think about it, see if you think it’s a good one. Either follow up or don’t, but it’s just an idea. A gun is, I want you to do this.” Surprisingly, people often can’t tell the difference on their own. As a leader, you typically want most meetings, particularly at a senior level, to feature open brainstorming, a free exchange of out-of-the-box ideas, but that means it’s all the more important to carefully identify what emerges as actionable initiatives and what things continue to be simply thrown around as possibilities.
• Put it in writing. Supplement the directions you give in meetings and one-on-ones with a clear and succinct written summary. Doing this both clarifies and makes an unambiguous record of what you’ve asked for, and accurately communicates it more broadly than just to the people who happened to be in the meeting. It’s a way of demonstrating that you’re declaring yourself accountable. Doing so is vastly preferable to having your people run around claiming “The CIO wants this.” (And with some, once they discover that such a line grants them all sorts of vicarious power, they’ll tend to overuse it, and at inappropriate points). I’ve seen a lot of ineffective leaders follow some kind of old-school “just tell them” mentality, and they cause significant confusion in the ranks by failing to put things in writing. And it’s no wonder that with this approach, which evolves into a kind of “Telephone” game, they’re often disappointed in what they get.

Oral communication is often vague and ambiguous. Written communication is on the record. Strive to go on the record as much as possible.

• Be utterly clear about who owns the execution of the initiative, and who will be making specific lower-level related decisions. Most notably, avoid having people think that everything needs to be cleared with you at all junctures. For most initiatives, your role is to set the overall goal, not to shepherd day-to-day the specific process of getting there. Lack of clarity here is common, even when everything else is done right.

Common sense, all these tips, no? The thing about common sense, though, is that it’s often frightfully uncommon.

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.

How do we (IT executives) get away from being typecast as technologists, unconsulted on core business issues and approaches? Face it, that’s a common situation and dilemma that we all encounter, early and often, and it’s the grist for a constant mill of articles and blog posts and books on business/IT alignment.

Lately, though, a part of that mill has started insisting that focus on technology should be avoided altogether by what they usually cast as the “next generation” of CIO.  So I’m going to (again) be a bit of a contrarian here: it’s possible for the pendulum to swing too far in the wrong direction. I think that we can at times go overboard in our desire to avoid being seen as the geek with the pocket protector.  Examples: some preach outright denial that there might be such a perception problem: don’t even think of using the terms “IT” and “business”, they urge, and they recommend against ever discussing “alignment” as a goal.  Stop referring to the “business” as something separate, they recommend; IT is just as much part of the business as anything else! Similarly, their advice is “avoid discussing the technology itself.” As if a mere shift in language could solve the perception problem and automatically propel the CIO into the inner circle of decision-makers.

Here’s the gist of how I see it, though: in many (I daresay most) companies, the path of IT from high priesthood to strategic key playerdom has not really been fully traversed: in other words, greater alignment IS still needed of IT with “the business.”

In many companies, there’s still a trust problem. IT is arcane. IT can be as resented as a roadblock as the in-house corporate counsel types who veto certain kinds of corner-cutting.  Of course we’re “part of the business” (and increasingly so), but that doesn’t mean it’s wrong to continue to focus on breaking down the walls that linger.  The walls, in many/most places, are a reality, and it’s going to take steady, relentless, active work, not just a shift in language, to scale them. What especially will not help our effort to do that is if we embrace this odd trend of sneering at technology as a lesser-order concern—basically, positing that we should let someone else do that while we do the important (strategic) stuff.

In other words, I differ (vehemently) with those folks who now look down on such things as the need to align IT with the business, or who don’t recognize the benefits that come from regarding people as “internal customers”, or who recommend even avoiding using the terms “IT” and “business”. While the basic spirit behind those sentiments is of course valid—again, it’s undeniable that IT is part of the business, as much as any other department—it is in fact IT that has a problem in how it’s perceived by other elements of the company, going back to the high priesthood. Let’s be frank: IT folks have often been snooty, vague, cagey even, about what we do, why we do it, and how we’re meeting the company’s business needs as a whole. Deprecating the important progress and mentality shift that’s occurred in the last few years (that is, the high priesthood evolving to a service mentality) is exactly the wrong approach.

And somehow, inexplicably, the deprecators are getting louder, despite years of research and general agreement on the value of approaches such as IT governance, the ongoing need for IT/business alignment, etc.

Taken to an extreme, insisting loudly that IT is part of the business can extend to feeling that IT knows just as much about what’s good for certain business processes (say, manufacturing or shipping or collections or whatever) as the people executing those functions on a daily basis.  From there, it’s just a small but perilous step back into the old sort of IT arrogance, where systems were designed and deployed with little or no feedback from the actual users.  I exaggerate? Quite possibly, but I’ve seen it happen.

IT needs to both know its place and insist on its place, not one or the other. Here’s another example of a truly ham-fisted (even though well-intentioned) attempt to align IT more closely with business: I took over as CTO at a high-profile internet company, in the midst of deep, bet-the-company changes to its main product, a consumer-facing web site. I learned in my first few weeks that my predecessor had initiated a robot project.  His idea was apparently that he’d program this robot to walk the halls of the company, greeting people and thus making them feel more comfortable with technology. As Dave Barry is fond of saying, I am not making this up.  Needless to say, this project swiftly became a laughingstock across the company, representative of IT embracing technology for technology’s sake, completely OUT of alignment with business needs. Meanwhile, systems were crashing, projects delayed, etc.  This CTO somehow thought he was being strategic and business-oriented, but he actually was just being plain clueless, and more tech-focused than ever.

With IT’s background and history, the push towards IT/business alignment is ongoing and needs to be continual, rather than dismissed as something we’ve now evolved beyond. Even more, alignment mustn’t be deprecated as somehow beneath the higher goal of strategy. It’s not an either/or, and it most certainly doesn’t happen through mere declaration. And openly striving for alignment with our peers is nothing that anyone should present as a taboo or a sign of weakness. Additionally, at the same time that we serve as service providers to the company, we can and must be strategic in our outlook. This shouldn’t be either a surprise or controversial; in fact, excellence in tactical delivery is the ante that gets you to the strategic table.

It’s taken decades to get where we are—and I’d say (given, for example, the anecdote I cite above) that most of us are not really there yet anyway. Let’s not risk reinstating the “ivory tower” of strategy, devoid of the reality that comes from grappling with the actual pragmatics of implementation.

So, here are MY three tips on how to help convert your CEO’s understanding of where IT fits into the bigger picture. You’ll notice the emphasis of these points is quite different from the similar list in the piece I’m responding to here: in particular, my points stress a healthy balance between strategy and tactics, technology and business.

• Make sure there’s a rock-solid prioritization mechanism for all projects, where the priorities are clearly set, the tradeoffs carefully examined, and tough choices explicitly made and regularly revisited by the group of senior management, including the senior technology executive, who are jointly responsible for the business success of the company.  Focus on IT governance, Project Portfolio Management, etc.

• Speak up visibly and strongly to ensure that “roof projects” are given appropriate attention and priority. Build for the day after tomorrow rather than just for tomorrow. You in IT are a key advocate for this sort of basic corporate responsibility; you have and need to exercise your equal seat at the table.  And don’t let a misguidedly monomaniacal focus on strategy derail your obligation to keep the trains running on time. Nothing undermines the case for IT to be viewed as having a greater strategic role more than if the company is experiencing ongoing crises in basic delivery and systems.

• Be the straw that stirs the drink. IT, given a leader with appropriate vision and perspective, can and should be a natural cross-functional leader in the enterprise, both initiating business innovation AND espousing tactical responsibility.  They go hand in hand.

Let me end by quoting my colleague Steve Romero, who wrote, “Recognize that the “achievement” of alignment does not mean you’re done. This is where the “journey” analogy comes in. Think of IT-Business Alignment as “getting your head above water.” Once you reach the surface, you are not done. You need to keep treading water or you sink again. IT-Business Alignment is something that must be maintained as opposed to achieved.”

Lagniappe:

• Michael Krigsman, “IT failure? Blame your CEO.”  February 16, 2010
• Steve Romero, “IT-Business Alignment is Not a Meaningless Catchphrase“, October 28, 2009
• Michael Pattison, “Is IT – Business Alignment Meaningless?“, November 6, 2009
• Bob Evans, “Global CIO: Suicide Strategy For CIOs: Aligning IT With The Business“, October 13, 2009
• Fred Cummins, “Is Business-IT Alignment Suicide for the CIO?“, October 21, 2009
• Mary Nugent, “The Four Phases of IT/Business Alignment“, December 10, 2004
• Paul A. Strassman, “What is Alignment?  Alignment is The Delivery of the Required Results“, Cutter IT Journal, August 1998

What is it that sets apart a top-notch IT executive from others of his calling? To my mind, one mark of today’s true professional, especially at the senior executive level, is to be deeply familiar with the seminal books in his or her field. The dilemma for an IT professional, though, comes from the ongoing and increasing flood of books to choose from, and trying to figure out how to walk the fine line between focus on the intensely tactical and focus on higher-level concepts and ideas.

The tactical books do have their place on your shelf, actually, and it would be a mistake to ignore them simply because you’ve moved beyond daily application of your development, configuration, and technical trouble-shooting skills: judicious selection and absorbing of nuts-and-bolts techniques and new approaches will keep your insight into technology and its possibilities fresh.

I started in IT as a developer, and I remain fascinated by the endless possibilities and techniques of the world of software. In the last decade or two, though, I’ve become even more intrigued by a metalayer above the more tactical concerns. True to my ongoing insistence that the biggest challenges in IT aren’t purely technical, I am ever more convinced that the greatest difficulties are presented by “psychology of IT” issues: the human factors in how software and systems are conceived, built, tested, deployed, maintained, and eventually decommissioned.  Here are just a smattering of the eternal, non-technical questions that go far beyond the computer language du jour or the latest hot methodology:

• How do teams actually create and complete information technology projects? What works, what fails, and why?
• Why are some software developers ten times as productive as others?
• Why do some software teams gel and others don’t?
• Why do small companies with very few resources often beat out large, well-funded efforts in the marketplace?
• How technical should managers be?

So starting with this post, let’s embark on a multi-part survey of the groundbreaking, timeless books on such issues. I’m going to pick what I consider to be the top three books from each decade, starting with the 70s.  Each of them deserves not only a place on your bookshelf, but to be read and reread every few years. And contrary to what one might think, their insights remain not only valid after all these years, but have become all the stronger by having been confirmed by the history of the industry since their publication.

• Weinberg, The Psychology of Computer Programming (1971)

Weinberg opens with, “This book has only one major purpose—to trigger the beginning of a new field of study: computer programming as a human activity…. If our experiences are any indication, each [software developer] could be functioning more efficiently, if he and his manager can learn to look upon [him] as a human being, rather than as another one of the machines.”  This book was especially groundbreaking by addressing software development as both an individual and a team effort. Remarkably readable and full of anecdotal examples, it covers virtually every human aspect of the software development “sausage factory”: team formation, individual contributions, goal setting, leadership, estimating.  Weinberg’s “Silver Anniversary” edition of this book contains annotations and commentary for each chapter, reflecting on similarities and differences to today’s environments.

• Brooks, The Mythical Man-Month (1975)

I’ve said it before: if there’s one single book that every IT professional should read, it’s this one. Brooks’ foreword presents it as a “belated answer to Tom Watson’s probing questions as to why programming is hard to manage.”  Brooks’ writing brims with key universal concepts that can be unfortunately non-intuitive to people outside the field, but which ring familiar to any long-time IT practitioner. The titular essay introduces the concept of the “mythical man-month”, his adage that “adding manpower to a late software project makes it even later.” But there’s much more, such as “plan to throw one away”, where Brooks points out that the “first system built is barely usable; … there is no alternative but to start again.” I can’t say enough about this book. As with the Weinberg book, the anniversary edition now being sold includes Brooks’ later (1986), equally seminal essay, “No Silver Bullets” (see my post on this: “No Silver Bullets. Really!“), as well as some added chapters that revisit the assumptions of the first edition.

• Weizenbaum, Computer Power and Human Reason (1976)

Ultimately, this is a book about the limits of computers and software. Weizenbaum, a noted computer scientist in the early days of Artificial Intelligence research, wrote a program called ELIZA, featuring a script that “enabled it to parody the responses of a nondirective psychotherapist in an initial psychiatric interview.”  In other words, his test subjects would converse with a software program that emulated a therapist. Weizenbaum became horrified by how many people forgot that this was “just” a machine they were talking to, and that the dialog was really just an illusion. Many insisted, to his amazement and despite his explanations, that the computer actually understood them.

IT professionals today can be just as swept away, to a fault, with the potential ultimate power of software and systems as Weizenbaum describes.  I’m inspired and reinvigorated every time I read his sobering, methodical discussion of the nature of programming, the limits of its scope, and the need to consider the social implications of technical projects.

The next time, I’ll be on to the key books of the 80s. I’ve already picked the books I tentatively plan to write about, but I welcome your suggestions.

Lagniappe:

Here are a couple of books that didn’t quite fit in my theme and chosen time frame, but which are still worthy of mention:

• Thomas Kuhn, The Structure of Scientific Revolutions (1962)

Nobel Prize-winning physicist Steven Weinberg wrote that this book “has had a wider influence than any other book on the history of science.”  This book is not about information technology directly, but its influence has been monumental across all scientific disciplines, and it is a book that any technologist should know well.

• Ted Nelson, Computer Lib/Dream Machines (1974)

This was a self-published book in the early 70s, by influential industry visionary Ted Nelson, the man who coined the term “hypertext.” It’s probably different from just about any book you’ve ever read.

A few years back, I had an extremely surprising and unpleasant experience as CTO. The director of my Program Management Office ran a weekly status meeting for project stakeholders, where we’d all methodically go through the current project portfolio, in order to communicate on issues, gather necessary feedback, and align everyone’s expectations. I typically attended in order to provide input and executive-level decision participation, but left it to the director to actually run the meeting and present the topics.

Unfortunately, immediately before one of these weekly meetings, that director was given bad news (in a brief hallway conversation, no less) about a major bug that had just been discovered in the software for our highest profile project, which was currently in testing and due to launch in just a couple of weeks.  This project, with its strategic and revenue-enhancing potential, was foremost in the minds of everyone in the company.  Stakes were high, in other words.

Without conferring with me or anyone else, the director announced to the entire group of assembled stakeholders that the project had hit an insurmountable snag in terms of our target launch date, and that it would be delayed potentially by weeks. No further information was available on specifics, and people’s concerned questions went unanswered. You could feel the anxiety spread through the room. I actually had to truncate the meeting abruptly and promise to reassemble the group when we knew more.

My director was quite upset with me. Rather than having my action be understood as a necessary attempt to prevent panic until we could get some real facts, I suddenly realized that I was being accused of wanting to “hide information” from the stakeholders. The director even told me, “Well, I like to be honest and tell it like it is, but that obviously just isn’t what is wanted here.” I was stunned. Here was a person who had the wrong idea of transparency, and astonishingly for their position, a warped idea of what project management is all about.

As most experienced project managers know, it makes utterly no sense to drag stakeholders through the entrails of every back-and-forth readjustment that is discussed and worked through in the course of a project’s lifetime.  To do so lowers stakeholder confidence, unnecessarily in many instances.  In this case, the director somehow wanted to be a kind of Paul Revere, forewarning the stakeholders, but instead came off as Chicken Little. Transparency can’t be an act of individual heroism; it needs to be a concerted, institutionalized, collaborative philosophy and approach.

Moreover, good project management isn’t about making everything go smoothly. There’s probably no project plan in the history of the world that has gone completely smoothly from beginning to end.  Instead, project management is about responding appropriately when it doesn’t, and recalibrating to keep everything still on track. In fact, it should be expected that not everything will go as planned, and your whole team should be prepared to take some bumps and glitches in stride without panicking.

It’s not hiding anything to hold back on discussing, in a public forum, a problem that has just been discovered, the ripple effects of which initially can only be guessed at.  When you promulgate potential bad news prematurely, it puts you into the position of trotting out the absolute worst case, before you really have any idea whether that worst case is likely or even plausible. In fact, it’s a fundamentally selfish act: it takes your own personal panic and extends it to as many people as possible.  And if there’s one thing we know about panic, it’s that it’s contagious.

You need to shoot for judicious and organized transparency. That’s where you plan on regular status communications, and you methodically, soberly assemble the facts in a structured manner before you make those announcements. Most of all, you collaborate internally: before you bleat about a potential crisis to the stakeholders, you bring in the rest of your team to talk through the possibilities and “degrees of freedom” in how you’ll act with respect to that crisis. Otherwise, you may think you’re nobly playing Paul Revere, but instead of imparting critical facts, you’re shouting “The British might be coming!”  And that’s not transparency, that’s mere alarmism.  Remember that especially during the dog days of a stressful IT system development effort, what often seems like a dire setback, upon careful and collaborative examination in the light of day, turns out to be merely a minor speed bump that is easily overcome.

Is it “controlling the message” to be cautious about spreading the alarm? You bet it is. And doing that is in everyone’s interest. Remember my adage: show that you’re in control. Your job as project manager (and, by extension, the job of the Director of the PMO, and the CIO) is to be in control and to demonstrate to the users that you’re in control.  That doesn’t mean that you “hide” anything; it does mean that you deliver bad news broadly only when you’re sure of your ground, have weighed the options for how to cope with that bad news, and are ready to present those options soberly instead of in a flailing manner.

Adhering to a philosophy of transparency is a far cry from shouting every blip or misgiving about the project from the rafters. This is particularly so if you’re in a leadership position. You want your communication to be transparent, yes. But without appropriate structure and caution, transparency can be the height of irresponsibility. In those cases, in fact, you’re just building a slightly more institutionalized rumor mill.

Lagniappe:

• Karen Guglielmo, “What is transparency, and how is it relevant to IT?“
• Phil Windley,  “Tools for IT Transparency“
• Peter Kretzman, “Why the CIO should air the dirty laundry“

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

As I’ve written before (“Offshore development: target the destination, even if you never go there“), the reality of the CTO/CIO’s life is to be constantly challenged to produce more. Most technology executives, given that challenge, focus on squeezing out greater efficiency from existing processes, which is of course a necessary and constant push. What many don’t do is recognize the importance of crisp, formal handoffs of software from stage to stage, and how those can greatly enhance productivity.

Software engineering lessons over the past decades have taught us that software architectural techniques such as encapsulation, data hiding, and well-defined module interfaces are essential practices as systems scale ever larger. Equally, the human side of software delivery needs those sorts of crisp interfaces and neutral handoffs: loose coupling, in other words.  Loose coupling entails “minimal assumptions between the sending and receiving parties.”  And an increased focus on internal efficiencies (plus deadlines and pressure) can sometimes lead a shop away from that, and into tightly coupled handoffs, because those seem faster and easier.  You don’t have the time to do it right, so you end up using a lot of time doing it over.  My argument is that (just as it is with object-oriented architectures) it’s worth slightly less efficiency-in-the-small, if certain sacrifices in the hand-off arena can help you attain efficiency-in-the-large.

As I wrote in my previous post, referring to the constant business-driven pressure to “put eight pounds of manure into a five pound bag” when it comes to delivering technology projects,

The main insight here is that finding a viable way to outsource some projects is your ticket to expanding the bag.  I’m not even talking about offshoring here, simply about being able to take a chunk of your project load and hand it to an outside entity to get done.  If everything could be done that way, then you’d be constrained in your project load only by available money.  Sadly, in many shops, almost nothing can be done that way, due to too much interdependency of systems, too much background lore required, and no processes in place to allow for external entities delivering changes into current production environments.  My position here is that it’s a key part of your job to change that situation: to work actively on decoupling the interdependencies so that you at least have the option to leverage outside help more effectively.

Let me focus in this post on the important role that outside help can and should play in your development portfolio.  Specifically, I recommend that you find several (I suggest three to five) vendors who can take on well-defined development projects and deliver them relatively independently of your current core development staff.  Pay no attention to the natural sales technique that each vendor will use (e.g., “we want to be your sole provider”), because that’s principally in their interest, not yours.  Each vendor will have different skill sets, different availability, even slightly different approaches.  Not to mention pricing: when a provider knows that they won’t win every job, by definition, that keeps everyone on their toes in terms of both maximizing quality and minimizing the cost of delivery.

Here are a few key aspects to strive for when embarking on this sort of selective outsourcing:

• Make sure the vendor can and will work within the software delivery approaches that you’ve carefully established. You’ll find that a lot of independent vendors actually aren’t accustomed to the idea of formal handoffs and loose coupling.  Educate them, and move forward with the ones who get it.
• Work closely with your company’s legal department to understand clearly what data you can hand off to external entities, and what protection mechanisms need to be in place.
• Design (or redesign) all of your development processes so that it will be relatively painless to keep your vendors working with current builds, data, and necessary interfaces into your key systems.  Otherwise, you’ll face a nightmare of integration testing once they deliver.
• Don’t tolerate lack of collaboration (i.e., with other vendors, or with your internal staff, which happens more than you probably suspect) or information hiding. Everyone needs to be part of the team, with all behavior above-board.
• Make sure everyone (the vendors and your in-house staff) understands that delivery is defined as full delivery, not just “working code.”  That includes acceptance testing (user and operations both), knowledge transfer, agreed-upon documentation, test scripts, everything.
• Do recognize that functions “down the road” (QA, operations) will be impacted (resource and schedule-wise) almost as much by an outsourced project as by an in-sourced one. Nothing comes for free, and this is often forgotten.
• Make sure that your internal team understands the strategy here. You don’t want to have jealousies or insecurities pop up, simply because not all projects are being done internally.

Most of all, the key lesson I’ve learned from working with outside vendors has to be the notion of putting multiple arrows into the quiver: in other words, actively seeking out and using more than one vendor for the portfolio of outsourced projects. Not only does that make sense from a negotiation and pricing point of view, it pushes and tests everyone to make the hand-offs as well-defined (i.e., not individual-specific) as possible. And that benefits everyone.

Think about it: you can’t really tell the difference, on a day-to-day basis, between a car that has had its oil changed every 3,000 miles and one that has had its oil changed every year or two.  Only eventually.

Similarly, the stability of most IT departments proves very difficult to discern from outside.  Even insiders within IT can have myopia.  And non-technical senior management (CEO, COO, CFO)?  They usually can’t really tell either; they often don’t even know the right questions to ask, and their gut instincts on IT matters can actually run dizzyingly counter to best practices.  In short: to many or most people, it can look like things in IT are going pretty well, but in fact it’s all getting shakier and riskier every day.  Truth is, if a company is passionate about excellence, IT has to function well both on the surface and to the careful trained observer. IT is a service organization, and getting a few key things wrong means that the entire company suffers as a result.  Eventually.

My claim here sounds like an admittedly rather pessimistic one: that your IT department may be in much worse shape than appears to the eye. Yet, industry statistics indicate that’s probably the case. Having worked for and/or consulted to a lot of companies in the past decade, I’ve walked into a lot of “opportunities”, places where there was a lot of unchanged oil, so to speak. In fact, I’d be willing to bet that most companies have at least one, if not several, of the situations I’m going to describe in this post.

On the optimistic side, though, there are identifiable common root causes, all of which can be addressed, over time, by the appropriate focus and leadership.  As people always say, the first (and often hardest) step is simply recognizing that there is a problem. Let’s dive into the specifics, at a high level.

Here’s a reverse top-10, David Letterman-style, loosely ranked list of IT “anti-patterns“. I’ve actually seen companies where all of these situations existed. How many hold true where you work?  These gaps represent failures at meeting important best practices; like canaries in the coal mine, you should consider them to be potent indicators of looming instability in one or many of the dimensions where IT needs to serve the company.  Each of these deserves a separate post, or more, to treat fully; in some cases, I’ve already written posts on the item, so for those I provide a link below.

• 10. There’s no published record of system uptime and failures. IT departments that don’t monitor, measure, and publish their operational success rate probably aren’t doing all that well, and although people may suspect that’s the case, they have no facts-based way of truly knowing.  And what you don’t know will hurt you here.
• 9. Development doesn’t separate maintenance work from new development. Combining maintenance and new development in the same set of developers is a pretty guaranteed way of neglecting one or the other, often on an alternating basis.
• 8. Developers are performing production-level operational tasks on a regular basis. If you want to deliver new work consistently, you can’t afford to have your developers worrying about production tasks and issues. As with #9, one or the other, or both, will be neglected. Worst example of this? Having your developers push code live into production.
• 7. There’s no crisp handoff of new production code to the operations group, and no formal Operations Acceptance Test (OAT). Putting code into production needs to be a big deal, with metrics established, gates in place, and confirmation required prior to doing the deed itself.  As I’m fond of saying, the most destabilizing thing you can do to a software/hardware system is to change it.  You need a well-tuned system of checks and balances to avoid problems and instability.
• 6. Capital expenditures aren’t well planned or tracked, and often there’s a “last minute purchase order” frenzy. This is a CIO-level gap, often, compounded with CFO tolerance or lack of awareness. There should never be a situation where anyone needs to run to the CFO or CEO waving a purchase order, usually with no documentation or justification attached, insisting that it must be signed before close of business or systems will fail.  Nearly all expenditures, with few exceptions, should be in the context of a pre-established, signed-off plan.  Discipline (and accountability) in how IT spends money is a key hallmark of excellence.
• 5. The IT desktop/laptop inventory is murky, with no clear and published unit replacement plan.  What you don’t monitor, you can’t measure; what you don’t measure, you can’t control. Lack of discipline here not only costs money, it’s indicative of general lack of due diligence.
• 4. Development and test environments are all different, with no clear change control for new builds or tweaks. Without adherence to an airtight process for installing new code, software environments inevitably diverge, and at that point, chasing bugs can be quite frustrating.  A dogged drive to keep environments consistent with one another is a key benchmark of world-class development shops.
• 3. There’s no published list of projects underway, along with commitment dates: a public report card. If IT isn’t formally and publicly accountable for delivery, that’s the first step down the road to chronic slippages in schedule.
• 2. Projects are begun one-by-one. Estimates, if done at all, are unrelated to actual resource allocation. Without a project portfolio approach, projects fall prey to the “oh, that’s gonna take us three months” throw-off estimate which gets cemented into a commitment.  Without doing the math (figuring out competing projects and actual resource availability), you’re stacking up the dependencies and the likelihood of frequent failure to deliver.
• 1. The business doesn’t sit down regularly with IT to do a formal prioritization of major projects. Most critical of all: what gets worked on needs to be constantly examined and revisited, with the priorities set, the resource commitment understood, and the trade-offs recognized by business stakeholders.

You’ll notice that the most important (last) three items all deal with project management. That’s because strong project management, handled on a portfolio basis, is the most critical success factor facing an IT department, and the most common place where IT organizations are pressured to cut corners and “just get it done.”  Again, ensuring that you have that kind of project management will require focus, as well as active, informed leadership inside and outside IT.

This has been a scary post, perhaps.  You know what’s even scarier? This list could actually have been much longer than 10 items — these are just the most potentially damaging of the situations I’ve witnessed, but they are by no means the only canaries to look for.

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.

I noted last time, once again, that “IT is hard. In fact, it’s so hard that it seems most people have to learn certain core lessons by themselves.  It seems like everyone needs to burn his or her own hand on the hot stove.”  I went through some examples of this sort of “hot stove” lessons particular to management; this time, let’s talk about similar “hot stove” lessons/myths I’ve observed in other IT areas, most notably development and operations.

• Source code control and release management. One of the traits of a superlative programmer is his or her ability to maintain a complete logical model of the system/program in their head.  The really good ones are in fact really good at this.  Unfortunately, their consummate skill ironically leads to them sometimes resisting tools that help out with some of the logistical pitfalls that arise as system complexity increases.  Source code control is the most important such tool.  Programmers have even told me, “I can just keep track of what I’ve changed and what’s where.”  In a way, I suppose this is a species of the (typically male) trait of refusing to ask for directions—it’s a reluctance to embrace appropriate tools that are designed to avoid common screw-ups and to facilitate overall team success.  Suddenly, though, complexity mushrooms: releases overlap and patches are made in the heat of the moment, and without impeccable source code control and release management, bugs reappear, QA takes longer, and so on.  Typically, I’ve seen this “hot stove” lesson not really get learned by an organization until the source code control failure causes a notable customer-facing issue with a major release.

• Avoiding reporting against production.  Here, the going-in position of many developers is that “it’s fine to run reports against our production data; we’ll change it if it becomes a problem.”  This is another example of development activities incurring implicit technical debt.  What often happens, of course, is that certain ad hoc reports suddenly become regular and popular throughout the business, with business decisions resting on what they reveal.  New variations get created over time, and overall demand (and frequency of access) soars.  Then, unanticipated and unpleasant ripples occur, often without an obvious link to their cause: system performance problems, unpredictable timeouts, disk shortages, and so on.  When it reaches that point, it’s actually quite difficult to step back and re-architect seamlessly, without a hiccup.  In other words, by the time everyone becomes glaringly aware of the problem, you’ve painted yourself into a corner in terms of the ability to fix it quickly.
  

• Separation of development and operations. As companies grow from small numbers of employees to larger enterprises, it’s a common rite of passage for the organization to wrestle with the role of development in ongoing operations [See my post on Speed vs. bureaucracy: management issues confronted by companies in transition.]  Originally in such companies, of course, “everybody did everything,” and people are often proud of and wistful for those halcyon days.  Reducing people’s long-held access to systems is often seen as bureaucratic and authoritarian. But yet it’s necessary. The more you institute a healthy separation of duties and systems, the more likely you ensure clean handoffs from development into production, and the more likely you will avoid the sorts of production problems that ensue when developers make and apply “just one little quick fix” in the heat of the moment.  In truth, minimal developer intervention should ever be needed for production purposes. Developers should have no operational responsibilities and no regular access to production data.  I witnessed one mid-level startup once, where in a crisis moment, the CEO wanted to have a developer code a patch to our enterprise software product in the middle of the night and push it out that night to all other customers as well.  That kind of freewheeling approach and company simply can’t (and didn’t) succeed over time.  In that case, the “hot stove” resulted in the whole company and its investors getting burned.

• Full disclosure of problems and issues.  Maybe it’s human nature, but I’ve seen a common trend among IT staffers who haven’t learned this particular “hot stove” lesson.  It’s a general feeling that they should keep potentially damaging information quiet, and that “what people don’t know won’t hurt us”.  That philosophy shows up when they resist informing the company widely of system outages (often applying an IT kind of twist to the Five Second Rule).  Or when they are aware of but resist wider debate over critical bugs that they believe won’t actually be noticed by the customer.  Or when system performance problems in testing aren’t escalated, again in the belief that it’ll all turn out to be OK in production environments.  In my IT executive experience, there is no lesson more critical than the need for IT to create and actively encourage an atmosphere of full trust and open disclosure about system issues across the enterprise. All it takes to undermine that trust, and undermine it for a very long time, is one unfortunate instance of IT sweeping something under the rug and getting “caught” at it.  Then, a cycle often ensues: the reaction to the error itself is so strong and painful that IT folks are even more reluctant, the next time around, to disclose anything similar.  IT management can best help here by insisting on airing the dirty laundry, as I’ve discussed before.
  

Note here that the underlying theme of these “hot stove” lessons is that people resist learning them. Advice and counsel alone do not seem to hammer them home. IT management, if appropriately aware of these pitfalls, can (and should) insist on instituting mechanisms that will prevent the worst of their impacts, but be aware that doing so generally will be against some resistance, both up and down the management chain.  In essence, it may just be that people sometimes need to, well, get burned.