Fred Brooks on the Design of Design

The Design of Design: Essays from a Computer Scientist, Brooks, Frederick P.

Currently a professor of computer science at the University of North Carolina, Fred Brooks led the development of IBM’s System/360 and its operating system. He’s the author of The Mythical Man-Month : Essays on Software Engineering, which remains one of the best books on project management in the real world. In The Design of Design,  Brooks reflects on what he has learned about the problems of design over the course of his long and distinguished career. He combines his reflections with case studies drawn from multiple design efforts. Here is his justification for adding one more volume to the growing literature about design:

the design process has evolved very rapidly since World War II, and the set of changes has rarely been discussed. Team design is increasingly the norm for complex artifacts. Teams are often geographically dispersed. Designers are increasingly divorced from both use and implementation — typically they no longer can build with their own hands the things they design. All kinds of designs are now captured in computer models instead of drawings. Formal design processes are increasingly taught, and they are often mandated by employers.

I believe a "science of design" to be an impossible and indeed misleading goal. This liberating skepticism gives license to speak from intuition and experience — including the experience of other designers who have graciously shared their insights with me.  [The Design of Design, pp.xi-xii]

Brooks begins with a look at various rational, engineering-centric, models of the design process including Herbert Simon’s view of design as a search process and various waterfall models of software development. His take, and mine, is that these models bear only a passing resemblance to how real designers actually do design. Whatever value they might have as reminders to experienced designers is outweighed by the risks they pose in the hands of those without the necessary experience base to appreciate their limitations.

Brooks frames the design process problem this way:

  • If the Rational model is really wrong,
  • If having a wrong model really matters, and
  • If there are deep reasons for the long persistence of the wrong model,

then what are better models that

  • Emphasize the progressive discovery and evolution of design requirements,
  • Are memorably visualized so that they can be readily taught and readily understood by team and stakeholders, and
  • Still facilitate contracting among fallen humans?  {p.52]

Brooks thinks that something along the lines of Barry Boehm’s Spiral Model of software development will best meet these criteria.

In the middle section of his book, Brooks explores a variety of topics and issues relating to design including

  • when collaboration is useful vs. when it is not
  • conceptual integrity
  • identifying the core budgeted constraint (rarely money)
  • finding and developing great designers

In the final section, Brooks examines several cases in depth.

As a series of essays and reflections, this book is most valuable to those who have wrestled with design problems of their own. Given the frequency with which all of us are presented with design problems, Brooks’ reflections on real design problems offers many useful insights. Among the insights that I will be mulling over:

  • the boldest design decisions, whoever made them, have accounted for a high fraction of the goodness of the outcome
  • great designs have conceptual integrity–unity, economy, clarity. They not only work, they delight.
  • An articulated guess beats an unspoken assumption
  • wrong explicit assumptions are much better than vague ones
  • If a design, particularly a team design, is to have conceptual integrity, one should name the scarce resource explicitly, track it publicly, control it firmly 

