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.

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

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“

Roger Sessions recently published a white paper on IT complexity and its role in IT project failure: “The IT Complexity Crisis: Danger and Opportunity”.  It’s certainly possible to quarrel with bits and pieces of his analysis, and thereby tweak his numbers, but the overall thrust remains undeniable: IT failures are costing the world incredible amounts of real money. Sessions even sums it up under the dire-sounding phrase, “the coming meltdown of IT,” and says, “the out-of-control proliferation of IT failure is a future reality from which no country—or enterprise—is immune.” And he presents “compelling evidence that the proliferation of IT failures is caused by increasing IT complexity.”  He points out that the dollar cost of IT failure in the US alone is close to the cost of the recent US financial meltdown, and cites indications that the rate of failure is also increasing by 15% per year.

Roger’s paper is excellent and thought-provoking, and I recommend it highly. And I do agree with his view that complexity is the chief culprit in IT failure. That said, I think his argument focuses a little too strongly on one cause of complexity (unnecessary overcomplexity of architecture), to the neglect of other important factors.

To be sure, some obvious contributors to IT failure (poor project management, and lack of communication within teams and from business to IT implementers) aren’t dismissed by Sessions, but he sees their contribution to the crisis as relatively small. I don’t, and I’ve used this blog to write about those factors quite a bit.

Most of all, though, I differ with Roger’s focus on streamlining architecture as being the key to reducing system complexity. One could say, in fact, that Roger’s solution is primarily a technical one, where the bugaboos I see are primarily cultural and sociological.  I see not one, but at least three distinct complexity-related burdens, increasingly endemic, and increasingly bringing down IT:

• Overly complex design/architecture
• Taking on too much functionality
• Poor implementation (technical debt in-the-large and in-the-small)

Roger has admirably dealt with the issue of overly complex design/architecture, at least in terms of a viable approach for simplifying up-front architecture, so I’ll focus here on the other two.

Taking on too much functionality

I recently rented an economy car (the least expensive option) on a trip with my son. (Remember, my self-appellation is “Cheap Technology Officer.”) He was stunned and dismayed that the car didn’t have automatic door locks; he didn’t realize that they even made cars without them anymore. Similarly, my 11-year-old daughter has grown up in a TiVo-ized world where live TV can always be paused. When she encounters a TV without a DVR (and thus no pause capability), she regards it as hopelessly primitive. Indeed, as unacceptable.

Similarly, the general standard for functionality and UI design has been raised by extremely functional PC software.  I now expect to be able to double-click on a number in any onscreen report, and thus “drill down” into the transactional details that make up that number. When I can’t, I feel cheated. Equally, I expect everything on an interface to drag and drop; I get frustrated if it doesn’t.

So as an industry, we’ve raised the bar of acceptability, considerably, in software and technology systems over the last couple of decades.  What that means in practical terms, though, is that across the board, our eyes have gotten bigger than our stomachs. We want more, up front, than it often makes sense to build at the start. And our demands are not negotiable, or so it seems. The first few cell phones I had didn’t even have a ring silencer on them; I used to silence the phone by adroitly disconnecting the battery when a call came through at an inopportune time. Today, most people wouldn’t even consider buying a phone that lacks much more elaborate features, such as a camera, that I would have considered as space-age in nature back in the 80s.

So our increase in expectations, alone, has added considerably to the functionality of systems we tend to build. There’s more functionality in and of itself, and usually more interface points to other complex systems. In fact, integration testing—where you connect new code into a working environment where it has to interface correctly with other systems—has become a frequent and major sticking point in launching information technology projects.  In essence, we’ve fallen into the “nuts” dilemma, both in large and small ways.  We want so much, and attempt so much, that we increase our risk of failure considerably.

Technical debt (in the large and in the small)

Any software developer will tell you that their first stab at implementing a given piece of functionality is often (if not usually) much more complex than turns out to be needed. Only after exploring the problem domain, with experiments and backtracking and restarts, do developers usually realize that their code can be pared down, simplified, combined with other modules, etc. This is usually called “refactoring”, and its importance is a relatively recent insight in the software development discipline.

