When should managers insert themselves into a messy situation

Bob Sutton’s Work Matters Blog continues to be one of my best sources of managerial insight. One of the challenges of managing is choosing whether and when to intervene in your organization (presuming that micro-management is not your goal). In this recent excellent post, Sutton offers the distinction between two classic acronyms as an excellent diagnostic question to help make that choice:

FUBAR, SNAFU, Fast Company, and Good Bosses – Bob Sutton:

Snafu — situation normal, all fucked-up

fubar — fucked-up beyond all recognition

One CEO I know, also the son of a World War II veteran, uses the distinction between the two to help decide whether a “mess” requires intervention, or it is best to leave people alone for awhile to let them work through it.

He asks his team, or the group  muddling through mess: “Is it a snafu or fubar situation? ” He finds this to be a useful diagnostic question because, if it is just usual normal level confusion, error, and angst that is endemic to uncertain and creative work, then it is best to leave people alone and let hem muddle forward.  But if it is fubar, so fucked-up that real incompetence is doing real damage, the group is completely frozen by fear, good people are leaving or suffering deeply, customers are fleeing, or enduring damage is being done to a company or brand — then it is time to intervene.

This is a really nice way to assess both a messy situation and the strength and skill of your management tea. I’m adding it to my repertoire.

Richard Feynman On The Folly Of Crafting Precise Definitions

I’ve often struggled with the notion of definitions when working in organizations. On the one hand, too many of us hide our ignorance and uncertainty behind a wall of jargon and terminology. Terms fall in and out of favor and their relationship to the underlying real world is often less important than their value from a marketing perspective.

On the other hand, new terms and language can help us point to and see new ideas and new opportunities for action. Here’s a recent post from Bob Sutton that sheds light on these challenges and is worth thinking about.

One of my best friends in graduate school was a former physics major named Larry Ford. When behavioral scientists started pushing for precise definitions of concepts like effectiveness and leadership, he would sometimes confuse them (even though Larry is a very precise thinker) by arguing “there is a negative relationship between precision and accuracy.” I just ran into a quote from the amazing Nobel winner Richard Feynman that makes a similar point in a lovely way:

We can’t define anything precisely. If we attempt to, we get into that paralysis of thought that comes to philosophers one saying to the other: “you don’t know what you are talking about!”. The second one says: “what do you mean by talking? What do you mean by you? What do you mean by know?

Feynman’s quote reminded me of the opening pages of the 1958 classic “Organizations” by James March (quite possibly the most prestigious living organizational theorist, and certainly, one of the most charming academics on the planet) and Herbert Simon (another Nobel winner). They open the book with a great quote that sometimes drives doctoral students and other scholars just crazy. They kick-off by saying:

“This is a book about a theory of formal organizations. It is easier, and probably more useful, to give examples of formal organizations than to define them.”

After listing a bunch of examples of organizations including the Red Cross and New York State Highway Department, they note in words that would have pleased Feynman:

“But for the present purposes we need not trouble ourselves with the precise boundaries to be drawn around an organization or the exact distinction between an “organization” and a “non-organization.” We are dealing with empirical phenomena, and the world has an uncomfortable way of not permitting itself to be fitted into clean classifications.”

I must report, however, that for the second edition of the book, published over 20 years later, the authors elected to insert a short definition in the introduction:

“Organizations are systems of coordinated action among individuals and groups whose preferences, information, interests, or knowledge differ.”

When I read this, I find myself doing what Feynman complained about. I think of things they left out: What about norms? What about emotions? I think of situations where it might not apply: Doesn’t a business owned and operated by one person count as an organization? I think of the possible overemphasis on differences: What about all the times and ways that people and groups in organizations have similar preferences, information, interests, and knowledge? Isn’t that part of what an organization is as well? I could go on and on.

I actually think it is a pretty good definition, but my bias is still that I like original approach, as they did such a nice job of arguing, essentially, that if they tried to get more precise, they would sacrifice accuracy. Nonetheless, I confess that I still love trying to define things and believe that trying to do so can help clarifying your thinking. You could argue that while the outcome, in the end, will always be flawed and imprecise, the process is usually helpful and there are many times when it is useful pretend that you have a precise and accurate definition even if you don’t (such as when you are developing metrics). “

Richard Feynman On The Folly Of Crafting Precise Definitions – Bob Sutton:

Euan Semple on nurturing a knowledge ecology

This gem from Euan Semple made the rounds earlier this summer. I was too busy then to do more than note it.

Ten ways to create a knowledge ecology

TUESDAY, JUNE 28, 2011 AT 7:08AM

A tweet yesterday prompted me to remember sage advice from Dave Snowden which I took to heart in my work with social tools at the BBC. “You can’t manage knowledge but you can create a knowledge ecology”. I thought it might be useful to others to list the ten most important things I learned about doing this.

