Questions about questions

One of my professors, Warren McFarlan, made an observation about the choice of questions that has stuck with me. He argued that you could either ask questions that would get you published or you could ask questions that mattered.

He might have been a bit more diplomatic in his phrasing but that was the essence. Were you going to be driven by safety or by curiosity?

Most of education and society drives our questions to safety. We learn which questions lead to the answers that our teachers and managers are looking for. “Will this be on the test?” is the default question. The ways we suppress curiosity while pretending to encourage it are limitless.

I had a classmate in business school who liked to chat with our professors after class, which earned him a reputation as a brown noser. The notion that you might be genuinely curious about the subject was a foreign concept to most of our classmates. I got to know Phil as the year went on and discovered that he already had a Ph.D. in the History and Philosophy of Science. I may have been the only one in our section that he revealed this to; he believed, rightly I suspect, that this would only brand him further.

Curiosity is a dangerous value; it has killed more than cats. Suppose you also believe it is important regardless of the risks. How do you encourage, promote, and nourish real curiosity in environments that fear and suppress it?

How do you learn to ask questions that matter?

I’m making a claim here that I’ve avoided this problem and navigated the system with my curiosity intact. How did I manage that? More importantly, are there any lessons to learn?

School was a place where most things came pretty easy. But the culture still rewarded right answers and compliant behavior. As I listen to others tell tales of the pressures to achieve they faced from parents and teachers, they strike me as foreign. I was certainly praised when I did well, but I never felt pressured. My mom was always a believer. She was pleased with my results. But, she never talked about expectations. I imagine that with my six younger siblings to wrangle she was mostly relieved that I was operating on my own.

Looking back, my dad was pretty tricky. It was never “were you the best?” The question was “does this represent your best work?” If the answer was yes, the actual grade was immaterial; if the answer was no, then an A was no defense. That got me through high school and by the time I reached college I was comfortable chasing my interests instead of grades. I took courses based on my interests at the time, not based on my grade point average. As I often tell my students today, I managed to collect at least one of every possible grade.

Grades served as feedback, not measures of my value.

My work in the theater taught a second important lesson. Working on stage productions was always about scarce resources and hard deadlines. You can generally negotiate an extension on a class assignment; you can’t move opening night. On a show, the question is always “does this make what the audience sees better?” That leads to a second question, “if the audience can’t see it, why are you doing it?” There’s no good reason to paint the back side of a set.

The question is not about effort; it’s about value. We track effort because we can’t always wait to measure value; effort can be an appropriate early warning signal. Demanding maximum effort is a lazy manager’s way to avoid thinking about the value you are seeking to create.

The old adage is “if something is worth doing, it’s worth doing well.” I encountered an improved version on the bulletin board of a doctor friend:

If something is worth doing, it’s worth doing well enough for the purpose at hand. It is probably wrong, and certainly foolish, to do it any better.”

Throwing resources at problems is rarely an effective strategy despite the frequency with which it is employed. Acceptable as a strategy if you are resource rich, questionable if the problems and opportunities exceed the resources available. Getting the most leverage out of resources starts with learning how to ask better questions.

Dangerous magic–casting technology spells without understanding

I just gobbled up Charles Stross’s The Labyrinth Index, which is the 9th book in his Laundry Files series. The series is the hybrid that might result if you threw Ian Fleming’s, Robert Heinlein’s, and H.P. Lovecraft’s fiction into a blender. I love it; your mileage may vary.

The underlying premise of the series is that computation and applied mathematics is magic. Not magic in a metaphorical sense; real magic that can unleash demons and eat souls. The Laundry is secret British organization that tries to keep the average computer science student or random hacker from accidentally destroying the universe.

In my last post I talked about understanding the magic in technology. I remain puzzled by people who are content to not understand, who are content to accept something as mysterious and get on with it. As we continue to build and deploy technology we are putting magic in the hands of many who can inadvertently wreak havoc.

