Skills that have mattered to me as a CTO/CIO

This time on a more personal note: I’ve been reflecting lately about the various specific skills that helped propel me in my career, and how I picked those up. These are mostly metaskills, rather than specific technical capabilities. A number of technologies that I spent a long time becoming expert in are not listed, for example, in the interest of emphasizing the broader lessons, the mindsets, the “core understandings” that have molded my outlook. Are these skills applicable to you and to your path? Only you can be the judge. I offer them up simply as a catalog of things that I feel have boosted my career.

  • Writing. The ability to express one’s thoughts and plans in clear, logical, well-formed language is, I feel, the single most valuable skill to bring to the workplace, particularly in an executive role. Writing is not easy, and the result is by no means always perfect. But this skill is definitely top of the list.

[Read more…]

Rock and a hard place: why estimating turns into a squeeze play

I wasn’t ever a very good bridge player, and it’s been decades since I played. Hence, using this analogy may be stretching matters, but as is typical, I took away some key metaphors from my time with the game. One is the squeeze play, where you force your opponent to discard a vital card. It’s similar in a way to what’s called Zugzwang in chess, which describes a situation where one player is put at a disadvantage because he has to make a move, and by doing so (any move, in other words) will force himself into a weaker position.

How does all this relate to CTOs and CIOs? Consider the case of having to estimate how long a specific project will take, particularly early on, usually before any kind of detailed requirements are even remotely fathomed. Note that this kind of estimating is among the most critical activities that you and your organization will do, because it feeds into the organization’s whole prioritization and costing process as a whole. Unfortunately, it gets you into exactly this kind of squeeze situation. If you say a project is going to take what’s considered to be “too long”, you’ll get beaten down about why you can’t do it faster. If you blithely “sign up” for doing it too fast (say, as fast as they want it), there’s a huge risk that you won’t be able to deliver.

[Read more…]

Nightmares before Halloween: bad dreams of the CTO/CIO

In honor of the season, I thought I’d share a few recurring nightmares, ones that unfortunately don’t seem to confine themselves to the fall time frame. All of these are chronic worries that have truly kept me up at night; most of them stem from actual real-life situations I’ve encountered.

1. Your CEO calls you and asks you why the web site is down… and you didn’t know it was!

When the company’s web site (or any other mission-critical system) is down, escalation mechanisms need to inform you and inform you fast. Of course, the site should rarely / never be down other than for scheduled maintenance, so putting yourself in that notification loop (subject to calls in the middle of the night) shouldn’t be too common and painful. If you’re not informed of these situations, I’d argue that either your team isn’t sufficiently on top of detecting them, or they’re “sparing you the pain” of being told. In truth, the pain has to be spread around. The onus of notifying management is one mighty incentive to make sure that the need to do so arises as seldom as possible. Don’t tolerate being part of (much less at the helm of) an organization that purposely or through omission sweeps things under the rug.

[Read more…]

The agony and the agony: firing an employee

This may be the hardest posting to write so far, but it is a necessary bookend to my other recent posts about hiring. It’s hard to write because actually firing anyone is hard: it’s emotional and full of moments of self-doubt, before and after. And I can only scratch the surface of the subject here in a normal-length post.

Terminating people is, of course, a necessary part of any senior manager’s responsibilities, but it never gets easier. It affects people’s lives, families, careers, self-esteem. I’m going to focus here on performance-related terminations, not on general staff layoffs (“RIFs”, or “Reductions in Force”, as they now seem to be universally called). And I won’t be talking too much about the nuts and bolts of how to do it most effectively or kindly; see the Lagniappe section below for some helpful tips from others on that subject.

Donald Trump aside, concluding that you’re going to terminate someone because of his or her performance is never a snap decision (or at least it shouldn’t be). Being a manager is primarily a people job, and people are, well, difficult at times. Technical people may be especially so: extremely bright, specialized, independent, resistant to coaching. Nearly everyone in a technology role has the ability to contribute in some form, otherwise they wouldn’t be in the job in the first place, or (at least) your decision wouldn’t involve quite as much anguish. Determining, conclusively, that the downsides of dealing with a problem employee outweigh the upsides of his or her contribution: that, in my experience, is the tough part.

[Read more…]

A team-oriented approach to making good hires

I made two really bad hiring decisions in a row a few years back, and I have to admit that it shook me for a while. I won’t go into details about why these two hires were horrendous (although I should note that the problem was not because the requisite technical skills were lacking), but the most important thing I can say about them is that both hires happened when, with all good intentions, I departed from the general hiring process and practice that I’ve evolved to over the years.

This process doesn’t always work out exactly as described below, for scheduling reasons, but here’s what I strive for and what I’ve found tends to get great results:

[Read more…]

Hiring and firing: an example of a stellar employee

I plan to make a couple of posts surrounding the very thorny issue of hiring (and firing) IT staff. To start off, here’s a recommendation letter I wrote a couple of years ago, at the request of a former employee. It shows at least one executive’s (i.e., my own) view of what matters in a job candidate most of all, and how certain characteristics can (sometimes, not always) make up for lack of background or experience. I’ll call him Harry. What I sought (and found) in Harry doesn’t necessarily pertain equally to all IT positions, but I offer it for consideration:

I have known Harry for over four years, ever since I hired him into the role of Project Manager at XYZ, where I was the VP of Information Technology.

[Read more…]

Career tips for the CTO/CIO path

One of the most frequent questions I’ve gotten after starting this blog pertains to how one can work up to the CTO or CIO role in IT. This isn’t all that easy to answer, other than with some platitudes. Every career is different; every individual takes a separate path. I can’t exactly recommend to people that they take the path that I took, because there were certainly some odd stutter steps and digressions along my route. That said, I do indeed have some biases and thoughts about how a motivated, talented IT professional can position herself or himself for a top management role in IT.

  • Get broad. Strive to understand ALL of IT: development, quality assurance, operations, project management, architecture, user experience, PC help issues. And, of course, there’s no better way to understand those areas than to do some kind of rotation into each and every one of them, formally or informally. Diversify yourself. Doing so fully may require moving companies. One of my favorite Tom Peters’ quotes is “‘Repot’ yourself every ten years.” With respect to high tech, it needs to be more frequently than that.

[Read more…]

Einstein and the care and feeding of upper management

One area where I feel I’ve learned and grown in my career is achieving a much clearer understanding on how to communicate with upper management. Most advice along these lines tends towards simply warning against overuse of technobabble, and I can’t disagree with that. But there’s a lot more to successful communication than simply that, and I’d like to describe here a few ways to avoid the pitfalls that I’ve seen IT people (including myself) fall into in these situations. None of these ideas is especially new or difficult, but they don’t always seem to come intuitively to IT folks.

When presenting a problem and/or proposal to upper management, keep in mind the following:

[Read more…]