1, Have a variety of tools rather than a single system. Not everyone sees the world the same way or has the same needs so mixing up different tools with different strengths allows people to find one that works for them. Avoid single platforms like the plague.

2. Don’t have a clear idea where you are headed. The more fixed you are in your aspirations for your ecology the less likely you are to achieve them. Be prepared to go where people’s use of the tools takes you and enjoy the ride.

3. Follow the energy. Watch where the energy in the system is and try to copy the factors that generated it. Get others interested in why energy emerges and they will want some of it themselves.

4. Be strategically tactical. You can have an overall strategy of behaving in certain ways depending on how your ecology develops. It is possible to sell this as a strategy to those who need strategies.

5. Keep moving, stay in touch, and head for the high ground. Keep doing things, keep talking about what you are doing and why, and have a rough idea of where the high ground is.

6. Build networks of people who care. Don’t try to manage your ecology by committee but cultivate communication and trust between those who care that it works and have the commitment to do something about it – whoever they are and whatever their role.

7. Be obsessively interested. Notice everything that happens and consider why. Tell great stories about what you are observing.

8. Use the tools to manage the tools. Blog about what is going on with your corporate blogging, ask questions in your forum about security, tweet when something is changing in your ecology and ask people why it is interesting.

9. Laugh when things go wrong. If you are pushing limits and exploring new territory things will occasionally blow up in your face. Having a sense of humour and enjoyment of the absurd will help you stay sane.

10. Unleash Trojan Mice. Don’t do big things or spend loads of money. Set small, nimble things running and see where they head.

(– The Obvious? – Ten ways to create a knowledge ecology)

The paradox of organic approaches to change is that while they appear to be simple and mundane, they also appear to be the only thing that works with any regularity in complex situations. For all the rhetoric of bold plans and audacious goals, the reality is that most change occurs inch-by-inch.

Where IS Health Care Going? Technology Leader’s Presentation

Last week, JoAnn Becker  and I ran an interactive discussion with the monthly TLA Manager’s breakfast meeting here in Chicago. We had a lively and excellent debate among a group of technology executives, health care executives, and other smart people about the real challenges of successfully deploying information technology to improve productivity and quality in delivering health care in this country.

That, of course, is an immense issue and would could barely scratch the surface in the hour we had. For those who are interested, we’ve uploaded our slides to Slideshare.


We used two recent TV ads from GE and IBM to kick off the discussion. On the surface, each provides a sense for the promise of information technology to make health care more effective:

GE TV ad – Doctors
IBM TV Ad – “Data Baby”

In the tradition of all good technology vendor advertising, both also completely gloss over the complex organizational adaptation and evolution necessary to bring these hypothetical worlds into being. They also gloss over the existing institutional and industry complexity that needs to be understood and addressed through a combination of design, leadership, and management.

Fred  Brooks, professor of computer science at UNC and author of The Mythical Man-Month : Essays on Software Engineering, draws a critical distinction in the final chapter of the book, which is titled "No Silver Bullet," between accidental and essential complexity. His point is that software is so difficult to design and develop because it must successfully model the essential complexity of the domain it addresses. Technology and software efforts can stumble on a variety of barriers and roadblocks, but failing to understand and address essential complexity is the worst.

Health care provides its own mix of accidental and essential complexity. If the decision makers aren’t careful to draw distinctions between accidental and essential, then a great deal of time and effort will be expended without corresponding returns. On the one hand, we may simply succeed in "speeding up the mess" as my friend Benn Konsynski so liked to put it. Or, we may obliterate  essential complexities in a quest for uniformity and productivity that is blind to those complexities. Or, finally, we may invest the appropriate level of design time and talent in systems that account for essential complexity and eliminate accidental complexity.


We drew on a variety of excellent resources in preparing for this talk and wanted to make them more easily available here.

Here are several books that provide useful context and background

Here are pointers to a variety of health care related web resources worth paying attention to:

How better thinking about deliverables leads to better knowledge work results

Deliverables should be a knowledge worker’s best friend but, like all good friendships, the relationship can get complicated. One of the most direct ways to improve the quality of knowledge work is to spend more time and effort to define appropriate deliverables.

My faith in deliverables has grown out of decades of practical consulting experience, where defining the appropriate deliverable can mean the difference between mediocrity and success. A deliverable is an identifiable work product intended for someone outside the knowledge work process that marks the end of that particular process. Examples of deliverables include:

  • A consulting report prepared by the consultant or consulting team containing recommendations to the client sponsor.
  • A list of recommended job offers to prospective employees prepared by a campus recruiting team and handed to the hiring manager.
  • Production Release 1.0 of a new application system installed and operating on the companies intranet.
  • A project work plan and business case delivered to a steering committee for approval.

Why Deliverables Are Relevant