More often than not, they inflict harm only on themselves. But that is small comfort. Consider the example of the Morris Worm that crippled the early Internet because of a programming error that turned an unwise experiment into a catastrophe.

Clarke’s Third Law posits that “any sufficiently advanced technology is indistinguishable from magic.” Gregory Benford, another science fiction author suggested the variation, “any technology distinguishable from magic is insufficiently advanced.”

Those who market technology are fond of promising magic. Too many individuals and organizations treat that claim as operational guidance rather than puffery. Stross offers a reminder that we do so at significant risk. The answer lies not in further insulating people from the technology they employ, but in working to reduce the magic factor. We have to get better at making the technology beneath the magic accessible and understandable.

Understanding and explaining the magic

Skokie Benefit Rehearsal 2003The place where technology, organizations, and people come together has been a continuing focus of my work. That interest was birthed in stories of the wonders and dangers of fantastic new inventions. Like a lot of future scientists and engineers I was raised on the stories of Isaac Asimov, Arthur C . Clarke, and Robert Heinlein.

Somewhere in my early, unsupervised, reading I encountered Arthur C. Clarke’s “Profiles of the Future,” long before I was mature enough to grasp much of it. I’ve since returned to it multiple times over the years. One thing stuck from the earliest, Clarke’s Third Law:

Any sufficiently advanced technology is indistinguishable from magic

That notion gestated in the back of my mind as two strands played out. First, I encountered and learned about technology in multiple manifestations; mathematics, physics, carpentry, programming, electricity.

Second, I created magic in the form of live theater. Group effort focused on creating illusions that touched the heart observed from a spot where all the illusion was exposed. It’s an odd experience to watch a singer bring an audience to tears while listening for the key change that is the cue to dim the lights and adjust their color; all of which reinforces her voice  and triggers those tears night after night.

Where this has taken me is showing people that the magic is understandable. Revealing the technology that creates the magic gives people power to create their own magic and power lets you solve problems.

There is a moral question of whether you hoard or distribute power. I land on the distributing side; the problems we face need all the power we can collectively muster. Hoarding crimps the flow of total power we need.

You transform magic into technology in stages. The first is to shift perspective and take people behind the scenes. That involves telling the story twice; once from the magic side and again from the technology side. Next, you break down the experience into its component parts and reveal the seams. Finally, you help people learn to create and assemble their own designed experiences.

The venue for this transformation can take multiple forms. It can be as simple as a telling of the tale from the right perspective. Or, it can be a guided tour. With enough time and resources, the best choice can be a “build your own” experience with a veteran guide at your side.

Building tiny bridges

Rope BridgeThe short version of the story I tell about why I decided to leave work to get a Ph.D. is that I needed to figure out why those stupid users weren’t taking advantage of the clever systems I was designing. That turns out to be a midpoint in a longer thread of trying to bridge two worlds that should be one.

The tagline for my blog is a quote from Dorothy Parker: “the cure for boredom is curiosity, there is no cure for curiosity.” In business, curiosity is acceptable only up to a point. You can be curious about the specific things you need to learn to tackle your next well-defined goal; free-floating curiosity is suspect.

Today, we are likely to label free-floating curiosity as attention deficit disorder and bring it under control. ADD is a problem of poor executive control, which implies that curiosity must be subordinate to focus.

I was fortunate to grow up in a time before we had ADD as an explanation for certain behaviors. I also had enough natural talent for school-like activities that my curiosity was nurtured and encouraged rather than constrained.

Sometime around the second grade I had my first collision between instinct and the conformity that most schools and teachers preferred. It was a Catholic school and I posed a problem for the nuns; I was clever but, as an eldest child, generally well-behaved. One morning, my teacher—a nun whose name is long lost to me—discovered that the workbook I was supposed to be maintaining for the last several weeks was empty. Who knows what I had been doing instead.

I was dispatched to the principal’s classroom with the empty workbook as evidence of my failure. The principal taught 8th grade students so my arrival provoked their amusement and my humiliation as intended. Knuckles rapped with the principal’s yardstick, I returned to my classroom. I was sent home at the end of the day with the empty workbook so that my mother would also know of my dissolute ways.