A key insight about refactoring, though, is that it means improving the code without changing its overall results. There’s often no immediately obvious payback to this undertaking: it’s a roof project, in essence. To the extent that refactoring isn’t done (no time, no inclination, no recognition of a simpler approach), the end product is left with vestiges of unnecessary complexity. The greater the time crunch, and the greater the aspiration for the functional depth and breadth of the software to begin with, the more likely it is that these vestiges linger. And one ancillary aspect of the raised bar in expected minimum functionality is that it causes the time crunch to get ever greater.  It’s no longer about delivering just a solution that will work, it’s about making sure that the solution includes (metaphorically speaking) a 5-megapixel camera too.

Couple this unnecessary but accidental complexity with what often amounts to a rush job on design for the sake of meeting schedule (creating “technical debt in-the-large”). An example I’ve used here before: choosing a different core DBMS to implement a given function, simply out of expedience, and failing to take time to modify previous functionality to use that new DBMS. Supporting two DBMSes within the same product represents significant technical debt: every subsequent system change and addition will entail “paying interest” on that debt, which not only increases schedule and manpower costs, but increases risk of failure as well. And that’s just one example; the technical debt cascades, feature upon feature, release upon release. Technical debt, until paid down, can be equated to a invisibly rising substrate of complexity, and it contributes massively to an increasingly wobbly, risky system. And lately, I see more and more organizations “pyramiding” their technical debt, never taking the time and cost to pay it down, with disastrous results. As Hemingway said about going broke, it happens slowly, then all at once.

What now?

Roger’s analysis, to its large credit, outlined an important aspect of complexity and posed a solution (an approach he calls SIP, or Simple Iterative Partitions).  The aspects that I’m presenting (taking on too much functionality, and the pyramiding of technical debt) are, as I’ve said, cultural and sociological within companies. The answer is not nearly as simple or as neat as a specific technical solution (although I am certain that I will get comments on this post, perhaps rightly, from devotees of Agile).

To my mind, it’s engaged, savvy, forceful leadership that alone can address these issues, slow down the demand train, stop the madness. If anything, I think that there is an increasing lack of leadership in IT circles that can suitably recognize and address these factors, as well as educate their peers. And that’s what needs fixing most of all.

Lagniappe:

• Kevin Schlabach, “Agile East 2009 by Thoughtworks”
• Martin Fowler, “Technical Debt“
• Eric Ries, “Embrace technical debt”
• Johan Lindberg, “Painting With Hands and Feet: The IT Complexity Crisis”

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“

I was at a relatively young company once where a senior executive suddenly sent out a message to the entire employee base, asking for general input on the  cause and treatment of the following concerns:

• “There is a feeling that the company is not able to move fast enough or nimbly enough — we’re not delivering products fast enough or turning projects around fast enough
• “People feel that it’s very difficult to get things done
• “There is a feeling that we’re getting too bureaucratic in everything
• “People aren’t working collaboratively; there appears to be a ‘contract’ mentality in dealing with people”

Aside from the unfortunately vague, passive-voice constructions in this message (“there is a feeling”: meaning one person? everyone? just senior management?), this message didn’t surprise me much.  In fact, it wasn’t (at all) the first time I’d seen this kind of sentiment arise in a young company. 

Here’s what I know: when a company is first formed and starts to get traction, everyone does everything. There’s a high sense of frenzy and focus and commitment, corners get cut but everything really important still gets done, and so on.  It’s a heady and exhilarating time.  Then, as the company matures, perhaps broadens its product line, expands its customer base, ramps up on employees, and tightens down some previous loosey-goosey processes, a degree of wistfulness and concern settles in, particularly among the old guard.  “We’re not customer-responsive enough anymore!” goes out the cry.

But in truth, it’s now a much more complex world than it used to be, with necessarily more constraints and rules, and well, some people chafe at constraints and rules quite a bit.  Hence this post, since many of the concerns about speed and potential bureaucracy tend to be directed at things that relate to information technology.

The chafing at new rules and increased structure comes from a range of people across the enterprise, people such as the following:

• developers, who are irritated that they have to check code in and out as they work, instead of managing it themselves the way they used to (when everything went just fine, thank you very much);
  
• sales/marketing people, who cut deals for customers that it turns out can no longer be implemented within the promised time frame, because the company’s world of interrelated systems has grown more complex with much more to juggle than there was “in the old days”;
• IT infrastructure people, who are being required to actually write down an implementation plan before beginning to execute it;
• customer support people, who discover that it’s no longer an acceptable process to just “call up Bob in IT” and put him to work on the perceived crisis of the moment;
• product managers, who can’t fathom why it’s now no longer acceptable to insist that a developer code and release a patch into production in the middle of the night to assuage an angry customer;
  
