|
|
| Home - Industry Article - Sep 04 Issue |
Business Technology Leadership: What IT Means in the Early 21st Century |
By Steve Andriole, Founder & CTO, TechVestCo
Leadership Challenges – Then & Now
Two major business technology leadership challenges occurred in the 1990s. The first was regressive. The Y2K remediation problem – which turned out to be not much of a problem at all – scared just about every technology project off the docket that wasn’t focused on keeping the machines running. As companies invested millions of dollars to keep things working, they also fanned the fire of resentment about how thousands of computers might actually shut down on January 1, 2000. Many senior managers suspected that the techies really didn’t know what they were doing when they wrote all that COBOL code way back when and – worse – really weren’t sure if they could fix it all by the new millennium. It was a tense time for all sorts of reasons. While senior management leaned on technologists to lead the Y2K compliance effort, it was a leadership exercise focused directly on the past – past mistakes, that is.
While the Y2K problem was playing out, another leadership challenge emerged. But this one – eBusiness – was positive, and focused on the future. But the early Web site development projects were managed not so much by technologists as marketing professionals. Of course, the technologists had to be involved in the process, but many of the early Web sites were actually hosted by some of the new application service providers (ASPs) such as Exodus Communications (now gone). Arguably, technologists failed to lead the initial development of Web-based “brochureware” or transaction processing-based Web sites. At best, these projects were co-managed by technologists and marketing managers (in much the same way that marketing often owns current customer relationship management [CRM] projects).
Long before Nickolas Carr published his now famous “IT Doesn’t Matter” article in the Harvard Business Review, technology leadership was changing. The technology heroes of the 1970s and 1980s were different from the heroes of the 1990s, and the heroes of the early 21st century wouldn’t even recognize their 20th century counterparts. However, successful career management requires that we understand how heroes – and heroic behavior – are defined.
So where’s leadership headed now?
Five years ago leadership could be defined around desktop operating system upgrades; today that same project would probably require leadership around the development of the RFP and SLA necessary to outsource the activity. As supply chains compress, leaders are necessary to optimize the business technology partnership.
Impact and influence are changing as well. In the 1990s it was more than enough to report on a successful implementation of a back-office accounting system; today the only meaningful performance metrics are business value metrics. Did the project increase our market share? Our profits? Are our customers happier now that we invested in CRM?
Communications are changing. Business cases must now be in the language of business, not techno-speak.
Does all of this mean that operational technology is unimportant? Or that there are no leadership opportunities below the line? Of course not. But business technology leadership is about above-the-line excellence, not below-the-line efficiencies – which are expected, just as compliance to Sarbanes-Oxley is expected.
Another way of thinking about 21st century leadership challenges is to ask yourself – and your staff – if they think that the jobs they’re performing today will persist into 2010. In a recent survey I took among over 100 technology professionals across three companies (one public, one private and one not-for-profit), not one director-level (or higher) technology professional believed that he or she would be doing the same thing they’re doing today just five years from now. If this anecdotal data is correct, we’ll all have new jobs by 2010. What will they be? This report looks at these emerging leadership challenges and provides a wake-up call of sorts to any of us still stuck in the 1990s!
What Leaders Do …
In the midst of all these changes, what should business technology “leaders” do? Among other things, they should:
Build Collaborative Business Scenarios
Track (Only) Technology that Matters
Identify Business Pain & Pleasure
Organize Adaptively
Manage Infrastructure
Communicate
“Market”
They do these things because they all – one way or another – connect them seamlessly and holistically with the business models and processes that determine competitive positioning, market share, growth and profitability.
Build Business Scenarios
In the 1990s when I was CTO of CIGNA we engaged IBM to develop a set of business scenarios that described where the insurance and financial services industries would be in the early 21st century. My group at CIGNA was The Technology Group which was responsible for setting technology standards, defining the overall computing and communications architecture, maintaining security, and managing the research and development (R&D) process. In order to develop credibility with the CIGNA lines of business, we suspended all talk about technology and instead focused on current and emerging business models and processes. Needless to say, in the mid-1990s this disarmed the business executives, since their image of “systems” was that we were always late, always expensive and always a little arrogant. Realizing this (I was well coached by Bob Zito, my Senior Technology Officer and a CIGNA veteran), I used business scenarios as a friendly Trojan Horse. It worked well. Why? Because all of the effort was about the business, not technology.
Business technology leaders should focus on business models and processes before they focus on technology infrastructure or applications. Macro business trends should occupy their time, trends like eBusiness, customization, personalization, and supply chain planning and management – all suggested by Figure 1. Leaders get their companies in the upper right hand corner of the cube.
Scenario planning identifies the drivers of change, their velocity and the confidence we have in their validity. Good scenarios also quantify the uncertainties that complicate planning.
But what good scenarios really do is profile marketplaces and profitable transactions. They also identify constraints. They are compasses that influence the direction that strategic decisions take.
Figure 1: Emerging Business Models
Business technology leaders develop, package and “sell” business scenarios. They work with the business to profile “as is” and – especially – “to be” business models and processes. They become champions of the scenario development process; they brand themselves as business-models-first-technology-second heroes.
Is this to say that business models and processes should be developed independently of technology-enabled opportunities? No, but they should lead the process. There will be times when new business models are difficult if not impossible to imagine without technology knowledge. Since business technology leaders understand technology, they’re in a good position to exploit the business technology intersection.
Track Technology that Matters
Leaders also track technology trends – especially trends that matter to the business. Trends that matter include all technologies that can impact business, not technology “concepts” or even “prototypes.” Examples? The semantic web – the intelligent Internet – is a tremendously interesting concept – but it’s a long way from implementation. Real-time synchronization (and real-time computing generally) are also fascinating concepts but, again, we’re some years from away from productive implementation.
Utility computing, on the other hand – the technology acquisition and support model that uses the electricity model to describe it’s pay-by-the-drink approach to technology acquisition – is emerging as a prototype with some potential – though it’s way too early to commit to a major investment in whole technology subscription models. Similarly, grid computing is showing some promise as is Web Services technology, thin clients and the newest voice recognition technologies. These all bear watching so long as they map on to the business scenarios that the same business technology leaders develop.
Technology “clusters” are real and powerful – and ripe for exploitation. Clusters are proven technologies with large supporting casts of developers and support vendors; they’re also supported by well-funded vendor R&D infrastructures.
Figure 2 organizes all this in a picture. Business technology leaders should focus on the chasm between prototypes and clusters – the thick line between the two in the figure. They should track the more interesting concepts but resist temptations to hype technologies that are still in the early stages of development: the last thing that a business executive wants to hear about is how “cool” a technology is, or how great it’s going to be (in five years). I am forever amazed at how enthusiastically technologists describe technologies that are largely irrelevant to the business for the foreseeable future, and how indignant technologists become when the eyes of the executives glaze over after five minutes of over-hype. Figure 4 helps us understand the relative value of technologies and how to allocate our tracking resources.
Leaders understand the differences among technology concepts, prototypes and clusters and never over-hype technologies because of their elegance or potential. Instead, leaders play the role of technology gatekeeper making sure that the business never invests in technologies before their time – before they’re able to contribute directly, cost-effectively and profitably to the business. Leaders are able to generate enough credibility so that the business believes they’re acting in the best interest of the business not technology.
Figure 2: Technology Distinctions - & the Chasm that Leaders Track
Leaders also track dominant technology standards. Would you have invested heavily in Bluetooth wireless communications technology two years ago? Would you have done the same in Web Services in 2001? Are you tracking service oriented architectures, or have you already moved to event driven architectures? Who’s watching RFID standards? Leaders do a couple of things here First, they watch the standards power brokers. Can any of us deny the impact that IBM’s decision to support Linux had on the adoption of the operating system? Wal-Mart will yield tremendous power over RFID standards (as it has in the collaborative forecasting and replenishment, inventory and supply chain management areas). As the technology industry continues to consolidate, the number of companies with standards-setting power is actually shrinking, which is good news for leaders searching for direction. The second thing that leaders do is map the trajectory of standards onto their business scenarios. How will Wal-Mart-influenced RFID standards affect your business? How will IBM’s support of Linux change the way your company thinks about server OSs?
|
|
|