I don’t recall Mom being terribly upset. What I do recall is that I did the exercises I had neglected and completed the rest of the workbook that night as well. I returned the finished workbook the next morning.

Here’s where I got lucky. My teacher then and those who followed encouraged me to discover what else I could accomplish rather than force me to conform. None of them imposed their agenda or expectations. Once I got the work at hand done, I was free to explore whatever caught my attention. Their gift was to help me discover that learning was about questions not answers and, then, how to ask questions safely rather than ask safe questions.

In an alternate timeline, I might have gone strictly down the math and science path. I was certainly curious about things that were logical—puzzles that had answers, things that made sense. But, not only was I a Catholic in those days, I was catholic in my interests. I was equally interested in things that didn’t make sense to me. It turns out, of course, that many things don’t make sense in the way that mathematics and science make sense.

In my early years, I wasn’t well equipped to distinguish between what didn’t make sense because of my ignorance, what didn’t make sense because of its inherent complexity, and what didn’t make sense because of my limitations rather than my knowledge. I didn’t even have those buckets to work with.

Among the things that made less sense to me were people, especially in groups and organizations. I understood classrooms, I didn’t understand recess.

My intuitions about the logical, systemic, and structured world developed and improved pretty robustly. My intuitions about the human world were weaker and slower to develop.

One choice would have been to stay within the bounds of the logical. But my innate curiosity kept pushing me to make sense of all of my environment.

There’s a long-running split between the human and the systemic. C.P. Snow called it “The Two Cultures” back in 1959. Working that gap has been the place that suits me, although I prefer to work it at a more detailed level than Snow. Recognizing a big problem doesn’t yield a big solution. It calls for building bridges one piece at a time.

Learning and knowledge management in start up mode

 Becoming a founder of Diamond Technology Partners in 1994 was a textbook example of leveraging your network. In late 1993 I was ready for something new. I had published my first book and sent a copy to a former boss and mentor with a note that I would like to use his name as a reference as I started to look for that next new thing. Our phone rang early on a Saturday morning in October—this was when phones were still attached to walls. My wife answered and handed the phone to me.

It was Mel. He had read the book the night before after traveling all week. He quickly came to the point. We needed to meet as soon as we could synchronize our travel schedules. I could not use his name as a reference.

Within the week we were seated in a conference room at the Admiral’s Club at LaGuardia Airport. Mel shared one of the very first copies of the Diamond business plan. The plan included a projected organization chart with a box labeled “Chief Knowledge Officer/Chief Learning Officer.” The only job Mel was prepared to help me land was to figure out how to make that box work.

Three months later I began commuting from Boston to Chicago. By June my wife and two young boys were in a new house on the North Shore of Chicago trying to make new friends while I tried to figure out what that box might mean.

Putting knowledge management and learning on our to do list demonstrated no special insight; these were issues that all professional services organizations were tackling. Professional services firms live off their accumulating knowledge and their ability to disseminate that knowledge across the organization. Knowledge management and learning are core requirements.

Drawing different maps

What was less clear at the time, to me at any rate, was that the lessons from established firms could not simply be transplanted. The issues and problems they faced were problems of maturity; their solutions addressed their problems. We had to work out how our problems were different before we could begin to design appropriate solutions.

I think of this as drawing different maps because it reminds me that we were in different territory. That wasn’t immediately obvious. We had all come from established firms and had limited experience in start up environments. It was tempting and comforting to view our challenges as simply matters of resources and scale.

The limited resources of being a start up turned out to be an advantage. We had combined knowledge management and learning in one box on the organization chart because we didn’t have two people to warrant two boxes.

We did not have a “Diamond” way of working. We were actively creating one out of the McKinsey/Accenture/Booz/Bain/Ernst&Young/IBM/LEK ways we drew on from our collective experience. Our clients worked with us because they had problems that didn’t fit any of those established ways.