• users, who are being told they can’t use their own laptops on the company network or bring in their own printer from home if they feel like it;
• employees, who are suddenly being required to carry and display a badge at work.

And on and on and on.

Implementing new processes such as the ones cited above is of course a quite normal and expected (indeed, arguably unavoidable) rite of passage for a growing company.  Yet, the change management associated with them looms large, and the need for change management simply must be recognized and championed at the most senior levels of the company.  In young companies, though, it’s unfortunately the senior management themselves (particularly the ones who were around in the early days) who often appear most consternated by these shifts.  And that doesn’t help the rest of the employees grow or adapt.  As an analogy, it’d be like a parent not understanding it as expected and normal when their son’s voice changes, or when their daughter begins to menstruate. Think of the impact on the poor teenager in that situation, watching his or her parent freak out on them.

Distressed calls for input about how to stop the encroaching bureaucracy, even though well-meant, deliver a very mixed message.  Almost always at these juncture points, there are actually a lot of middle management forces within a company that are correctly pushing for what’s really needed now: focus, prioritization, measurement, scalability, and long-term benefit, rather than merely short-term “success”. Then along comes a message like this, indicating that oh, we’re not being responsive enough as a company.  Employees’ heads start to spin around in confusion, and morale can suffer.

Consider the following:

• These juncture points at young companies typically revolve around the need for greater scalability: more customers, more volume, etc.  Competitive pressures now aren’t just about getting new products rolled out in an agile and fast-paced way; they’re also (or more) about successfully delivering more of the existing products, and to a broader base. The company usually started its existence by focusing on product definition and delivery; scalability concerns come late to the party and are less understood and usually underprioritized.
• Structure is not bureaucracy. Early-stage companies often equate cowboyhood with success and reward.  Individual, bold initiative carries the day early on, and rightly so.  But, people who are used to being cowboys will tend to complain about fences, any fences.  Cowboys usually don’t want to hear about why good fences make good neighbors.
  

• It’s speed, not lack of speed, that’s actually the problem. Usually, it’s not that a company at this juncture is moving too slowly, but really the opposite: as projects proliferate and accelerate against the landscape of a broadening business, a greater degree of “haste makes waste” often sets in: poor planning (or non-existent planning) contributes to scrambling, rework, failure to focus, and failure to execute because of the emergency du jour.

• As for a “contract mentality”: actually, clear agreements are a benefit of a greater emphasis on process, not a symptom of bureaucracy. Of course there’s a strong need to work collaboratively, but it actually helps collaboration and throughput if scope and dates and responsibility/accountability are firmly identified for tasks and projects, rather than just assumed. Reaching agreements on those basics doesn’t have to even represent a huge amount of overhead, frankly, particularly considering what typically happens when the agreements aren’t clear: chaos and rework before success is ultimately snatched from the jaws of repeated failure.  As the old saw goes, people seem to have the time to do a given task over (and over and over), but not the time to do it right.
  

So don’t let the discussion be about the supposed but specious tradeoff of speed vs. bureaucracy.  Instead, it’s all about change management and all about leadership. Recognize that using the same approaches that worked earlier to shoot your company into space will now serve to drag you down to crash and burn. Don’t throw collaboration and need-for-speed out the window, but instead find ways to make them work within the new world of the broadening company.  The old world isn’t coming back, and frankly, no one really wants it to.

Yes, I admit it’s an old and hackneyed play on words, but I’ll repeat it anyway: in the course of my career, I’ve worked in IT positions in the fine States of New York, California, and Washington, but I’d have to say that the most frequent state I’ve encountered in IT matters has been the State of Denial.

It seems to be a common trend, up and down the levels of a company, to engage in a bit of willful self-delusion about IT matters, practices, outcomes.  As I thought about this, I realized that several of my key “Peterisms” (these being sayings that come out of my mouth again and again, as already chronicled here and here) have evolved as a response to this persistent theme of “states of denial”.  So let’s talk about three more of those Peterisms in that light.

• Everyone wants to get to heaven; no one wants to do what it takes to get there.