Observable work – more on knowledge work visibility (#owork)

My post on the visibility of knowledge work last week generated some some excellent comments and excellent blog posts around the web. For my own benefit I wanted to gather up what I’ve come across so far and put it in one place.


Greg Lloyd, CEO at Traction Software, kicked things off. pulled together some key threads of the conversation and gave us a better label – “observable work.” His initial summary:

I believe that principles of open, observable work like open book financial reporting to employees – is a simple and powerful principle that people at every level of an organization can become comfortable using. In my opinion, wider adoption of observable work principles can succeed with support and encouragement from true leaders at every level of an organization – as Peter Drucker defines that role: “A manager’s task is to make the strengths of people effective and their weakness irrelevant–and that applies fully as much to the manager’s boss as it applies to the manager’s subordinates.” Enterprise 2.0 and Observable Work

Greg also pointed to an excellent post by John Tropea at Library Clips:

why do I have close to total awareness of people in my personal life that requires low effort, but yet in the workplace I don t have this ambient awareness!

In fact it may be more crucial to have micro-blogging/activity stream networks in the workplace as we share and work on the same/similar/related goals and tasks within our teams, across teams, workgroups, and enterprise wide so the more we are aware, the more we can be on the same page, and have better coordination, cooperation and collaboration surface opportunities (emergence), have the best people on the right tasks, and generally have the ability to be more responsive and adaptive.

Balancing Uniqueness and Uniformity in Knowledge Work

Self-portrait of Leonardo da Vinci. Red chalk....

Image via Wikipedia

The essence of good knowledge work is uniqueness not uniformity. The ideal knowledge work product is exactly what your client asked for and could only have been created by you. The challenge is that we have been conditioned by the industrial economy to value uniformity and see uniqueness as undesirable variation instead of the essential quality it has become.

To deliver better knowledge work products, we need to unlearn habits and develop new perspectives. Our inappropriate habits stem from assumptions about industrial work. With industrial thinking, once you ve created a new product the goal becomes how to replicate it predictably. You specify the characteristics of the output precisely, lock down the process, or, ideally, do both. That works if you need to manufacture cars or calculate every employee s pay stub correctly. It doesn t when the goal is to create the new product. The primary challenge here is to shift focus away from the issue of replication and toward creation. The question becomes how do we manage to create this? instead of how do we produce the same thing all over again?

Creating good knowledge work has a challenge beyond simple uniqueness. It is the same challenge faced by artists who once worked at the pleasure of their patrons. You want to create your art, but ultimately, you have to please your patron as well. You need to educate your patron about the nature and qualities of the output you have been commissioned to create and you need to learn from your patron what limits and constraints they face in putting that output to work. The unique insights where value resides may need to be packaged in a document or presentation package comfortable to the organization. Or you may need to place those insights in a more familiar context that lets them be seen by the organization.

Working out a feasible balance between the unique and the familiar is more complex and more subtle than either simply delivering what the customer asks for or creating an off-the-shelf product. It is not precisely a negotiation, nor is it generally a full-bore collaboration.

A basic strategy for discovering an appropriate knowledge work output has three parts.

1. Defining a deliverable.

If you ve grown up in a professional services environment, what s the deliverable? gets tattooed on the inside of your eyeballs. It s essential in professional services because it creates something tangible for which you can get paid. In any form of knowledge work the notion is valuable in that it makes something tangible out of what can otherwise be an amorphous process. A deliverable might be a spreadsheet or a presentation, an executive workshop, or a first release of a new information system; regardless, it needs to be something that both you and your client can point to and decide that it is done.

2. Understanding how the deliverable will be used.

The most important thing to understand about a deliverable is what your customer intends to do with it. Will it be used to identify a decision to be made? Justify that decision to someone higher in the food chain? Generate or eliminate alternatives?

Each of these possible uses influences what is important about the deliverable and what is secondary or irrelevant. For example, if your customer wants to understand whether a particular technology does or doesn t work in their current environment, a lengthy analysis of the current state of the software market isn t likely to be relevant.

That same analysis may be the essential requirement of someone evaluating whether to introduce their technology to the market. Whether you invest in preparing the analysis depends first and foremost on whether someone needs it.

3. Determining how the deliverable can be created.

Understanding how a deliverable will be used sets limits and focuses your attention on how it should be created. An executive who needs an answer about whether to invest in a new distribution channel may prefer that answer delivered on a one-page memo. However, if your customer is that executive s support staff, you may need to create substantial supporting analyses. Even in that case, whether you deliver that supporting analysis as a bound report, an electronic document, or organized as a series of frequently asked questions will affect both its value to the customer and its cost (to you) to create.

This three-step process should be followed for every piece of knowledge work we create. The urge to standardize outputs or processes is a holdover from industrial practices that is inappropriate in a knowledge work environment. Applied here, it risks short-circuiting the essential interaction. We must define and deliver the unique output that integrates client needs with your ability to create an appropriately unique solution.

More from Dan Pink on the Science of Motivation and Purpose

My long-time friend (old is such an ugly word) Vaughn Merlyn at IT Organization Circa 2017 points to the following fascinating animation to a speech by Dan Pink on his most recent book Drive, which I reviewed here earlier this year. It’s well worth 10 minutes of your time to watch.


We are in the midst of learning some immensely meaningful stuff about how our minds work in recent years. I’m willing to bet that those organizations that factor this knowledge into their designs first are going to make significant strides in the next few years.

Managing the visibility of knowledge work

Debates over whether the Internet is making us smart or stupid are entertaining in the bar and can serve as a pleasant background noise for ruminating during a keynote address in a dimly lit hotel ballroom. When I get back to work on Monday (or more likely on Sunday night) I return to the reality of working in a fundamentally digital environment. My files are digital, my tools are digital, and most of my interactions are digital.

As a knowledge worker, much of what I get paid for happens inside my own head. Before the advent of a more or less ubiquitous digital environment, however, that head work used to generate a variety of markers and visible manifestations. That visibility was important in several ways that weren’t evident until they disappeared:

  • Seeing work in progress in front of me made it possible to gauge my progress and make connections between disparate elements of my work.
  • Different physical representations helped to quickly establish how baked a particular idea was.
  • Physically shared work spaces supported rich social interactions that enriched the final deliverables and contributed to the learning of multiple individuals connected to the effort.

For all the productivity gains that accrue to the digitization of knowledge work, one unintended consequence has been to make the execution of knowledge work essentially invisible, making it harder to manage and improve such work. The benefits of visibility are now something that we need to seek mindfully instead of getting them for free from the work environment.

Knowledge work is better understood as craft work; its products are valuable because they are creative and original. Delivering identical consulting reports to different clients is grounds for a lawsuit, not an example of good knowledge management practice.

From a craft perspective, examining and understanding what constitutes a quality client report, for example, is an important part of the apprenticeship that transforms a recently minted MBA into a seasoned advisor. The visibility or invisibility of knowledge work products can make this process more or less difficult.

Before PowerPoint, crafted presentations began with a pad of paper and a pencil. You knew by looking at a roughed-out set of slides that it was a draft; erasures, cross outs, and arrows made that more obvious. You then took your draft to the graphics department, where you were yelled at for how little lead time you provided. A commercial artist tackled your incomprehensible draft spending several days hand-lettering text and building your graphs and charts.

From there you started an iterative process, correcting and amending your presentation. Copies were circulated and marked up by your manager and hers. Eventually, the client got to see it and you hoped you’d gotten things right.

Work was visible throughout this old-style process. Moreover, that visibility was a side effect of the work’s physicality. Junior members of the team could see how the process unfolded and the product evolved. You could see how editors and commenters reacted to different parts of the product. Knowledge sharing was a free and valuable side effect of processes that were naturally visible.

With e-mail, word processors, spreadsheets, and presentation tools, maintaining visibility of your knowledge work (at both the individual and workgroup level) requires mindful effort. An office full of papers and books provided clues about the knowledge work process; a laptop offers few such clues. A file directory listing is pretty thin in terms of useful knowledge sharing content. In an analog process, it’s easy to discern the history and flow of work. When an executive takes a set of paper slides and rearranges them on a conference room floor, a hidden and compelling story line may be revealed. You can see, and learn from, this fresh point of experience. That’s lost when the same process occurs at a laptop keyboard at 35,000 feet. The gain in personal productivity occurs at the expense of organizational learning.

In the digital process, who creates and what they contribute risks becoming more an exercise in political posturing and interpretation than simple observation. The abstracts in a document management system reveal little about what work is exemplary, new, or innovative, and obscures emerging patterns.

Invisibility is an accidental and little-recognized characteristic of digital knowledge work. Seeing the problem is the first step to a solution. While better technology tools will play an important role, the next steps are changes in attitude and behavior at the individual and work group level. For example, organizing your own digital files into project-related directories might help, but not if you continue to name files "FinalPresentationNN.doc" where NN is some number between 1 and 15 representing a crude effort at version control. Embed more information in the file name where you know it will be visible even as you e-mail it around the organization. Use more informative subject lines on your email. Those file names and subject lines should provide the best clues possible as to what will be found inside.

Systems developers have learned that time invested in naming standards and conventions pays off. Teams crafting knowledge-work products should make the same investments. Better yet, spend time with good development teams and look for ways to adapt their practices to more general-knowledge work.

New disciplines take time to become habits. Fortunately, they also eventually become "the way we do work here." As the disciplines take root, taking a more aggressive look at technology tools becomes appropriate. Many of the office suite tools offer some form of internal revision tracking or auditing tools. What’s missing is any systematic way to integrate these tools into a disciplined practice. The capabilities are there but they are irrelevant if they aren’t used intelligently. A version control system doesn’t do anything until you incorporate it into the routine practice of creating a new document.

The right starting point is to simply make the flow of work more visible. I suspect that this is one of the underlying attractions of social networking and micro-blogging. They promise to restore some visibility to digital team work that we lost in the first generation of tools.

If visibility is, indeed, important to effective knowledge work what else would you recommend as ways to manage and increase the visibility of the intermediate and end products of knowledge work and the people-to-people interactions that take place in creating those products?

Review of Nicholas Carr’s latest book – The Shallows

The Shallows: What the Internet Is Doing to Our Brains, Carr, Nicholas

Nicholas Carr has a knack for framing provocative questions. In his latest book, he expands on an article he wrote for the Atlantic in 2008, "Is Google Making Us Stupid?" Provocative but unanswerable.

When I was a young consultant, I would frequently get my hand slapped for trying to "boil the ocean." Later, as a doctoral student, my advisors would hound me to narrow my research questions to something they judged feasible and I felt constricting. It doesn’t appear that Carr got comparably wise advice.

Carr’s thesis is that the Internet (more precisely the World Wide Web) represents

…an important juncture in our intellectual and cultural history, a moment of transition between two very different modes of thinking. What we’re trading away in return for the riches of the Net – and only a curmudgeon would refuse to see the riches – is what Karp calls "our old linear thought processes." Calm, focused, undistracted, the linear mind is being pushed aside by a new kind of mind that wants and needs to take in and dole out information in short, disjointed, often overlapping bursts – the fast the better…

For the last five centuries, ever since Gutenberg’s printing press make book reading a popular pursuit, the linear, literary mind has been at the center of art, science, and society. As supple as it is subtle, it’s been the imaginative mind of the Renaissance, the rational mind of the Enlightenment, the inventive mind of the Industrial Revolution, even the subversive mind of Modernism. It may soon be yesterday’s mind. (The Shallows, p.10)

There are two primary threads in Carr’s argument. First is a review of the development of writing, the codex book, literate culture, and reading. The second is a look at the plasticity of the human brain and recent research studies about how new technologies might be leading to changes in how we think. While I found both of these journeys interesting in their own right, Carr fails to persuade me that they make his case.

Literacy enables substantially more complex thought than was possible in the oral cultures that preceded the invention of writing. Carr is a bit too quick to dive into the development of literate culture without examining how it differs from oral cultures. He acknowledges the work of Walter Ong and his study of this transition in Orality and Literacy, but would have done better to stay with that transition for a while longer than he does.

As for the plasticity of the human brain, my take on Carr’s analysis and on other reports from the world of neuroscience is that the jury is still out and will be for some time to come. Most of this research suffers from the limitations of all rigorous research. The studies need to be narrowly enough construed to generate results that are publishable. Few, if any, of the researchers conducting these studies would ever make the leaps of generalization that Carr does to support his interpretations.

Carr writes exceptionally well, which actually presents a problem. There are several spots where he smoothly leaps from his evidence to conclusions that go far beyond the evidence into unsubstantiated speculation. If you aren’t reading carefully, you’ll find yourself lost in the poppies somewhere. Somehow, I don’t think Carr intended this as a test of my abilities to closely follow his arguments. But you can draw your own conclusions.


Enhanced by Zemanta

Reflections from the 2010 Enterprise 2.0 conference (#e2conf)

I’m just back from the Enterprise 2.0 conference in Boston. Fortunately, there were a number of bloggers more proficient than I at tweeting and reporting on the action as it happened. Bill Ives, Mary Abraham, and Patti Anklam all provided excellent blog posts, while the tweet stream at #e2conf was rich.

What follows are some reflections provoked by being simultaneously immersed in the virtual and physical experience. I expect all will be topics that I will return to here and with clients.

Enterprise social software platforms

The feature sets of the various social software platforms are now effectively identical and are also essentially mash-ups of Facebook, Twitter, WordPress, MediaWiki, and Documentum. The problem i have with this is that feature sets aren’t terribly relevant in whether enterprises will succeed in efforts to derive value from these platforms.

I’m reminded of something that my wife regularly finds extremely annoying. She’s a photographer and an excellent one at that. When people see her work, they always want to know what kind of camera she uses. What she’s taught me, of course, is that the equipment is largely irrelevant. What matters is the photographer’s eye for composition and for the moment.

We’re in a similar situation with enterprise social software and are still working out the relationship between tools and creators. At the moment that appears to mean a bit too much focus on tools and not enough on the creators and their practices. There was certainly a lot of talk about the importance of understanding and influencing behavior in the hallways. We actually know quite a bit about individual and group creativity; it’s time we spent more effort to integrate that knowledge into the user experience. I expect we’ll see some interesting collisions between technophiles and organizational designers.

From workflow and process to light weight coordination

The notions of business process and workflow that we’ve developed over the course of deploying ERP systems and other large-scale operational systems don’t translate well to the realm of knowledge work. Unfortunately, like the proverbial hammer, they are the only notions most have and the results are painful for those of us who don’t happen to be nails. Greg Lloyd of Traction Software has been using the term "light weight coordination" and his colleague Jordan Frank has been talking about Social Process Reengineering and has coined the term Emergineering, which is at least a provocation in the right direction.

The problem with process and workflow is that they lead you into trying to nail down with precision activities that only work with an appropriate degree of looseness. They also emphasize translating judgment calls into hard and fast business rules. The goal in enterprise 2.0 is not to extend process/workflow concepts to the ends of the enterprise. The goal is to offer a degree of transparency and appropriate support to the judgment calls that continue to exist.

I don’t think this issue is widely recognized yet, but I predict we will find our existing concepts about process and workflow are too inflexible and constraining to help with knowledge work arenas.

Making the case for Enterprise 2.0

What’s the ROI is still a perennial question. Not, however, a terribly useful one when framed in this seemingly business-like shorthand. ROI is a tiny piece of mathematical machinery at the tail end of a complex organizational process of allocating scarce resources.

Enterprise 2.0 is in much the same place we were in the in the early 1990s when organizations were debating the merits of email and local area network investments. Back then we talked about "stealth infrastructures" and about how to piggyback investments on top of big efforts that had the necessary organizational backing.

Resource allocation in organizations is a political, economic, and occasionally theatrical process. Better to acknowledge this from the outset than to continue the search for the perfect spreadsheet.

Unpacking organizational culture

Organizational culture was another shorthand term that was in frequent use last week. Organizational culture is an amalgam of which behaviors are celebrated, encouraged, tolerated, risky, and forbidden. It encompasses who has power and influence and who does not. It’s the stable patterns that emerge when you observe all the instances of individual behavior in the organization.

Organizational culture is not a variable that you manipulate. It sets the context within which the behaviors you would like to promote will be evaluated as desirable, undesirable, or neutral. Culture is malleable over time, but the change emerges from the accretion of new behaviors.