There’s the business you plan and there’s the business the market tells you that you are in – you had better learn to listen to the market. Rather than match problems to the solutions we understood from experience, we let the features of problems shape our approaches. Our learning and knowledge problems were tightly coupled.

Our knowledge management problem was not about how to codify and scale our work so that it could be reliably distributed. It was to push on the boundaries of what we knew to make room for more new ideas. Our fundamental knowledge management problem was how to extract and organize insights from the innovation that was taking place. Our problem wasn’t so much knowledge management as it was knowledge creation.

We had to learn how to draw the maps we needed as we went further into the wilderness. Our problem was more like being part of a research team collectively trying to figure out what we were seeing, what it meant, and what to do about it.

Expanding the learning problem

With the market pushing the entire organization to create new ways to work, the scope of our learning needs expanded. Who had to learn, what they had to learn, and how they had to learn it all changed.

In established firms, the primary learning problem is to equip younger staff with the skills and expertise of their elders. For us, everyone had to deal with learning as both learner and teacher. Junior staff came wanting and expecting to learn; not all senior staff shared that mindset.

We also had to reduce the lag between knowledge creation where we learned something for the first time to sharing that learning with everyone else who could take advantage of it. In more stable environments, knowledge creation could be followed by investments in codification and confirmation. In our environment, we were happy if there were a handful of relevant examples from prior work that could help us shape what to do next.

Circumstance forced us not only into learning by doing but often learning while doing. There’s a rich base of knowledge backing the case for the power of learning by doing. We had the good fortune to be able to tap the insights of two of the leading thinkers in this area—Roger Schank and Alan Kay.

You can incorporate doing into almost any learning situation. Learning while doing turned out to be a bit trickier. Thinking in terms of how to better support reflective practice is one element. Building After Action Reviews into our projects was another.

We also deliberately blurred the lines between learning and practice. In our presentation skills class for new hires, rather than craft exercises we polled the field for research tasks and assigned those to students. If, for example, we needed to gather intelligence on a prospective client that became an assignment for a team in the course. Further, we brought in experienced staff from the field to evaluate and judge the quality of the research and the quality of the presentations.

The success of these experiments encouraged us to knock down more of the barriers between the field and learning/knowledge management. We brought experts back from the field to serve as instructors. We asked those same experts to ground the courses in their current client experiences.

What makes all of this matter beyond the challenges of one start up is that more of today’s organizations face similar problems of external environments that change too quickly to be captured in the knowledge management and learning practices of more mature organizations. We have all become start ups and our practices need to adapt to remain relevant.

McGee’s Musings turns 17

The experiment continues. The first post here came in 2001. This post is somewhere north of 1500. The number is inexact because portions of the earliest postings here aren’t easily tracked down.

The past year has seen a bit of a reboot here in terms of posting frequency., For those of you who’ve been following along, what would you like to see more of? What would you like to see less of?

Review: Planning for Everything: The Design of Paths and Goals

Planning is Everything Planning for Everything: The Design of Paths and Goals. Peter Morville

Conversations about project management often invoke Dwight Eisenhower’s dictum that “plans are useless, planning is essential.” We’re agreed that it is the process that matters. Peter Morville’s Planning for Everything offers an extended and illuminating reflection on the nature of that process.

It’s an effective interweaving of vignettes and case examples illustrating how planning principles and practices play out. That actually makes it more actionable and adaptable than generalities or detailed processes and checklists. It certainly doesn’t hurt that Morville is an excellent writer.

The title captures a perspective on planning that squares with where my thinking has been evolving – that effective planning is more about design than about execution and that the design process revolves around the interaction between paths and goals.

The book is organized around six central chapters:

  • Framing
  • Imagining
  • Narrowing
  • Deciding
  • Executing
  • Reflecting

that lay out the essence of planning processes. These chapters are bracketed by chapters stepping back to adopt a wider perspective; some may find those a bit too removed from the pragmatic, don’t let that stop you from working through the core.