In the world of industrial work, process outputs are well-defined. This gives organizations a straightforward process improvement path. Holding the outputs constant allows process improvement to proceed by identifying and eliminating activities that don’t add value to the output; to break down, reorder, and redesign process steps to create more standard outputs with less input; and so on.

This path isn’t available to knowledge work practices. The goal is not to produce well-defined, standardized outputs. Deliverables are the closest analogue but their value depends on how well they match the unique needs of their users. No one is interested in a spreadsheet full of someone else’s data; no teacher is likely to value a copy of a paper you’ve submitted to another class. Understanding what aspects and features of a knowledge work deliverable are most valuable to its intended user is key to focusing efforts on producing the desired deliverable.

Natural vs. Artificial Deliverables

Some knowledge work processes produce obvious and natural deliverables. A campus recruiting effort generates a list of candidates to extend offers to. There may be a variety of associated supporting documents (e.g., interview notes, assessments), but the list is the deliverable and is a natural outgrowth of the process.

Other knowledge work processes generate more amorphous or less obvious outputs. For example, what’s the deliverable for a typical project status meeting? Shared understanding among the project team? Agreement about the state of the project between the team and the project sponsor?

Consider the typical status report as a more artificial than natural deliverable and ask how much value resides in this particular item. If you can define the deliverable more effectively, is the world a better place?

Defining Better Deliverables

The better we can define deliverables, the better and more effective we can make our knowledge work. Rather than ignore the end product, we need to be systematic in extracting as much as we can about the expected deliverable that can guide our effort to create it. There are three productive paths to explore in using the deliverable to drive your knowledge work.

  • Path #1: Understand the user’s essential quality need

    Does this deliverable need to be exactly correct whatever the time or cost, as good as possible given a particular deadline/budget, or the best you can come up with on the phone? Each deliverable demands a different approach; each requires a conversation (and perhaps a negotiation) with the end user. The history of systems development is littered with examples of failing to follow this path.

  • Path #2: Balance uniqueness and uniformity

    We’ve been conditioned by one hundred years of industrial experience to value uniformity. In knowledge work, the value of uniformity is to free time and attention for the essential uniqueness we’ve defined. The folks in marketing may believe that corporate identify standards are about branding. For a knowledge worker, they let you ignore formatting decisions to focus on the content that matters.

  • Path #3: Specify stopping conditions

    There was an joke that was old even in my early consulting days that you knew the design phase was complete when the budget ran out. Possibly the biggest challenge for managing knowledge work is determining how to recognize that the deliverable is done. Think of the unfinished doctoral dissertations and manuscripts of the great American novel gathering dust on a shelf or lost in a lonely directory of a disk drive. Too many knowledge-work efforts fail simply because no one thinks about how to recognize what "done" will look like.

Focusing on deliverables means working backwards with the end in mind. Knowledge work is valuable to the extent that it produces end results, i.e. deliverables, that meet the unique requirements of a particular customer or end user. Time invested in understanding what that deliverable should look like will yield the greatest return in defining and focusing the activities that contribute to creating that particular deliverable at the right time and place.

Review of Bob Sutton’s "Good Boss, Bad Boss"

Good Boss, Bad Boss: How to Be the Best… and Learn from the Worst, Sutton, Robert I.

I’m becoming a fanboy of Bob Sutton, an engineering professor at Stanford who co-founded the d.school there. It started when i read The Knowing-Doing Gap : How Smart Companies Turn Knowledge into Action, which he co-authored with organizational theory icon Jeff Pfeffer. In 2007, he wrote The No Asshole Rule, which became a NY Times bestseller and was judged among the best business books in 2007. In between, he’s written a variety of books and articles, and an excellent blog, Work Matters, on management and organizational issues in today’s economy. Bob was kind enough to send me an advance copy of his newest book, Good Boss, Bad Boss, which is due to hit shelves early next month.

In Good Boss, Bad Boss, Sutton turns his attention and preference for evidence-based insights to the "authority figure that has direct and frequent contact with subordinates–and who is responsible for personally directing and evaluating their work." The quality of your boss, or your own quality as a boss, makes a huge difference in both the quality of work that gets done and the quality of the working environment. We all want to work for good bosses, presumably most of us aspire to be good bosses as well. Sutton adroitly mixes the substantial body of empirical evidence differentiating good bosses from bad bosses with effective stories and cases. He makes a case that it is possible to  become a better boss for those who wish to make the effort. Substantial and continuing effort, to be sure, but possible.

Sutton does have one core bias, a bias that I share. In his view, "bosses ought to be judged by what they and their people get done, and by how their followers feel along the way." The heart of the book is a series of chapters reviewing what the best bosses do. The chapter titles offer a good clue to both their content and Sutton’s perspective:

  • Take Control
  • Strive to be Wise
  • Stars and Rotten Apples
  • Link Talk and Action
  • Serve as a Human Shield
  • Don’t Shirk from the Dirty Work
  • Squelch Your Inner Bosshole