A former boss of mine was especially fond of this one.  With business stakeholders, the saying tends to pertain to things like wanting robust delivery, solid systems, ease of maintenance and flexibility, and high predictability of time frames for development and release.  But then you confront them with the not-so-shiny prerequisites to getting those things: e.g., the need for careful prioritization of desired functionality; the importance of not trying to get everything all at once; the need to hold to plans once they’re formulated, rather than changing the game every week; taking the time to test and carefully document even though those activities sometimes just seem to delay “the real work” of delivering what they want. There are tons of other examples, of course.

With IT staff (developers, operations folks) themselves, the saying pertains to things like wanting to set their own time estimates for completing their tasks; to be protected from “death march” overtime; and to have the freedom to set their own tools, standards, hours.  But then you confront them with, again, the not-so-attractive means to achieve those ends: the importance of actually hitting the estimates they themselves have provided, and the need to reduce the rework that results from people adopting different and undocumented tools and approaches.

Discipline is tough, especially self-discipline.  Across the business, I often see people wanting all the possible upsides and accepting neither the means to those ends, nor the risks or trade-offs that will necessarily ensue from those approaches.

• There’s no substitute for tedium

This one’s an original, one that I love to drone out in an onomatopoetically intentional monotone, but in truth, it’s just a restatement or narrowing of the one above. I can’t tell you how often I’ve seen people whine that something in IT is hard work or boring: going item-by-item through bug lists or feature/function estimates, for example.  I’ve probably spent literally years of my life, if you placed all the sessions end-to-end, sitting in groups meticulously going through bug lists in preparation for a software release or update.  People are often tempted to cut corners in these situations, but every time I’ve seen that attempted, the released software ended up with inexcusable issues that should have been caught and fixed prior to going live.  Functional prioritization is similar: people often want to take a power-determined “I’ll just be the one to decide” approach to it, but that’s usually done in tunnel vision, without a full look at the competing functions that would merit potentially higher prioritization than what tends to be picked through such a seat-of-the-pants approach.

There indeed may be no real substitute for this sort of tedium, but that’s still not an excuse or justification for liking it: you’re still obligated to do everything you can to reduce the amount of tedious overhead you go through, in a “continuous improvement” manner.  In the case of bug lists, for example, you want to make sure that you insist on testers entering accurate, pithy bug descriptions so that you don’t spend precious minutes repeatedly “rediscovering” what the real issue is before you can decide how large an impact the bug has.  You want to make sure you get adequate (neither understated nor overstated) assessments of each bug’s severity, so that you can operate in rapid triage mode.

• If you want to make an omelette, you’ve got to break some eggs.

I actually stopped using this one for a while, ever since I heard it was attributed to Stalin.  Fortunately, it now appears that attribution was untrue (was it Taft? Robespierre? Chamberlain?), so I can use it again in clear conscience.

Just as the main point of the first two sayings is “nothing comes without a bit of hard work,” the point of this saying, at least in terms of how I use it around IT situations, is that nothing comes without some downsides or impacts.  Changing a system to be more functional may make it less usable or elegant. Automating a process may offend or threaten people who are responsible for the way the current process is manually handled.  Downsides.  All of these must be carefully analyzed, openly discussed, and courses of action deliberately chosen while taking their impact into account. The alternative?  Denial: thinking that there’s a Shangri-La alternative out there that has no downside, where there won’t be any negative impacts, and where there is no risk.

When it comes to IT, whatever your role, you need to be ready and willing to accept that it’s going to entail some hard and often tedious work.  And you need to be mindful of the ever-presence of downsides to whatever alternatives you painstakingly choose.  Otherwise, you’re destined to be one of those people existing in a State of Denial.  And nobody wants that.

Cultural references are among the most powerful language tools around.  The old cliche may be true that a picture is worth a thousand words, but equally, a well-targeted cultural reference, used as an analogy, can stream light onto a subject better than dozens of droning paragraphs of prose.

So here’s one that comes to mind over and over again in the course of IT management: the Wizard of Oz.  And it’s not a flattering analogy; in fact, it serves more as a warning or a reminder of what not to do.

Specifically, think about the Wizard of Oz’s behavior when Dorothy asks him to help her and her friends.  She gets upset when it seems that the Wizard isn’t going to help them, but he assures them that he will, if they do just one little thing:

The Wizard: Silence, whippersnapper! The Beneficent Oz has every intention of granting your requests. [Lion instantly regains consciousness and sits up.]
Cowardly Lion: What’s that? Huh? What did he say?
The Wizard: But first you must prove yourselves worthy by performing a very small task. Bring me the broomstick of the Witch of the West.
Tin Man: But, but, but, if we do that, we’ll have to kill her to get it.
The Wizard: Bring me her broomstick and I’ll grant your requests. Now go.
Cowardly Lion: W-w-what if she kills us first?
The Wizard: I SAID GO!!!

How often do you, as an IT executive and overall manager of people, tend to display that behavior?  How often do you ask someone (a business stakeholder, or one of your staff) to first go out and fetch you a broomstick, so to speak?  I know I have.  Why does this reaction occur?  There are two basic species of reason:

1. It’s a great way to delay having to act — so, be careful of doing this as a knee-jerk response simply because you’re busy and swamped.  It becomes a defensive mechanism, and yes, your stakeholders and/or employees will start to pick up on it and/or imitate it too fully and frequently.  I had one IT manager tell me with great delight that a really effective way to get people to shut up about their needs was to ask them to document those needs.
2. Sometimes, well, you actually need that broomstick before you can grant the request. In other words, sometimes (often, in fact) you can’t magically solve people’s problems unless and until they do a little groundwork themselves.  Sometimes that’s as simple as having them write down their actual requirements, rather than leaving it to a couple of ambiguous sentences exchanged in a hallway conversation.  Sometimes it’s asking your employee to more fully research alternatives before you sign off on a purchase order for a software tool or hardware acquisition.

Remember, it’s actually acceptable (indeed, it’s usually necessary) to set these kinds of prerequisites, such as asking users to provide things like documentation and requirements and prioritization.  Granted, sometimes doing so is one of the few ways to slow down the stream of needs from the firehose that’s trained at your eyeball.  Sometimes it’s the only way of giving a quality response on things like a request to estimate the work level of effort to accomplish something.

The trick, of course, is distinguishing between situations when you’re imitating this Wizard of Oz behavior out of a pure knee-jerk reaction, and situations when you really need that broomstick in order to fulfill a request.  The key? Don’t ever ask for any broomsticks that you don’t plan to use directly and rapidly to help serve the person bringing you the request.  That tends to backfire, especially when you’ve let your broomstick request become an implicit promise to grant their wishes once they comply.

Remember the outcome in the movie.  Dorothy and her entourage, amazingly, succeed in obtaining the broomstick, and they bring it back to the Wizard, expecting to now get their wishes granted.  That’s when things really hit the fan, and they have genuine reason to get angry.

The Wizard: Can I believe my eyes? Why have you come back?
Dorothy: Please sir, we’ve done what you told us. We brought you the broomstick of the Wicked Witch of the West. We melted her.
The Wizard: Oh, you liquidated her, eh? Very resourceful.
Dorothy: Yes, sir. So we’d like you to keep your promises, if you please, sir.
The Wizard: Not so fast, NOT SO FAST! I’ll have to give the matter a little thought. Go away and come back tomorrow.
Dorothy: Tomorrow? Oh, but I want to go home now!
Tin Man: You’ve had plenty of time to think already!
Cowardly Lion: Yeah!
The Wizard: DO NOT AROUSE THE WRATH OF THE GREAT AND POWERFUL OZ! I SAID COME BACK TOMORROW!
Dorothy: If you were really Great and Powerful, you’d keep your promises!

And it goes downhill from there; the Wizard is (rightly) ultimately exposed as a charlatan.

So, key take-aways:

• be careful what you wish for and ask for from stakeholders and co-workers;
• be even more careful about what you have promised to do for them once they provide it;
• and, as appropriate to the situation, be prepared to be Great and Powerful once you actually get it: keep your promises.

I’ve touched on this topic briefly before, but here’s a lengthier discussion on why, in general, I find e-mail to be vastly preferable to voice mail for communication in the business world.

Here’s my stance: voice mail works reasonably well on a small scale in the home (i.e., personal voice mail implemented usually with answering machines), but it tends to break down completely in a large-scale business environment.

