My April 28th letter made reference to a fascinating study of network reliability, specifically the trade-off between tolerance of accidents and resistance to deliberate attacks. The referenced PDF file, for no known reason, became corrupted at just about the time that the letter went out: Im pleased to report that the administrator of the site replied immediately when I finally took the time to report the problem, and that the link now appears to be working correctly.
It seems to me that this illustrates a key advantage of ubiquitously connected IT, compared with the more isolated networks of about 10 years ago. We can do more things at lower initial cost because the follow-up cost of refining them is so much less than it used to be. We can actually afford, in many more ways, to adopt the mantra of “Ready, Fire, Aim” that Tom Peters and Bob Waterman coined in their 1982 book, “In Search of Excellence.”
Its vital to realize that Peters and Waterman never intended this expression to be an excuse for poor quality or a cynical description of customer abuse. On the contrary, they intended to raise expectations for rapid resolution of problems and for short-cycle improvement of products and services. Peters has quoted Ross Perot as describing the advantages of quickly correcting errors and neutralizing threats, saying, “At EDS, when you see a snake you kill it. At General Motors, when you see a snake, first you seek out the best consultants on snakes. Then you appoint a committee on snakes. And then you study snakes for a year or two.” Killing snakes, not breeding bugs, is the goal.
Id be the first to point out that Peters often makes money by arguing both sides: After selling 6 million copies of “In Search of Excellence,” he discovered five years later that only 14 of that books 43 exemplary companies were still looking good. He promptly began a new book, “Thriving on Chaos,” with the statement that “There are no excellent companies.” Oh. When Peters talks about the process of “conjectures and refutations,” we have to realize that sometimes hes refuting himself–and we need to have the courage to do the same, candidly if perhaps not joyfully, as we learn.
When we stop pretending that well always do it right the first time, were able to discuss the need to build a robust mechanism for repairing and improving our initial efforts. We dont really want to discourage IT vendors, for example, from picking their own point on the continuum of short time-to-market versus bulletproof hardware and software quality: As long as customers have accurate information about the outcomes of vendors product development processes, they can make their own best choice to meet their varying needs across the spectrum that runs from bleeding-edge innovation to rock-solid reliability.
What we want is to have our cake of rapid product development cycles without spending too much time in the kitchen of bug tracking and patch management. At an IT security conference where I spoke last week, hosted by Washington Group International in Boise, Microsoft Strategic Technology Director Brett Arsenault put this goal high on his companys agenda, calling patch management “by far the biggest problem” in maintaining IT security. “Ideally,” he said, there should be a common update service for operating systems, drivers and other key software that is used by all vendors, “a place … [that] shouldnt be owned by Microsoft.”
Not denying errors, but disclosing them promptly and fixing them inexpensively; not being defensive, but being proactive in offering customers a portfolio of options; not passively accepting what vendors provide, but clearly stating our preferences and needs, and reflecting them in our purchase decisions. Fire when ready; aim at will.
