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.