Until I took active steps to deal with it about a dozen years ago, I was getting between 50 and 100 voice mail messages a day. The “message waiting” light on my phone had become a night light for my office. At an average of a minute or two each to listen and respond, these messages were taking me hours a day to work through. I realized that our greater project team of several hundred people was able to put voice mail messages into my queue a lot faster than I could ever pull them out. Voice mail just wasn’t a good use of my personal bandwidth. So I took the radical step of putting an outgoing message on my voice mailbox, telling people that if they had a choice, please send me e-mail rather than voice mail, and I’d be able to get back to them a lot more quickly.

E-mail has flaws, of course, but sports many advantages over voice mail: most notably, it can be quickly skimmed, categorized, saved, searched, archived. What’s more, it puts you and others on the line: you can be held to what you argued, what you promised. At most, it can be misinterpreted, but it can’t easily be denied. And that’s healthy, for you, for your co-workers, and for your organization. Accountability drives responsibility.

When I communicate something in e-mail, I’m forced to examine how I’m expressing it, whether I’ve left important parts out, and whether I’ve perhaps included needless information that doesn’t add to the message. On the other hand, when I listen to my own messages in voice mail, I’m often surprised and dismayed to hear what I can now clearly see are blatant omissions or ambiguous phrasing. Once those words are out of my mouth when I’m sending a voice mail, I can’t really call them back, short of starting the response over again entirely. And given the need to listen to one’s own new incoming messages, who has time for that?

Unlike voice mail, responses to e-mail can selectively quote portions of text, so that issues can be addressed clearly, point for counterpoint. As a result, the intellectual rigor of an e-mail discussion can be substantially higher than an ongoing stream of back-and-forth voice mail messages, where people eventually forget who said what when, and the whole mess disintegrates into fuzzy impressions.

Voice mail is maddeningly sequential, provides no audit trail, no accountability, no skimmability. It can’t be kept for long, and even if you do keep it, you can’t get to a particular message quickly when you need to. Within a particular message, you can’t tell where the important information content is, since most people don’t organize their spoken messages very well. At best, you can speed a message up, or skip portions, at your peril.

Cell phones are a boon to business in general and an apparent perfect match for voice mail. So, you listen to your messages in your car while commuting, until you discover the frustration of not being able to write anything down (an appointment, a phone number) while you’re driving. So you save the message, in the vain hope that you’ll return to it later to capture the information onto paper. The more messages you save, of course, the more time-consuming it is to wade through all the old junk, since you have to do it sequentially. Eventually, your voice mailbox fills up (most companies have limits) with all this detritus, and no one is able to leave you messages at all.

Key ways in which people misuse voice mail:

• Rambling on. Most people repeat themselves a lot in oral communication; few of us are natural extemporaneous orators
• Coming to the point at the very end (beating around the bush)
• Covering multiple topics and expecting you to remember and reply to each one
• Creating team “broadcast messages” that go to dozens or even hundreds of people, with the honorable intent of “keeping everyone informed.” People in at least one company I worked for fell in love with this concept. I would get ten to twenty broadcast messages per day, most of which were going out to more than ten people at a time. In essence, it was voice mail spam. I guess I would have felt well-informed, if only I could have waded through all the messages.

How you can model a more effective use of voice mail:

• Use it mostly when you have little alternative — when you’re on the road, for example.
• Leave short, succinct messages, covering a single topic per message.
• Don’t leave “content-free” messages, such as “Sally, could you give me a call when you get a chance? Thanks.” Let people know what you’re actually calling about and what you need to know.
• If you must leave a longer message, jot down an outline in advance so that you can make it as to-the-point as possible
• Try to influence a change in your overall corporate culture with respect to broadcast announcements, so that people start to issue and expect them in e-mail, not voice mail
• Develop good writing skills, in yourself and in your staff. “Put yourself on the line” with your commitments, in writing — everyone will benefit
• Don’t ever neglect face-to-face communication in favor of either e-mail or voice mail.

Voice mail is quite literally a technology for the last century, but by and large, we still haven’t learned to use it effectively.  In fact, we go overboard on it, often out of sheer laziness. Let’s rethink. Everyone needs to get comfortable with written skills, if you want to be competitive and maximize your personal communications bandwidth. Executives who can’t or won’t use e-mail effectively are going to find themselves on the outskirts of corporate society, uninformed, uninvolved.

Let’s mix some metaphors today, and attempt to relate them all to the world of information technology and project management.

I have a good friend and colleague, one of the top IT consultants I know.  He’s able to execute crisply at the detail level while keeping the big picture in mind; he’s especially good at balancing on the fine line separating necessary diplomacy and straight-shooting directness.