There are nuggets of insight throughout the book. I’ve recently been teaching courses on project management and requirements analysis; the combination is triggering thinking about the conflicts between agile approaches and management needs for predictability and control. Morville observes “since no amount of subsequent planning can solve a problem insufficiently understood, problem framing is the most important step in planning.” That reminds me that you can only plan as far ahead as you understand. The debate shouldn’t be about agile or waterfall or scrum; it needs to be about how to generate the best understanding of the problem at hand. Not a stunning insight but something that is too easily forgotten.

This is a book worth re-reading, or at least taking a pass through, whenever you face a significant planning task.

Managerial alternatives to leaving smart people alone

I’ve often quoted Tom Davenport’s observation that the default HR strategy for knowledge-intensive organizations is to “hire smart people and leave them alone.” While there’s wisdom in that perspective, I fear it is no longer a desirable strategy.

I once had the office next door to Tom’s when we both worked at the Center for Information Technology and Strategy in Boston. The Center was an experiment by Ernst & Young to build better connections between academic research and business practice. It was an embodiment of Tom’s observation, grounded in our experiences in organizations that had pursued other approaches.

What does it mean to “leave them alone?” People don’t become managers to leave things alone. Managers set direction, they marshall resources, they evaluate and interpret results. Why should smart people be exempt from these eminently sensible actions?

They’re not.

But managers of smart people often aren’t qualified to do these essential management tasks. Setting direction, marshaling resources, and evaluating results depend on understanding practice. This is where managers struggle. In a world of manual tasks and procedural paperwork, managers could be expected to have a good grasp of how the work was and should be done. Managers understood practice. Thus, they were qualified to manage it.

We no longer live in that world.

In a world of knowledge work, it is knowledge workers—the smart people—who best understand practice. In this world, Tom’s strategy is a safe and responsible one; if you don’t know how to do what you manage, you’re well advised to resist the urge to meddle.

“First, do no harm” is commendable but not the same advice as “do nothing.” Setting direction, marshaling resources, and evaluating results depend on understanding practice. But understanding practice tells us nothing about whether that practice is advancing the goals of the organization. Practice is anchored in where we are; we also need to know where we would like to go.

Blending these perspectives implies that managing smart people requires a collaborative effort. Smart people provide sense-making of where we have been. Managers provide insights on desirable places to go. Smart people and managers jointly develop the maps and plans that connect the two.

It is not yet clear to me how this collaboration should play out in practice.

Smart people must be able to articulate what they do for those who can’t be expected to know as much as the smart people do about their domains. This places a responsibility on smart people to be able to educate others—particularly managers—about the point and promise of their expertise. Smart people who can’t, or won’t, explain how their expertise matters do a disservice to their organizations.

When smart people were a rare phenomenon in organizations, smart people and pretenders could both get away with jargon and faux-complexity. The numbers were small enough that a few wise gatekeepers could contain the downside risk and the upside of actual smart ideas was worth the trouble.

There’s an old, likely apocryphal, story told of Tom Watson in the early days of IBM. Seems an engineer had made a 10 million dollar design mistake. When asked why the engineer hadn’t been fired, Watson’s response was “I spent too much money learning from that mistake to get rid of the one person who won’t make it again.”

The calculus changes when smart people represent a significant proportion of your work force. For one, tolerating a single 10 million dollar mistake is reasonable; managing a hundred simultaneous potential mistakes—and upsides—becomes an existential problem. There is too much chance to leave the process to chance.

The organization needs a view into the mix of potential smart ideas. Further, the organization needs to actively shape the mix to align with the goals of the organization. This becomes a conversation about “command intent” and how that interacts with “ground truth.”

Leaving smart people alone makes sense when the alternative is to give orders that are ignorant of context and possibility. Far better to combine the perspectives of smart people and forward-looking managers and increase the smarts applied.

Creating your knowledge workshop


