It’s probably already evident that a lot of the focus of this blog is going to be on “blocking and tackling” principles related to running information technology at a reasonable-sized company. Curiously, those basic principles often seem to get ignored, which is one way that lots of companies end up in crises of information systems delivery and operations.
This post, then, is going to be about the most basic of basics: reading and writing, and their importance (“critical success factor” importance, in fact) to the overall success of a CTO/CIO’s projects and department.
Reading
Early in my career, I noted with some amount of irritation that many executives wouldn’t read anything longer than a couple of sentences. Complex plans are just that: complex, and most things in information and technology require more than a superficial once-over. I was on a huge project once, where our team had collectively produced a 100-page document outlining an important future technology of the company. There was a lot of meat on that bone. The frustrating part was that no one in senior management was reading it, despite our efforts to make it interesting, relevant, and well-argued. All that changed with the advent of the new COO, who showed up at the first meeting with his heavily thumbed copy, full of yellow stickies and annotations. The fact that he’d done his homework made a big impression on me as a model to follow.
Here’s what I push myself to read as CTO (and, as a corollary, what I ask my people to produce as deliverables, with me contributing both content and close editing at all junctures):
- Product Requirements Documents (in full)
- Engineering Requirements Documents
- Operational Requirements Documents
- Strategy Documents (architecture, platform, software application acquisition, etc.)
Second observation: I feel that it’s critical, as a CTO/CIO, to read actively in the field. You should know the key books in the literature, both from a historical perspective and what’s making news and creating buzz now. I try to read at least one technology-related book a month, and although I often fall short of that goal, it’s constantly on my mind.
Writing
For years I’ve used the adage that “none of us took enough writing classes.” Anyone can come up with a plan or an approach, but adeptly communicating that approach to others (both to convince those who need convincing and to ensure that the plan is executed accurately) is actually the key difference between success and failure. I’ve found that too many people in IT rely on “table thumping” in meetings to carry the day for their points, as opposed to using solid, careful analysis that lays out the pros and cons of the various alternatives. To me, it’s not really a plan unless it’s written down and people have tried actively to poke holes in it.
Interestingly, sometimes it doesn’t matter all that much if anyone actually reads the documents–it’s the discipline of writing them that counts. As Dwight D. Eisenhower pointed out, “I have always found that plans are useless, but planning is indispensable.”
And, where my approach on reading is to do so voluminously, my advice on writing is to do so succinctly, as much as possible.
One of my favorite writing-related scenes in a movie is in A River Runs Through It
So, it’s back to the basics: reading and writing, just as we were taught in school. Two of the three Rs. Both take a lot of work. Be prepared to do both, frequently and enthusiastically. And it turns out that ‘Rithmetic matters too. Stay tuned for my next posting.
Lagniappe:
I’ve just started a new page, referenced via the page list at the top right-hand side of this blog, that will list what I consider to be “must read” books, as well as ones I’m either just finishing or have on the “to read” stack. See it here.
Peter, What is your take on reading technical books versus management/leadership books?
Great question, Tom, one that I wish I’d addressed in the list introduction.
My feeling is that both are necessary, and finding the right things to read in both categories isn’t all that easy. For example, I don’t need to even glance at, much less read, a book on IIS server configuration if that’s not the technology my organization is using or contemplating. If it’s an area we are using, though, and maybe one where we’re struggling, and I want to get the issues straightened out in my mind, I’ll consider picking it up. I probably spend hours a week in bookstores and/or online, figuring out what I should be reading.
Equally, I try to stay abreast of the classic and current management and leadership books (by the way, airport bookshop browsing is astonishingly useful for figuring out what’s current in that category), but I read quite selectively in that arena.