For reasons I find simultaneously admirable and unfathomable, this indefatigable person, whom I’ll call Gunner here, is planning on opening a pizza parlor as a sidelight, and is currently embroiled in the process of threading the various bureaucracies and logistics to make his vision happen.  We talk about this regularly, since I am a great pizza fan.  In a recent conversation, he reported that he had just gotten city approval to use a specific lower-cost piece of equipment, news that greatly increases the chances of the pizza parlor actually becoming a reality.  So I, of course, immediately asked when opening day would be.

His answer to me was to detail all the next steps, including negotiating the lease, hiring a staff, and so on.  He never mentioned a target date.

I pointed out to him that I’d asked him an executive question, and he’d given me an IT answer. This actually wasn’t meant as a criticism, just an observation, and I had suddenly realized that this pattern of interaction is fairly common in the IT world.  Hey, I realized, I’ve even done that myself, on both the asking and answering sides.

In other words, in this case I wanted a high-level estimate, a “when”, and I really wasn’t at all interested in the steps. IT people are trained to focus on the “how”s of a project, by necessity, and they tend to dive down quickly into determining the specific steps to get from point A to point B.  And they know that especially early on in a project, the “when” is basically unknown, since it’s so dependent on the particulars that have yet to be unearthed.  There’s such a wide range of possibility in the conceivable “when”s that to them it seems pointless to speculate.  Moreover, IT people aren’t stupid: they’ve also learned that this form of executive question frequently comes from people with an elephantine memory and a deaf ear for caveats, plus a high tendency towards great disappointment and surprise if, down the road, it turns out that the tossed-off rough estimate wasn’t accurate.  Thus, IT folks retreat into the world of the “how”s, deferring the clarification of “when” as long as they can.  And both sides end up very frustrated with the other.

So, after that prelude, there are a couple of major takeaways from this pizza parlor conversation:

1. Gunner didn’t know the opening day.  In fact, he doesn’t have any idea yet about a possible opening day.  It could be months, or it could easily be more than a year.  Gunner knows instinctively, without having to put any thought whatsoever into the matter, that there are loads of important issues to resolve before he will be able to zero in on a plausible target date.
2. It was thus kind of a stupid question on my part — but exactly how stupid it really was depends on my attitude towards the exactness of the answer I get.  I need to be utterly aware that any answer I get, this early on, is going to be a wild stab, at best an approximation, and that it may indeed be completely wrong.  In essence, I’m asking a question akin to “how long is a piece of string?”  But it’s actually only an unreasonable question if I have unreasonably lofty expectations as to the accuracy of the answer.

As we all know, CEOs and other executives do ask those kinds of questions; in fact, they need to, unless they want to just operate day-to-day and see what happens.  One can’t completely avoid answering them, and moreover, one shouldn’t.  I’ve written before about this, something I call the “impedance mismatch” between IT mentalities and executive mentalities.  It leads to the situation I’ve described where “you don’t really know anywhere near enough to estimate early on (say, during annual budget season, thinking about what you’ll do in the second half of next year), but you have to estimate anyway.”

What’s the answer?  Play speed chess. This is my frequently cited metaphor for pushing IT people into making judgments and estimates without full information and in-depth analysis.  Speed chess is where you aren’t given a lot of time to think through your moves and their implications.  And if you don’t move fast enough, you lose the game.  Equally, a group of knowledgeable, experienced IT middle-level managers can, relatively quickly, give you “SWAG” estimates on even high-level descriptions of projects, if you push them into it.  They’ll naturally be reluctant to do so, but the way to overcome that reluctance is to insist that the basic rule of the game is that these are “guesses without penalties”. They’ll do their professional best to come up with reasonable estimates (neither padded nor overly optimistic), but everyone in the game, executives and technologists alike, has to clearly understand that these estimates will be wildly wrong at least 30% of the time, because they’re based on limited information and a lot of implicit assumptions.  “Play speed chess”, intoned repeatedly as a slogan, can help both the executives and the technologists remember that, now and down the road.

So, maybe I can get Gunner to put some chess boards and time clocks into his new pizza parlor.  I’ll have to ask him for an estimate on when that’ll happen.

Lagniappe:

• Malcolm Gladwell, Blink: The Power of Thinking Without Thinking