19. Great Designs Come from Great Designers
Not from Great Design Processes
The basic premise underlying the SEI’s [Software Engineering Institute] work on software process maturity is that the quality of a software product is largely determined by the quality of the software development and maintenance processes used to build it.
MARK PAULK [1995], “THE EVOLUTION
OF THE SEI’S CAPABILITY MATURITY
MODEL FOR SOFTWARE”
...[W]hile some may see them as the crazy ones, we see genius, because the ones who are crazy enough to think that they can change the world, are the ones who do.
STEVE JOBS, APPLE COMMERCIAL (1997)
Great Designs and Product Processes
The authors of the opening quotes could hardly disagree more. Who’s right?
I have earlier listed a little personal classification of well-known computer products, divided according to whether or not a product has passionate fans. It is expanded as Figure 19-1, with some more recent additions. I believe this division reflects some greatness in the designs. (It does not at all correspond to commercial success, which depends complexly on many factors besides design quality.)
Figure 19-1 Computer product fan clubs
(After Brooks [1995], The Mythical Man-Month, Figure 16-1)
A striking thing about this chart is that, so far as I can determine, every one of the right-hand products was produced by a formal product process, one involving many inputs and many approvals. Each of the left-hand products was produced outside a normal product process.
Examples abound in other fields: the atomic bomb, the nuclear submarine, the ballistic missile, the stealth airplane, the Spitfire, penicillin, the intermittent windshield wiper. Each of these innovations was produced by a small team, either naturally or intentionally set apart from normal product processes.
Product Processes—Cons and Pros
This observation, even if true frequently but not always,1 raises important questions:
• Why do so many great products issue outside product processes?
• What are product processes for? Why have them?
• Can one do a great design within a product process? How?
• How can we make product processes that encourage and facilitate great designs, rather than inhibiting them?
Do Product Processes Stifle Great Designs?
I believe that standard corporate product design processes do indeed work against truly great and innovative design. Considering how and why corporate processes evolve, this is not hard to understand. Product processes exist to bring order out of the natural chaos that develops new products.
By its very nature, process is conservative, aiming to bring similar but somewhat different things within one orderly framework. Hence the really dissimilar, the highly innovative, doesn’t fit the framework. Consider the personal computer, not really the same thing at all as the institutional glass house of the 1960s or the central departmental minicomputer of the 1970s.
By its very nature, a product process aims at predictability: a product roughly defined by business needs before any great designer has spent substantial time on the problem, to be delivered at a stated time at a stated price. Predictability and great design are not friends.
By its very nature, a product process “fights the last war,” encouraging tactics that have worked in the past and discouraging those that have failed. Hence for the product addressing a new war—a totally new need or mode of operating—both kinds of tactics may be irrelevant. Consider the iPhone, not really the same thing at all as a simple mobile phone, much less the land-line instrument Alexander Graham Bell invented and his AT&T monopolized.
By its very nature, a product process is veto-oriented, aimed at blocking bad ideas and catching oversights. The process aims to inhibit products that won’t sell as hoped, products that cost more than expected to deliver, promises about function and schedule that can’t be kept. More subtly, a corporate product process also aims to inhibit a confused product line, where one’s own products are one’s most deadly competitors, and customers don’t know what to buy. Since failure can arise from many causes, product processes typically demand consensus by many people, each expert in a separate cause of potential failure.
Such consensus stifles great design in several ways. First, each expert watchdog is paid to avoid mistakes, not to make great things happen. So each is separately biased toward finding reasons not to proceed. Even when a really new product is not vetoed, consensus mechanisms often take off the sharp edges by forcing compromises. But the sharp edges are the cutting edges!
Next, product processes require not only consensus among the living and present, but consensus with the past, as codified into rules. Product processes grow, and as with all bodies of rules, each mistake-experience begets new rules or new approvals to prevent repeats. There are few barriers to the birth of such extra rules, and, once they are born, there are no forces for their elimination until a crisis comes. By the very nature of things, bureaucracies become more Byzantine, processes heavier, and organizations less nimble as they succeed and grow.2
When I was managing the development of IBM’s System/360 computer family hardware in the early 1960s, our S/360 Model 20 mainframe was being developed in IBM’s laboratory in Böblingen, Germany. This team had great talent and strong leadership. Yet, although they had been in operation for many years and had produced successful products for specialized markets, they had never quite succeeded in getting a product into IBM’s main product line, its worldwide market. For the “bet your company” System/360 project, this was scary, so I went to investigate.
The reason became clear. The engineers had always conscientiously and scrupulously followed IBM’s official Corporate Product Procedure, as documented in a manual of more than 100 pages. Successful project managers in other labs made bold “exceptions” to the procedure rules at the right times; the secret to success was choosing wisely!3 I sent such an experienced procedure manipulator to manage the project. He enabled the strong talent there to realize its potential. The S/360 Model 20 became phenomenally successful.
Finally, consensus processes starve innovative design by eating the resource. Consensus building takes meetings, lots of meetings. Meetings take time, lots of time. Great designers are few and far between; their time is exceedingly precious.
So Why Have a Product Process at All?
Am I quixotically advocating a revolutionary overthrow of all corporate design processes, in favor of creative chaos? I am not. Many of the reasons for process noted above are inescapable. At some point, corporate approval to go ahead must be obtained; at some point, experience should be tapped to catch obvious oversights; at some point, a product schedule and budget must be agreed. The trick is to hold “process” off long enough to permit great design to occur, so that the lesser issues can be debated once the great design is on the table—rather than smothering it in the cradle.
Follow-on Products
Further, a product design process will always have an important role because most designs are not intended to be highly innovative. This is for good reasons. Once users get their hands on a successful and truly innovative product, at least four separate effects follow:
• Use reveals shortcomings that need to be corrected in follow-on products.
• Users will put the innovation to unexpected uses, enlarging the product concept, usually in an incremental way.
• The innovation’s demonstrated usefulness creates a demand for a more capable product, and a readiness to pay more for it.
• Yet simultaneously with all these drivers for change, popularity breeds lock-in; users don’t want the next product to be “revolutionary”—they want what they know and like.
Thus, follow-on products are much more highly constrained and have less room for true innovation. At the same time, success breeds multiple opportunities and possible directions for enhancements in follow-on products. Yet no organization can do everything. So these follow-on products must be carefully selected from the range of possibilities. Their development must be monitored to ensure that the product stays on track to accomplish its chosen objectives and reach its forecasted customers.
Product processes, with their repeated cycles of
• Product definition
• Market forecast
• Cost estimate
• Price estimate
efficiently accomplish this selection and this monitoring.
But accurate market forecasting depends on having some sales experience with similar products. Accurate cost estimating depends on having some development and manufacturing experience with similar products.
Thus, product processes are, properly, designed for follow-on products. For innovation, one must step outside of process.
Raising the Level of Design Practice
Product design and release processes cannot turn good designers into great ones. They rarely produce great designs without a great designer. But the disciplines imposed can bring up the low end of the design curve and improve the average performance of the art. That’s nothing to sneeze at.
The software engineering community has given much attention to its development processes. It has needed to, for I know of few design communities where average practice is so far behind best practice, and where worst practice is so far behind average practice.
The work of Watts Humphrey and the Software Engineering Institute in developing the Capability Maturity Model and energetically prosecuting its adoption has been valuable.4 The CMM is a disciplined measure of components of a good design process that have generally been found to be useful. When a design shop does a CMM audit and scores poorly, it is time to look not only at its own practices but at those of more successful shops. Process improvement is most valuable in raising the floor of a community’s practice. The CMM has done a good job of that.
There is no magic there. No amount of process improvement can raise the ceiling of the community’s practice. Great designs do not come from great processes; they come from talented people doing hard work. Apple is quoted as saying, “We’re at Level I [on the Capability Maturity Model] and will always be.”5 Yet Apple’s results speak for themselves.
Isn’t Process Necessary Even for Innovative Designs?
I’ve been asked, “Surely the S/360 project, coordinating international labs and the business needs of multiple markets, made use of a great deal of process. How did you harness it without being stifled by it?”
Our core design team was well insulated from normal IBM oversight processes, with strong support from several levels of bold managers. We had exceptional capabilities to recruit talent from other company groups. We had enough money.
Getting the designs out as products required going through the standard processes. From the top came the word that this gamble was known to be revolutionary, and that it would require some bending of normal processes. The weekly struggle was our team’s pushing for more innovation in forecasting, estimating, pricing, and so forth, and the process teams’ proper pushing back. The talents of the process people were, however, of high order, and their skills were essential to our success.
The Clash: Process Stifles, Process Is Unavoidable; What to Do?
Great Designs Come from Great Designers; Find Them!
As a tone-deaf nonathletic man, I think it evident that not only are talents, whether for music, pitching, dancing, or design, unevenly distributed, but the range for any particular talent is enormous.
Even within a team of people of similar education and experience, gifts vary widely. I have had some team members and some students who were superbly gifted designers—they glitter in my memory. The history of the arts is bejeweled with examples.
Moreover, no two people have the same bundle of talents. (I think God did this so that each one of us will have something unique to give to other people, some unique way to serve.) Hence a wise leader organizes by drawing responsibility boxes around the people he has and can get, rather than putting people into the boxes he dreams up as abstractly ideal.
Our right and fundamental democratic concern is that all people be equal before the law and, a much more difficult goal, have equal opportunity. But pursuit of these goals must not blind us to the wildly unequal distribution of native talents, and the unequal drives to grow, hone, and express native talent.
Hence our structures and processes must cold-bloodedly recognize that people who have done great designs are more likely to make yet others if entrusted with freedom and authority to do so.6
Great Designers Require Bold Leaders Who Demand Innovation
First and foremost, the top leader of the organization must passionately want innovative products with great designs. This was clearly true of Apple under Steve Jobs’s first reign, less true under his successors, and true again when he resumed the throne. It was true of IBM under both Thomas J. Watson (CEO 1914–1956) and Thomas J. Watson, Jr. (CEO 1956–1971). Other examples abound.
How to Make a Process That Encourages Great Designs?
I have suffered under burdensome processes, and I have some experience in bypassing or violating such, but I have no experience in pruning or restructuring them. Every organization needs to do that from time to time. I should want to delegate that job to a first-class talent with a sweeping authority for a limited task and time.
If one is designing a new product procedure or restructuring an existing one, how does one build in the counterforces necessary to overcome the natural inhibitory tendencies? How can one make a process that allows, enables, and even encourages great designs?
First, the product procedure must explicitly identify the matters of fundamental importance and constrain those, and those only. It is inherently a protective mechanism. It must securely protect the crown jewels, but, equally important, it must eschew building high fences around the garbage cans. This requires discretion and restraint—the instinct of protectors is to overprotect. Chapter 27, “Case Study: A Joint Computer Center Organization,” illustrates how the separate identification of matters of fundamental importance worked in a specific case.
Second, the product procedure must provide easy and swift exception mechanisms, exercisable at the appeal of any project manager and the approval of only one sufficiently high-level boss. In other words, judgment and common sense must be explicitly provided for and readily available: “All rules can be broken.”
Go for Conceptual Integrity: Entrust Your Design to a Chief Designer
Since conceptual integrity is the most important attribute of a great design, and since that comes from one or a few minds working uno animo, the wise manager boldly entrusts each design task to a gifted chief designer.7
Entrusting has many implications. First, the manager himself must not second-guess the design. This is a real temptation, because the manager is quite apt to be a designer, but one whose design gifts may not be as great as the best who report to him (design and management are very different jobs), and one whose attention is surely fragmented among other tasks.
Next, it must be crystal clear to all that the chief designer, although perhaps managing only a few assistants, has complete authority over the design, and that he ranks equal with the project manager sociologically.
Third, the chief designer must be shielded from watchbirds from outside the project and protected from time diversions.
Fourth, he must be provided with tools and help as he sees the need. What he is doing is of prime importance.
Notes and References
1. Air Force Studies Board [2008], Pre-Milestone A and Early-Phase Systems Engineering, states that it is true for many of the most successful and innovative weapons development projects.
2. This universal phenomenon hits software as well, as convincingly documented by Lehman and Belady’s classic study of the growth of entropy over time in IBM’s Operating System/360: Lehman and Belady [1971], “Programming system dynamics.” A more thorough treatment is in an important paper: Lehman and Belady [1976], “A model of large program development.”
3. See the essay “Template zombies,” Chapter 86 in DeMarco [2008], Adrenaline Junkies and Template Zombies. I do not believe this IBM lab was afflicted with the form-versus-substance disease of the template zombie but was just conscientiously following the written rules sent from afar.
4. This has been recognized by the award of a National Medal of Technology in 2005.
5. James Robertson of the Atlantic Systems Guild gave me the Apple quote in 2008 (personal communication).
6. Cross [1996b], “Winning by design,” is a delightful case study of the methods of Gordon Murray, a winning racing car designer. The account reports a chief-designer team, avoiding most kinds of process, and benefiting from constraints.
7. The British Deputy Prime Minister sought from the Royal Academy of Engineering a report on how to make rail travel safer. The RAE delegated the task to a committee of only one person: its President, Sir David Davies. The report was done in record time and is crisp and forthright, rich with concrete recommendations (Davies [2000], Automatic Train Protection for the Railway Network in Britain).