When I talk with CEOs about what they want out of IT, technology leadership is high on their list. When I talk with CIOs about technology leadership, I see an occasional wistful smile, quickly replaced by a grimaced, “Where’s the budget for that?”

The theoretical answer: All around them … in the hands of all the other C-level executives who might benefit from new technologies if the CIO could clearly explain how they might benefit from it, and what would be required to give it a try.

It isn’t that simple, though, because as Clayton Christensen explained in The Innovator’s Dilemma back in 1997, few organizations invest in radical innovations, because there’s always a higher-ROI use for the funds, namely, improving the business in its current form.

Helping other parts of the business get better at what they do right now might not be easy, but it’s straightforward. Helping them figure out new and different things they might do? That sounds like a lot of personal risk, and long hours and hard work besides.

Also, most business leaders understand how things work right now, and by the way, they’re working well right now, or at least well enough. They’ll welcome improvements. Many can’t even envision something radically different, let alone want to make it happen.

And besides, a little-recognized transformation has taken place in industry: R&D has been replaced by M&A. The executives of most large corporations have figured that, compared to the cost and risk of developing innovations themselves, it’s a lot safer to let small, venture-funded startups take on the risk. When the technology and techniques have matured enough to be of practical use, they can acquire one of the successful ones, license their technology, or outsource its use to them at a fraction of the cost and risk of in-house R&D.

Oh, and it’s a whole lot safer to wait until some other company has figured things out than to be the figure-it-outer. Sure, we might lose a couple of years to a competitor, but on the other hand, now we get to adopt “best practices,” never mind that “best practice” means “what our competitor was doing last year and we’ll manage to start doing next year.”

To be fair, being second one into the pool can make a lot of sense. Sure, the IT punditocracy still makes a big fuss about the “first-mover advantage,” the proposition that whoever introduces an innovative product first has such an astounding advantage that everyone else might as well pack their bags and go home. But this is a zombie idea — one that refuses to die, even though the only evidence is counter-examples.

So letting someone else make the mistakes, but with all the preparation that lets you pounce six months later, just might be the winning strategy for a lot of opportunities. The problem is, this strategy easily turns into an excuse to not make those preparations.

Now you’re an also-ran, because, as has been pointed out in this space once or twice, mirror-chess is a losing strategy.

Technology leadership is starting to look pretty complicated, isn’t it? The phrase falls trippingly off the tongue, as the Bard might have said, but actually doing it in a way that works requires more than vision and boldness.

It requires:

  • Awareness. Not all business leaders are readers, but all business leaders need to be readers. Including you, because if you don’t read, you won’t know what’s going on, let alone have any idea whether or not it matters.
  • Relationships. Implementing a new technology is a collaborative effort. IT’s leaders in particular, but really everyone in IT needs to know people throughout the company, well enough to know how they think and what they care about. What — you think you can approach a total stranger with evidence and logic and have any influence?
  • Astuteness. “This will transform the company!” has drama. “Here’s how this fits into what you’re doing,” has plausibility. Guess which wins.
  • ETAM (that’s enterprise technical architecture management). Not initially — for pilot projects you can use a big hammer if that’s the only tool you have to connect new technology to what you already have in place. But to scale beyond a pilot you need a mature enterprise technical architecture management function in place.

This isn’t going to be easy. But consider the alternative. If you don’t take this on, your CEO is likely to bring in people like me.

Etymology isn’t identity. Where words come from is a matter of historical interest, not proper usage.

So I hope you enjoyed your Memorial Day, even though it’s become little more than a day off and an opportunity for retailers to offer sale prices.

Not that Memorial Day is something to be cynical about. I think about the sacrifices men and women in uniform have made for us and I’m reminded of the Passover tradition, where parents explain to their children that God brought them out of slavery — them personally, not just their ancestors.

Most of those who made the ultimate sacrifice probably weren’t thinking of us at the time. More likely they were thinking of getting the job done, of their buddies, and of their families. And yet, they sacrificed themselves for each of us, personally, and we shouldn’t forget it.

Which has what to do with running an IT department?

Just this: Too often, business leaders cast the need to get the job done in moral terms. There’s a project with milestones and deadlines — employees who don’t meet them are letting the company down, aren’t taking responsibility, won’t “give 200%” (and can we please start respecting the field of mathematics by jettisoning this tired cliché?).

They’re bad people, even though the milestones, and deadlines, and staffing to accomplish them, were adjusted to the point of absurdity through optimism bias and political necessity.

Please remember — the success of a business project lacks the moral imperative of liberating Dachau’s prisoners, not to mention France.

What’s hard is that this isn’t binary. You have more alternatives than just death marches and clock-watching.

In business, a sense of urgency is a valuable dimension of the corporate culture. It’s just that more isn’t better. Even more urgent is equal to frantic — an unproductive state in which employees divert their energy and attention from getting things done to worrying about how they’ll ever manage to get things done, while managers divert their time and energy from making sure things get done to making sure employees look busy every minute of every hour of every day.

There’s a dimension of oddity to this, too. The best executive leaders project an air of relaxed confidence. They’re able to act with urgency without ever looking rushed and harried.

But many of these same leaders interpret an aura of relaxed confidence in their employees as apathy and lack of commitment.

Go figure.

Getting back to deadlines and making them, you want this to matter to everyone. You want this to be a matter of professional pride. You want to make sure “This deadline was never realistic” isn’t the team’s default conclusion when the deadline becomes challenging, even as you conclude it’s time to change the deadline because it was never realistic.

Which brings us to a broader topic.

In some situations, the point of stability is where you want to be. That’s when leadership is easy. None come to mind at the moment, but I’m sure there are situations like this.

Leadership is hard when the stable places are the extremes, because that’s where staying in the healthy middle takes constant attention, a great deal of energy, and constant vigilance.

Maintaining a balance in the healthy middle that bisects the line that has apathy on one end and frantic flailing on the other is just one example. Maintaining a healthy balance between the stable cultural characteristics of chaos and bureaucracy is another.

If you’re a metrics-oriented sort, ask yourself how you’ll measure this sort of thing. Take CMMI (Capability Maturity Model integration), which in many respects is an admirable approach to process maturity. CMMI doesn’t, of course, advocate bureaucracy as it promotes increasing sophistication in process management.

The problem: It doesn’t recognize the near-inevitability of an encroaching culture of bureaucracy as organizations become more process-mature, and incorporate strong management practices to prevent it.

For that matter, and it’s a related matter, CMMI, like most maturity models, has a strong focus on metrics, but tends to hand-wave over the difficulty of making sure the metrics used to measure a process are the right metrics.

Here’s what I’ve never seen: A multidimensional maturity model that makes too much just as immature as too little.

But this is exactly what mature business leaders have to do.