Avoiding the Rubber Stamp maintenance renewal syndrome

As I discussed last time, everything you add to your environment (hardware, software) costs money in recurring fees. Part of the job of the CTO/CIO is to sign dozens of invoices, each and every week, that approve payment for the various elements in your infrastructure that have come up for renewal. And hey, we’re all busy. Anyone who’s been pestered by the company’s usually indefatigable accounts payable department knows the perils of not having signed off an invoice in a timely manner: in other words, you can’t afford to let them languish. Problem is, it’s relatively easy to fall into a “rubber stamp” mode, scribble a quick signature, and move on to the rest of your busy day.

Multiply that by dozens of invoices a week, 52 weeks a year. A few thousand dollars here, a few thousand there: as the saying goes, pretty soon you’re talking about real money. Careful scrutiny of each and every expense takes time and effort, but my view is that it’s one of the major responsibilities of the job. The amount of company expenditures that flow through IT places an important onus on you, the head of technology, to constantly be thinning the carrots, so to speak.

[Read more…]

Budgeting maintenance and support for IT

What does IT do, anyway?

Well, among other things, IT spends money. In many modern companies, the expenditures made through IT are among the highest in the company, second only to salaries and marketing.

What does that mean? It often means that when cost-cutting time comes around (as it tends to do, in cycles, at most companies), there’s a particularly harsh spotlight that shines on IT expenditures, and a vast amount of pressure emerges to reduce these, quickly.

Unfortunately, the “quickly” part of that last sentence just isn’t realistic. A lot of IT expenditures can’t be turned off (or down) at a moment’s notice. In many or even most cases, the company has already signed (and paid for) maintenance agreements with hardware and software providers that typically last a year, if not longer.

[Read more…]

DWYSYWD: IT and the value of declaring victory

I saw a license plate recently that read DWYSYWD. I puzzled over it for a while (Google wasn’t handy), and then it suddenly flashed on me: Do What You Say You Will Do. I’ve since learned that this is a well-known phrase, used by people such as Colin Powell, among others.

How does this relate to IT and the CTO/CIO? Well, all sermonizing aside about how “Do What You Say You Will Do” is a great mantra in general for life, it particularly fits the rapidly swirling technical project world that the CTO/CIO copes with every day. In that world, as we all know, it’s easy to say that you’ll do things, and you’ll certainly be pressured to say you’ll do more and more. Actually getting them done, however, is a bit harder.

How important is it to Do What You Say You Will Do? I went into a CTO role once where I rapidly observed that I had inherited a team that wasn’t doing. In fact, the team wasn’t saying, either. Astonishing as it may seem, they had been allowed by company management to fall into the pattern of making no commitments for delivery, in anything other than the vaguest of possible terms, most of which had to do with stating noble intentions of working hard. In other words, they weren’t really putting themselves on the line. A major part of my approach there was to emphasize the importance of making, and then meeting, specific commitments for delivery. “Commit, Deliver, Track & Communicate” became the simply-stated, three-pronged “get well plan” in that situation. Easily stated, not so easy to achieve; but that’s a story for a different posting someday.

My major point here, though, and an important part of project delivery (doing what you say you will do) that occasionally gets lost, is declaring victory when the project is successfully launched. This declaration should be a relatively formal, executive-penned announcement of the launch, usually delivered via a broadly disseminated e-mail.

Insisting on declaring victory has a number of important purposes:
[Read more…]

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…]

Mastodon