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.

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.

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.

Just a heads-up for readers: CTO/CIO Perspectives was mentioned this week in an interesting article in CIO Magazine, titled “20 Things You Can Do In 20 Minutes to Be More Successful at Work“. Not all the tips are spot-on, in my view (and I commented to that effect in the comments section), but there are definitely some gems there worth considering. All of us juggle a varied and heavy workload, and have frustrations about maintaining our personal productivity amidst the fray; lots of things in this article can help. Check it out!

In general, I highly recommend following the content published in CIO. As with all things, not everything is of equal value, but the range of topics and discussion is absolutely germane to anyone in an executive IT role in particular.

Joining some 89 million of my fellow netizens, I’m starting a blog. But there will be no pictures of my dog here. Instead, this one will concern itself with what I’m calling “Intensely practical lessons learned in the CTO/CIO trenches.”

Despite my considerable and immutable youth (I assure you that this is true), I’ve had a 25-year career in information technology, serving as a senior executive at Internet companies for the last ten or so of those years. I’m a strange combination, I think sometimes: a CTO who rose up through the ranks of software development, then got “religion” on project management and operational issues, and who maintains an extremely strong interest in and affinity for business issues, particularly those revolving around customers. I’m also a bit of an amateur “internet sociologist”, fascinated by what makes such companies succeed and fail, rise and fall. This admixture will make for some odd, but I hope interesting, topic choices at times.

I searched around the blogosphere (perhaps rightly one of the top most hated words on the internet), looking for something similar to the kind of blog I envisioned, and frankly, I couldn’t find it. Listed at the bottom of this post are links to some of the CTO/CIO blogs I did find, and I welcome people’s comments that point me to useful blogs that I might have missed.

One thing I’ve learned as an executive is the value of stating one’s goals at the outset, so here are mine for this blog:

• address what I see as common information technology issues / problems, ones that span just about every company;
• bring in real-world experiences and anecdotes related to the topic, with names changed to protect the guilty;
• provide “meaty” posts on the topic at hand, instilled with personal perspective;
• post at least once a week;
• provide useful topic-related links in each posting (what I’m calling my Lagniappe section).

This blog will be all over the map of the technology executive experience: I have at least 50 topics already jotted down, just off the top of my head. I plan to cover such things as vendor management, managing expectations, metrics, working with senior management, keeping up with technology, hiring and firing, application portfolio management. I’ll be writing a lot about what I regard as the key p-p-p-pillars of a CTO’s purview: People, Process, Product, Projects, Performance. There won’t necessarily be a logical progression of topic from post to post; I’ll just see where the spirit moves me.

So, what won’t this blog be about? It’ll of course be CTO/CIO-oriented, but one key thing that I have discovered from doing those jobs is that technology itself is really only about 10% of the job. So you’ll see only about 10% of my posts, at most, covering purely technical topics. Unlike one CTO blog I found, you will never see lists of instructions here for configuring hardware or software, with phrases like “Mount the Longhorn x86 Beta 3 ISO image on the VM, and boot the image.” That stuff certainly has its place, but it just won’t be here.

As does just about every blog, I hope to inspire a certain quantity of quality dialog on the topics I cover, but that will probably have to wait for a bit of traffic to build. Whether you agree or disagree with my stances, please consider chiming in with your own personal experiences regarding the topic. And remember I’m new here to the blogging world, so I’ll be learning tools and tips as I go.

Lagniappe:

Other CTO/CIO-oriented blogs: I was aiming for relatively generalist (not product-specific) blogs of this nature, ones that are still being kept current, with typically at least three posts a month. As I noted, though, I didn’t find very many of these, so not all of the ones below fit that criterion. These are not listed in any particular order (and were updated in November, 2009; for a more accurate look at current top CTO/CIO blogs, consult my blogroll):

• SoCal CTO, by Tony Karrer: http://socalcto.blogspot.com/
• Candid CIO, by Will Weider, CIO of Ministry Health Care and Affinity Health System: http://candidcio.com/
• CIO Mind, by Felix Enescu, http://ciomind.biz/
• CTO Blog, from various authors at CapGemini: http://www.capgemini.com/ctoblog/
• CTO 2.0, by Antonio Chagoury: http://www.cto20.com/
• CTO blog, by Lars Struwe Christensen: http://www.giritech.com/int/Giritech/CTO-Blog
• CIO Blog, by Peter Birley: http://www.cioblog.co.uk/