End-of-year Peterisms for the CTO/CIO

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

• Don’t tell them no—tell them what it will take to say yes.

IT personnel are frequently in the position of having to say no — in response to an unrealistic expectation, a potential breach of security, a violation of established policy. I’ve learned to emphasize the other side of that, though: rather than simply saying “no” to the request, it’s useful to outline potential ways of getting to what the person wants. Sometimes, carefully handled, that’s a reductio ad absurbum approach, through which the requester realizes themselves that they’ve asked for something completely infeasible. But in any case, it’s a good self-discipline for IT itself (remember my strong view that IT is a service organization), in that it forces us to examine what measures might actually enable the achievement of the request. Would more funding help? More personnel? Stopping work on other high-priority projects? Working overtime (yet again)? In the end, actively looking for “ways to get to yes” helps everyone establish the company’s true priorities and understand the others’ point of view.

• When the only tool you have is a hammer, everything looks like a nail

We’re all subject to this kind of laziness and complacency: the tools we’ve gotten used to are the tools we tend to use in every situation possible. I worked with a FORTRAN programmer in the late ’80s (no joke) who was so fluent and capable in that arena that he resisted using all manner of new tools, from spreadsheets to scripting languages. At another company I worked for recently, the entire web site architecture (as well as nearly all tools) for a high-volume site was built on Tcl, which is not exactly leading-edge scalable technology. Clearly, every company needs to settle on standards and toolsets — my argument, however, is that you need to work actively on avoiding establishing a monoculture. I’ll have further posts in the new year about appropriately diversifying an organization’s tools.

• You can’t fit 8 pounds of manure into a five-pound bag

This one’s a personal favorite, perhaps the one I trot out most frequently. As you might guess, it argues for “right-sizing” IT’s efforts to what’s achievable with available resources. The trouble is, it’s fairly common for an idealistic and energetic corporate management group to want to push forward on multiple fronts simultaneously. Indeed, doing so may be necessary to maintain market competitiveness for the company’s offerings. Alas, it’s considerably easier to dream up and spawn a project than it is to actually bring that project to fruition. Executives should perhaps be called “idea-tives” instead, because we tend to minimize how long it takes to execute the many ideas we dream up. Meanwhile, we’ve moved on to the next big idea, forgetting that the wheels are still churning throughout the organization on executing our last big idea. And (see above), we don’t tend to want to hear “no.”

Again, as I’ve stated before, the most important role of management is the proper allocation of resources. Finite resources, that is, spread across many areas of demand. In essence, that allocation is a zero-sum game: when you add a project to the plate, you need to remove a project. Just as you do with planned expenditures when you have a fixed budget. Educating the entire organization on this basic, unavoidable fiscal-like project discipline is one of the major ongoing challenges (as in uphill battles) of the CTO/CIO.