Obviously, no book on its own is going to make anyone a better boss. Becoming a better boss, like any skill, is a matter of good practice and good feedback. What Sutton offers in Good Boss, Bad Boss is a well organized and well justified collection of practices and ways to sense how well those practices are working. I found myself dog-earring pages, scribbling notes in the margins, and picking up new tidbits each time I went through the book. It reads smoothly and easily; yet it’s also densely packed with insights and actionable advice. As one example, let me share Sutton’s

11 Commandments for Wise Bosses

1. Have strong opinions and weakly held beliefs
2. Do not treat others as if they are idiots
3. Listen attentively to your people; don’t jut pretend to hear what they say
4. Ask a lot of good questions
5. Ask others for help and gratefully accept their assistance
6. Do not hesitate to say, "i don’t know."
7. Forgive people when they fail, remember the lessons, and teach them to everyone
8. Fight as if you are right, and listen as if you are wrong
9. Do not hold grudges after losing an argument. Instead, help the victors implement their ideas with all your might
10. Know your foibles and flaws, and work with people who correct and compensate for your weaknesses
11. Express gratitude to your people

Spiderman may offer the best summary of this book -  "with great power comes great responsibility." Good or bad, bosses are always on stage; their every move and utterance scrutinized. Being a good boss requires self-knowledge and self-awareness to an extraordinary degree. It also requires a keen sense for balance and for timing.

Other books by Bob Sutton


Enhanced by Zemanta

Review: Clay Shirky and Cognitive Surplus

Cognitive Surplus: Creativity and Generosity in a Connected Age, Shirky, Clay

Anyone who can use lolcats to make a relevant and provocative intellectual point is worth paying attention to. Clay Shirky pulls it off in his latest book. Here’s his point:

Let’s nominate the process of making a lolcat as the stupidest possible creative act…. The stupidest possible creative act is still a creative act. [p.18]

Cognitive Surplus is a follow on to Shirky’s previous book, Here Comes Everybody: The Power of Organizing Without Organizations. In it, he explores the following thesis:

Imagine treating the free time of the world’s educated citizenry as an aggregate, a kind of cognitive surplus. How big would the surplus be? To figure it out, we need a unit of measurement, so let’s start with Wikipedia. Suppose we consider the total amount of time people have spent on it as a kind of unit – every edit made to every article, and every argument about those edits, for every language that Wikipedia exists it. That would represent something like one hundred million hours of human thought….One hundred million hours of cumulative thought is obviously a lot. How much is it, though compared to the amount of time we spend watching television?

Americans watch roughly two hundred billion hours of TV every year. That represents about two thousand Wikipedias’ projects’ worth of free time annually….One thing that makes the current age remarkable is that we can now treat free time as a general social asset that can be harnessed for large, communally created projects, rather than as a set of of individual minutes to be whiled away one person at a time. [pp.9-10]

Shirky takes this notion and uses it as a lever to pry beneath the surface of lolcats, the Apache project, PatientsLikeMe.com, and other examples to look for something beyond the obvious. What makes it work is Shirky’s willingness to stay in the questions long enough to see and articulate deeper linkages and possible root causes.

One of the things that makes this work is that Shirky understands technology well enough to distinguish between accidental and essential features of the technology (to borrow a notion from Fred Brooks). Where this ultimately leads him is away from technology to look deeper into human behavior and motivation.

Like everyone else who’s been paying attention, Shirky turns to the wealth of insights coming out of the broad area of behavioral economics to understand why so much of the what is apparently surprising about today’s technology environment rests in our crappy assumptions about human behavior. As he argues in a chapter titled "Opportunity" when we find new technology leading to uses that are "surprising," the surprise is located in an assumption about behavior and motivation rooted in an accident of history not a fundamental attribute of the human animal. For example, he neatly skewers both the RIAA’s and the techno-utopians analyses of Napster and concludes:

The rise of music sharing isn’t a social calamity involving general lawlessness; nor is it the dawn of a new age of human kindness. It’s just new opportunities linked to old motives via the right incentives. When you get that right, you can change the way people interact with one another in fairly fundamental ways, and you can shape people’s behavior around things as simple as sharing music and as complex as civic engagement. [p.126]

For those of you who prefer your arguments condensed for more rapid consumption, Shirky provides one in the following TED talk

Shirky has his detractors. There are those who dismiss him as just another techno-utopian who imagines a world at odds with the practical realities of the day. At the level of a 20 minute keynote speech, that’s not an unwarranted takeaway. When you give his arguments a deeper reading, I think you’ll more likely to conclude they are worth your investment in wrapping your head around them.

Related articles by Zemanta

Enhanced by Zemanta

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.