Electronics workshpoVendors and too many managers continue to promote and search for the One True Tool. This is a clear indicator that someone is trapped in an industrial mindset irrelevant to the actual world of knowledge work that we inhabit. If your work can be accomplished with one tool, then you are little different from or better off than the average wrench-turner on an assembly line. You are a replaceable component in a rigid system.

To build a body of work as a knowledge workers you need at least a well-equipped toolkit; ideally you will learn to operate within a proper knowledge workshop.

For simple projects, Swiss Army knives and Leatherman Tools are the answer. No one serious about their craft works with a single tool. Good craftspeople depend on a collection of tools that work together and co-exist in a workshop where they can be found and used as tasks require.

We are at a point in carrying out knowledge work where we would be well-advised to set aside the quest for the one true tool and turn toward the problem of creating and equipping a knowledge workshop suited to our needs.

What makes a workshop?

A workshop is

  • a collection of tools, each suited to particular tasks and projects. Some tools are old, some new; some are general purpose, some specialized; some are used every day, others less frequently
  • organized and arranged so the right tool is available whenever needed.
  • containing an inventory of common parts and useful raw materials already assembled just in case.
  • and a scrap bin full of fragments and discards sitting in the corner. These are handy to test new tools or to create quick jigs and fixtures that might be helpful in constructing a final product.

These typical features of physical workshops offer guidance about how to create a knowledge workshop suited to our needs.

For a few specialized forms of knowledge work, the nature of a knowledge workshop is already reasonably well understood. Software developers have rich choices for their development environments. Bond traders and other investment specialists can have very sophisticated custom work environments built and maintained in the quest for a few more basis points.

Those of us doing more general knowledge work need a strategy for getting from concept to the creation of our own knowledge workshop. That plan consists of three phases; setting the workshop up, learning to use it effectively, and dealing with the roadblocks that a craft-centered strategy will inevitably provoke in the typical organization.

Setting Up

The exact details of setting up a knowledge workshop will vary by the particular form of knowledge work you do. Are you extracting insight from numbers? Are you designing new organizations? Are you writing research reports? The specific form your knowledge work takes will guide you to the particular tools relevant to the deliverables you create.

There are some general guidelines that apply regardless of the specific area of knowledge work. First, you are building a workshop, not searching for the perfect tool. Pay attention to whether tools you are considering play nicely with one another. Second, be conscious of how the tool mix is developing. Is there a balance between big tools and little specialty tools? Do the specialty tools bridge the gaps between what the big tools handle? Do the specialty tools get used often enough to be worth keeping, or do they exact greater demands on your memory than they return in improved effectiveness?

While selecting, assembling, and (eventually) integrating a random collection of tools into something more useful, consider how you will assemble relevant supporting materials. If you are a wordsmith, do you want an online dictionary available? Do you want more than one? If you perform market analysis, are there general statistical tables or reports that you draw on repeatedly (e.g., the Statistical Abstract of the United States)? Are the tools and materials arranged and organized to make your work easier, or are they a long list of random entries or icons on your desktop?


Once your workshop is set up, you can begin what will become a never-ending task of learning to use it effectively. Set aside time to play with your tools and discover their limits and features. If you want to take advantage of pivot tables in Excel, waiting until they are essential to the product you must deliver by the end of the week is a mistake. Do you need to discover that pivot tables exist first?

This is all in the nature of “productive play,” of learning what is possible from the workshop you are designing.

Overcoming Resistance

“Productive play” may be essential to doing better knowledge work, but it is also a notion certain to trigger corporate antibodies in most organizations. You will encounter resistance, so you must have a plan for addressing it. Your most potent weapon: your ability to deliver better quality knowledge work.

Before you can do this, identify and enlist allies in your efforts and co-opt or counteract the most dangerous sources of resistance. The specifics will vary by organization, but expect to run afoul of your IT group and whoever ended up with oversight of Sarbanes-Oxley compliance for starters.

Step zero of any knowledge workshop strategy then becomes: “Take your CIO to lunch or befriend the folks staffing the help desk.” Their policy roles make them potential enemies, but their natural predispositions also make them potential allies.

