Chapter 1 - The Cost versus Innovation Paradox
In the pharmaceutical industry, firms spend an inordinate amount on research and development of drugs, and work on many projects at once. They are aware mores of the drugs will fail at some point in the process, and the few that do survive have to cover the cost of all the ones that failed. It's common practice to plan for a great deal of waste and failure on the road to success, and they budget accordingly.
This speaks to a common technology paradox: executives are expected innovate, but at the same time keep costs to a minimum. One CIO refers to it as the "and" proposition: given a choice between controlling cost or innovating, companies demand they do both.
No CIO has a failure budget, nor much tolerance for having multiple failures for every successful experiment - which looking to other research efforts, seems to be the common practice. Trapped in between, their course is to take calculated risks and seek incremental improvements - pursuing only those experiments with a small chance of failure, or a small cost of failure. And as in any investment, small risks reap small rewards.
For the last thirty years, business has looked to technology for efficiency and productivity, and as such the prime directive to the IT department was to make everything faster and cheaper. Given that tasks were being automated for the first time, the IT department could deliver very significant value at very little cost. But now that most tasks have been automated and computerized, the largest strides have been made and progress has become more gradual.
And still, efficiency and productivity are still the same goals - with the added threats of outsourcing and offshoring if the internal department can't work cheaply enough. There's little reward for being innovative, and great punishment for failure to be efficient.
Also, consider that IT departments were originally internal support - the same staff who repaired the photocopiers provided installation and support of computers as pieces of office equipment. Being called to the table where business plans are made was new to them, an area in which they had no experience of expertise. Newer still is direct service being provided to consumers through mobile and social networking, another area in which technology employees had no background.
Meanwhile, most CIOs are "just deploying technology" in the same way they used to deploy other office equipment, responding to demand but having little input into the choices made by business.
Be a Chameleon
An interesting observation: IT success depends more heavily on people skills than technology. While its work product is technical, it cannot succeed unless it addresses the behaviors and attitudes of other people in the organization. Developing a new iPad application for the sales is easier than getting the salesmen to abandon their familiar and comfortable ways of working and adopt the new solution. Every IT product requires a cultural change.
On top of managing the technology solutions, the technology leader must meet with internal and external customers, work on changes to business models and processes, and interact with those on multiple levels of the organization. The ability to "change colors" and be whatever is needed is called "the chameleon factor" - you must have a variety of skills and be able to shift as needed.
The difficulty in doing so is it drags technology professionals out of the familiar world of hardware and software and requires them to interact with people - not only do technology professionals lack those skills, but they are missing from the IT culture. They were not needed before, and have atrophied to nonexistence.
Develop a Really Effective Metaphor
Information technology can be complicated and abstract, wholly unfamiliar to those outside of the profession. The author suggests that metaphors can be used to communicate something complicated to someone who doesn't understand technology.
The author unwinds a yarn about an IT executive who was looking to have a meaningful conversation about globalization, and worked with a photographer to arrive at an image of a three-lane highway with trucks, taxis, and motorcycles in different lanes - metaphorical in their size and ability to carry cargo, being a vehicle owned by the driver versus one that is temporarily rented, when it is wise to use one versus another, etc.
(EN: Two words of caution from personal experience. The first is that people who enjoy metaphors are not necessarily good at it - the strained metaphor becomes so disjointed and abstract that it really doesn't communicate anything and might be confusing things worse. The second is that it is an overused practice, so much so that some businesspeople shut down entirely when the geeks start telling fairytales - they are either insulted or feel that something is being concealed or misrepresented. It was a good practice once, but abuse has ruined it.)
Keep it Simple
Another obstacle for technology executives is the complexity and fragility of systems. Recall that technology was originally fractured, with departments like payroll, inventory, marketing, and whatnot all seeking to leverage different systems. This was all good and well until they wanted to integrate their systems, meaning a considerable amount of effort was needed to get the marketing database to share data with the inventory management system and vice-versa.
As such, much effort (at much expense) was put into systems integration, with a great deal of duct tape, and eventually into establishing a standard platform and rewriting applications to leverage central resources. The task of integrating internal systems had barely gotten underway when the demand came to interface them with external (vendor/customer) systems. It's a constant stream of paradigm shifts - likened to trying to "paint an airplane while it is flying."
The business is indifferent to the technical complexities - to them, it is a simple task to share information between two different departments, and they have little appreciation of the fact that it takes serious rewiring. That integration wasn't considered in the first place, that IT lacked the crystal ball to foresee what the business might want ten years later (and that the business, at the time, wanted a fast and cheap solution and disregarded warnings about the future) is of no concern.
And so, IT executives are further incented to ratchet down the costs, by internal customers who already think them to be too expensive, stripping down to bare bones and paring away any unnecessary cost ... like the cost of being innovative.
It's also inherent n the IT culture to consider complexities and throw up barriers. When a business executive wants to do something, the technical staff never say "sure, no problem," but instead begin explaining why it's impossible to do it quickly and at a reasonable cost. This not only saps innovation in the IT department, but throughout the entire enterprise.
Very often, there is a lot of vestigial complexity from the earliest days of technology, as evidenced by the number of people and systems that do essentially the same function for different business units. As an example, one firm discovered it had 33 different help desks to assist internal users with various systems; the same firm found it had 27 different data centers under different managers. Nothing can be done quickly and cheaply in such an unnecessarily complicated environment. To be nimble, you must first simplify.
The author suggests several CIOs he has interviewed are taking the approach of creating innovating groups - such that the majority of the staff can focus on the maintenance and operational tasks without the responsibility to innovate, and innovators can be freed from the daily M&O tasks. They staff these groups with bright technologists who also have good business sense. Others resist the notion of having a separate group, because an innovation group becomes an ivory tower of people who have zany ideas that can be dumped off on others to build and maintain, but instead seek to enable people in any role to suggest ideas - in hopes of getting better ideas, even if they are fewer.
Also, being too strict about developing solutions for everyone, everywhere, can be stifling. Eighty percent is good enough. An example is given of a firm that developed a system that worked everywhere except one remote region ... the solution being to implement the system for everyone except that region rather than abandoning the benefit of the many for a few for whom the new system would have been inappropriate.
Another suggestion is to be more broad-minded in the quest to innovate. Don't simply look at companies in your industry, but any company anywhere - that is, to learn from best-in-show and not just best-in-breed or best-in-class. Smaller firms tend to be more nimble - they are not encumbered by legacy systems and are able to consider the possibilities without being held back by devotion to obsolete technologies.
There seems to be an oblique reference to SOAP - building applications that access existing information without having to reside on proprietary systems, which enables firms to be nimble, knocking out applications to provided needed functions without having to modify monoliths.
A consultant who works with an array of firms remarks on a difference he notices in companies that predate the Internet and those who have arisen since: the latter are much more inclined to seek simple solutions to achieve results, and a willingness to adapt their systems and business practices accordingly, whereas the older firms seek to preserve systems and practices, which makes it difficult to implement simple and straightforward solutions.
As an example, consider developing an application to push data from a mainframe to an iPad. The simple solution is to write an iPad application that accesses mainframe data - the harder path is to write a mainframe application that provides data to the iPad. Yet the latter is the course that many established firms follow - they are focused not on performance and results, but on security, authentication, access control, and reporting.
As to whether this is necessary, it seems not to be: the same consultant researched the applications that were running on back-end systems to find that 80% of them merely read information (didn't even add/edit/delete records from databases) - and there is no practical reason they should be mainframe applications rather than device applications that have access to data. By creating middleware with read-only privileges, they were able to innovate and experiment without much cost.
Reorganize for Innovation
An anecdote from a CIO in the beverage industry, who found himself with the daunting task of coordinating the various information systems of thirty bottling facilities his company quickly acquired: ten separate ERP systems, thirty different route accounting systems, and multiple flavors of mainframe.
The first step was standardizing operations themselves: each data system was designed (or rigged) to support the activities of employees, and so long as the processes and practices remained heterogeneous, a single IT solution could not be implemented. This process took three years, and forced the firm to undergo a process of innovation because the disparate practices could not all be carried forward - they had to discover the best and most efficient practices.
The first step to doing this was outsourcing - necessary because the internal experts could not think to the future when their days were consumed with dealing with help-desk tickets and other exigencies of the moment. (EN: This is actually a great use of outsourcing: not only is the heads-down work sent out and innovation kept inside, but it also is a measure that should be temporary: when the new systems were in place, the outside help can be ramped down and eventually end when the older systems become discontinued.)
The next step was reorganizing the IT department according to the stakeholder groups that are served rather than the technical expertise - this is key to innovation, as there's less to be discovered by looking at the system than in the way that it is used to accomplish a given purpose, and having a single person in the role of relationship manager does more to keep the staff disconnected from their customers. This model involves the staff in the business decisions of their customers, and enables IT managers to have a voice in strategic decisions.
At another firm, a separate innovation group was established, and the author asserts this is the path that "many" follow. Most employees are needed to manage the ongoing operations and deal with the crises of the day, and are constrained in what they are able to do. A small group can be liberated from both demands and constraints under which the rest work, free to be creative in their thinking, and also free from the need to justify their expenses. Innovation and discovery are regarded as a waste of money because they do not have immediate or guaranteed results - you have to be free to go in the wrong direction in order to discover the right destination.
Build a Culture of Innovation
Another CIO expresses the way in which IT departments function as "striving for mediocrity" - by adopting a subservient role, IT departments ensure that they are regarded as servants whose advice and guidance is not needed or wanted. IT must do more than respond to demands to be regarded as capable of providing leadership.
In his organization, the CIO sought to begin with a dialog about the way in which his department was supporting the business needs, but translated that into a mutual effort to discover ways in which needs could be better served, in which IT had more of a voice in defining problems and suggesting solutions than merely responding passively to demand.
The author pauses a moment from the anecdote to remark that what this constitutes is a cultural change, begun in the IT organization, that must spread outward to the company. It seems ironic that most insiders regard IT as if it were something outside the business, but yet most innovation involves a technical component and, as such, IT is often central to innovation across the organization. The most successful CIOs break this paradox, take their technical expertise and apply it to make improvements across the organization, and are in a unique position to exercise influence and leadership across many other departments.
A personal anecdote from a new CIO who, in his first week on the job, made a very public declaration that he didn't accept the job "to strive for mediocrity." He developed a mission statement for the IT department that focused on innovation that clarified the intent to strive for improvement and innovation, the redesigned the office to accommodate collaboration among small teams instead of large meetings, then negotiated to get $1.5 million allocated to innovation.
Jump to another CIO who was able to give her enterprise architect a budget of $1 million for R&D. "One million dollars doesn't sound like a lot, but my architect was used to having nothing." And given a little bit of time and money, a plan was formulated to reduce operating costs by over 50%.
Jump back to the first guy: he instituted "tech jams" to enable staffers to gather in small groups and talk about technology in a broader sense - what they could do rather than what was on their plates at any given moment. The results were "phenomenal" and the company found that there was a lot of untapped creative power in people who were mistaken for dull and mundane because of the work they were required to do did not provide an opportunity to be innovative.
Conclusion
(EN: Just to note that the conclusion of this chapter, and presumably the others that follow, are a quick summary of key points already discussed, so I'll likely be skipping them.)