Getting Started

The monoculture of office suites and corporate Web portals is rooted in outmoded assumptions about the nature of work as an industrial task.

Knowledge work is not factory work; factory strategies will not help knowledge workers. Tools are what you give to someone filling a well-defined role on the assembly line. A knowledge worker—you—needs to go further. Build your custom workshop now and see your work prosper.

Building a body of knowledge work

Case study cover pageI spent a year writing case studies before I began my doctoral program. More accurately, I was required to spend a year as a case writer to demonstrate my qualifications and commitment to the program before the admissions committee would accept me. My academic transcripts showed a bit more variance than the committee was accustomed to seeing and this was the compromise between the advisor who believed in me and the committee.

The first case I wrote dealt with Gillette and their efforts to figure out how to manage electronic data interchange with their customers. At the time this was a leading edge issue for IT organizations. I went with my advisor to our first set of interviews on the South Side of Boston. He  took three quarters of a page of notes at most; I was scribbling furiously to keep up.

The next day, we met to review what we had learned and my advisor’s first question was “where is your trip report?” My blank expression would not have been an encouraging sight to the admissions committee; my advisor was more forgiving.

What he expected and explained to me was to see my semi-legible and partial notes transformed into a coherent reaction to the previous day’s interview. If I was to eventually create a case study that would work in the classroom or extend our understanding of this issue, I needed to get my thinking out of my head and available for inspection, by myself first and foremost.

HBS believes deeply in the value of learning by doing. The case method immerses you in management and decision situations and you figure out what to do in the middle of the same mess and confusion you will later work in.  You learn to write cases in the same way—in the mess and confusion. The challenge is to discover the appropriate threads and themes without overwhelming what is there with your biases and preconceptions. Richard Feynman captured this challenge most succinctly thusly: “the first principle is that you must not fool yourself — and you are the easiest person to fool.” The discipline and practice of transforming raw interview notes into a trip report turns out to be a simple and useful technique for avoiding that trap.

After a good stretch of this learning by doing, I did discover that this approach exists in its own rich context, as does any fundamentally useful technique. Anthropologist Clifford Geertz called it “thick description,” Sociologists Barney Glaser and Anselm Strauss called it “grounded theory.”

I thought I was developing my skills to do organizational research. What I was also doing was developing a set of transferable knowledge work skills. I was laying the foundations of my personal knowledge management practices.

I’ve written before about the challenge of solving for pattern, which is a core requirement of knowledge work. This demands a respect for the richness of what is going on out in the world. We are pattern seeking/pattern recognizing creatures; our early survival depended on our ability to notice, extract, and react to patterns quickly. If we mistake a stick for a snake, there is little penalty; if we reach for a stick that turns out to be a snake, we die. Those instincts can be a problem in less threatening environments. In modern settings, imposing a bad pattern on data means missed opportunities; not death.

Our modern task is to get better at noticing what is interesting. We need to temper our instincts to instantly match a pattern and strive to remain grounded in the details that make up the phenomenon we wish to understand. What was once an essential research task is now a day-to-day requirement for the average knowledge worker.

What makes this tricky is that we don’t often know, at the outset, what constitutes the phenomena we are interested in. There is no easy way to separate the phenomena you are interested in from the surrounding environment and context. We may also not be able to easily differentiate between objective phenomena and our subjective reactions. Rather than pursue an unobtainable objective stance, we simply acknowledge and include our subjective responses as part of the package of data.

More often than not, this package of data—interview notes, trip report, exhibits—is only interesting to the individual knowledge worker; it is not yet a final deliverable for sharing. But the collection is worth keeping and organizing for two reasons. First, it provides an audit trail and supporting materials for whatever final deliverable does get produced. Second, it becomes a resource for future work.

As knowledge workers our value is built on a body of work that accumulates over time. We can make that body of work more valuable to ourselves and, therefore, to our organizations by becoming more systematic in how we create, assemble, and manage it.