Category: Knowledge work

What’s in a name? Unexpected demands on 21st century knowledge workers

humpty-dumpty

I have over 49,000 files in the documents directory and its subdirectories on my computer. They span nearly thirty years of output writing, teaching, speaking, and consulting. These represent the knowledge assets that support my livelihood. I am willing to claim that this is likely to be typical of today’s knowledge workers. That means there is a knowledge management problem to solve at the personal level that precedes any organizational knowledge management requirement. The answer depends on being smart about naming things; in particular, about naming files.

This is a problem that snuck up on me; I muddled along for years before recognizing it and gradually crafting strategies to deal with it. At first, I thought of it as a problem of where to put things; a place for everything and everything in its place. The desktop metaphors of file folders and hierarchical directory trees fooled me into thinking that the answer was to replicate the practices of generations of file clerks and librarians. Wrong. The affordances of filing cabinets and bookshelves lead you in directions that create unnecessary problems and obscure the opportunities inherent in the digital realm.

The work of pioneering thinkers like Vannevar Bush, Doug Engelbart, Ted Nelson, and Tim Berners-Lee seemed to offer a way out. They painted a compelling picture of how knowledge work might flourish once everything was digital, reachable via clickable links, and cleverly indexed by the engineers and algorithms at Google. Progress, but these visions glossed over the question of how to create and manage all the digital goodies to be found at the other end of all those links. That’s the world that you and I spend our days in; a world of email, Slack, Dropbox, shared drives, and files. Lots of files; 49,000+ and counting in my case.

The choices you make the first time you save a file can either complicate or simplify your life tomorrow, next year, and five years from now. Here’s a file name I just pulled off my laptop from an old project;

Final Presentation v.3.31.ppt

I’m willing to bet that you have a similar file somewhere on your computer. In fact, I’m willing to bet that you have several files with that or a similar name. Now, you would be correct to surmise that this file was originally found in some project directory at the end of a path something like /Documents/CLIENT/CustomerServiceReview/. That doesn’t help you very much, however, without access to my computer. Things are slightly better if we are both working off of a shared drive or Dropbox folder. On the other hand, what if I need to email the file to a client whose IT department blocks access to Dropbox?

These are problems that occur when you share a file with an incomplete or ambiguous name. Weak file names also cause problems for the individual knowledge worker. While you will only name a file once, you will have frequent opportunities to decide whether to look inside a file based on its name. You will often be making that choice while scanning through a list of potentially relevant files—either a directory listing or the results of a search.

Over the last several years, I’ve evolved a set of rules or guidelines for choosing a file name. As a sort of meta-rule, I start from the perspective that I will write the name only once, while I will read the name and decide what to do based on that name dozens or hundreds of times over the course of a project or a career. Here are the names of two files from my computer:

Brin-Page-AnatomyofaLarge-ScaleHypertextualWebSearchEngine.PDF

NSC-TLA-PKM-StrategyWhyAndHow-2011-04-21-1104.pptx

The first is a journal article I want to have ready access to; the second contains the slides for a talk I gave to a networking group I participate in. Let’s dissect the names to see what they tell me. The first file name is straightforward; it identifies the names of the authors and the title of the journal article. It contains all I need to decide whether I want to open the file to read it or whether this is the particular file I’d like to share with a colleague.

The second takes a little bit more effort to decode, although I can decipher the code on the fly, which is my principal concern. If I share the file with you, the code might slow you down a little bit but you can still extract the necessary information with no knowledge of my system. Let’s breakdown the name into its components and see why its constructed the way that it is:

  • PKM-StrategyWhyAndHow- This is simply a descriptive name for the contents of the presentation. “PKM” is my shorthand for Personal Knowledge Management.
  • 2011-04-21-1104 This is a timestamp for when I created the file. When I created this file, I was using timestamps that included the time as well as the date. In my current practice, I only record the date. I use a keyboard macro program (TextExpander on my Mac, ActiveWords when I am working in Windows) to enter the time or datestamp.
  • NSC- This is a shorthand code for the organization I was part of at the time I wrote this talk. I’ve been affiliated with a number of different firms and institutions over the years and I find that who I was working for is a consistent memory trigger.
  • TLA- This is a shorthand code for the particular client I prepared this talk for. Another meaningful memory trigger.

There is a design logic underlying these names and a series of principles and considerations that have and continue to evolve:

  • Descriptive File Names: All modern file systems permit long file names. Use them. I choose names based on what they suggest about the contents and what will jog my memory later
  • Ordering of Name Elements: My basic ordering of name elements is Organization, Client/Project, Descriptive Name, and Datestamp. It’s basically a hierarchy to collect items in sorted lists
  • Shorthand Codes: I try to keep these codes at three letters each. I’ll deviate from that if something longer makes more sense. The codes are derived from the organization, client, project. etc. in a way that serves as a mnemonic for me. Three characters yields over 17,000 possible combinations so I’m not worried about running out. I don’t maintain an actual list; the code is a trigger for me to recall the actual organization. Here are some of the codes I currently use to offer a flavor of what I mean:
    • LOY – Loyola University Chicago
    • HCG – Huron Consulting Group
    • CMN – Collaborating Minds
    • NSC – New Shoreham Consulting
    • TLA – Technology Leaders Association
    • PKM – Personal Knowledge Management
  • Embedded Datestamps: Computer operating systems keep track of various file dates, so why bother to add a date to the file name? Because the operating system timestamps serve the operating system’s purpose and can change for any number of reasons. The embedded timestamp reflects a date that has significance to me. For example, it might be the day I delivered a particular talk.
  • Technical Considerations: Although most operating systems allow spaces in file names, I don’t use them. Instead I either capitalize each word (Title Case or CamelCase if you’re a wiki user) or use a dash to separate sections of the file name. I also try to avoid other punctuation characters to avoid potential problems in some operating system settings. Probably a holdover from my programming days.

This is a system that has evolved over time; much of it was not designed. I am not fanatical about any of it; utility today and tomorrow is the deciding factor. I do try to avoid the temptation to think any file is “only a temporary file.” I don’t try to be religious about any of this and keep the following passage from Jorge Luis Borges in mind:

These ambiguities, redundancies and deficiencies remind us of those which doctor Franz Kuhn attributes to a certain Chinese encyclopaedia entitled ‘Celestial Empire of benevolent Knowledge’. In its remote pages it is written that the animals are divided into:

(a) belonging to the emperor,

(b) embalmed,

(c ) tame,

(d) suckling pigs,

(e) sirens,

(f) fabulous,

(g) stray dogs,

(h) included in the present classification,

(i) frenzied,

(j) innumerable,

(k) drawn with a very fine camelhair brush,

(l) et cetera,

(m) having just broken the water pitcher,

(n) that from a long way off look like flies.

Paths to more effective knowledge work

There is no curriculum on how to be an effective knowledge worker although we live in a world dominated by knowledge work. We identify ourselves as knowledge workers. But what comes after that?

Peter Drucker observed that the defining characteristic of knowledge work and knowledge workers is that the first question is “what is the task?” (see Knowledge-Worker Productivity). In manual work, the task is a given. It is defined in advance of hiring the worker and its various inputs, outputs, and structures define who the appropriate worker is for each task.

All knowledge work begins with the question of what is it that I am expected to do. Nothing in conventional education or conventional organizational thinking prepares us to deal with this question. This goes well beyond questions of self-management or self organizing systems. It implies that we each have responsibility as both designers and executors of our work. It is not sufficient to understand the ins and outs of Microsoft Excel or Microsoft Word. If we have some responsibility for defining what the task is, then we have some responsibility to understand why the task is relevant and how it fits into the broader picture.

This complicates our lives as both individual knowledge workers and as members of larger organizations. This obsoletes conventional job descriptions. Every job now has components of project management, of strategic thinking, of analytic thinking, and design creativity. What does this imply for how we educate and develop ourselves to be effective as knowledge workers? Note that I’ve focused this question on our individual responsibilities. That leaves another set of questions for the educational institutions and training organizations that lay claim to preparing us for the environment in which we work.

Book Review – Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration

CreativityIncCover

 

Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration

Ed Catmull with Amy Wallace,
Random House, New York, 2014

 

This is an excellent case study of creativity and collaboration at scale. Ed Catmull was one of the co-founders of Pixar. With co-author/collaborator Amy Wallace, Catmull reflects on the lessons he and his colleagues have learned over nearly three decades of superior creative work. 

There’s a management summary of key lessons at the end of the book. For example, here’s Catmull on errors: 

Do not fall for the illusion that by preventing errors, you won’t have errors to fix. The truth is, the cost of preventing errors is often far greater than the cost of fixing them.

Pithy, but you’ll do yourself a disservice if you skip ahead to the conclusion. The value here is in the details and the unfolding stories of challenges met and mistakes made. 

I’ve been a fan of the movies forever and I’ve always been intrigued by the complexity hinted at in the credits. It’s easy to be dazzled by the egos of movie stars and auteur directors. The real work of any movie is hideously complex and interdependent. With the likes of Toy Story or The Incredibles, you must integrate art, science, technology, and business in a dynamic balancing act that spans months and years. This is organizational and management challenge in the extreme. 

Catmull is a computer scientist by training who grew into an executive role in a business that makes money by creating art collaboratively. The lessons here are applicable in any organizational context. They are all the more important because the organizational and economic world is moving along paths that Pixar has already travelled. Catmull’s observations and lessons learned are a report from the future. 

Organizations are backward focused. Accounting systems, standard operating procedures, human resource policies all look backwards. That can be appropriate in a slowly evolving world, but that is not the world we live in. That we live in a time of rapid change may be a cliche, but that does not make it less true. Catmull offers timely advice for this new world:

Whether it’s the kernel of a movie idea or a fledgling internship program, the new needs protection. Business-as-usual does not. Managers do not need to work hard to protect established ideas or ways of doing business. The system is tilted to favor the incumbent. The challenger needs support to find its footing. And protection of the new—of the future, not the past—must be a conscious effort.

How to read and understand a scientific paper: a guide for non-scientists « Violent metaphors

I only wish I had been this organized and diligent when I was doing the research for my dissertation. Or that I had had this kind of excellent advice available when I did. 

How to read and understand a scientific paper: a guide for non-scientists « Violent metaphors: “What constitutes enough proof? Obviously everyone has a different answer to that question. But to form a truly educated opinion on a scientific subject, you need to become familiar with current research in that field.  And to do that, you have to read the ‘primary research literature’ (often just called ‘the literature’). You might have tried to read scientific papers before and been frustrated by the dense, stilted writing and the unfamiliar jargon. I remember feeling this way!  Reading and understanding research papers is a skill which every single doctor and scientist has had to learn during graduate school.  You can learn it too, but like any skill it takes patience and practice.

I want to help people become more scientifically literate, so I wrote this guide for how a layperson can approach reading and understanding a scientific research paper. It’s appropriate for someone who has no background whatsoever in science or medicine, and based on the assumption that he or she is doing this for the purpose of getting a basic understanding of a paper and deciding whether or not it’s a reputable study.”

While excellent advice in its own right, this blog post is also a reminder that knowledge work requires some pretty sophisticated skills and those skills require practice to develop and maintain.

Wise advice—hard practice. Do the work—share it.

I discovered this in the usual way—by ignoring the advice and following a trail of breadcrumbs that started on Facebook. I’ve paired this talk by Neil Gaiman with a related one by Ira Glass below. I wanted to have both of them ready to hand when I needed some encouragement and a kick in the ass.

Gaiman’s closing advice: ‘Be wise, because the world needs more wisdom. And if you cannot be wise pretend to be someone who is wise — and then just behave like they would.'”

Neil Gaiman Addresses the University of the Arts Class of 2012 from The University of the Arts (Phl) on Vimeo.

 

(Via Neil Gaiman Says It Better (Video) | On Being.)

Here is Ira Glass with a similar set of observations and advice:

Eleven Years and Counting at McGee’s Musings

Yesterday marked the eleventh anniversary of the first blog post on McGee’s Musings in 2001.

In two weeks, we’ll practice the American version of democracy, choose a President, revolution will not occur regardless of who wins and, despite the rhetoric, life will go on. We (the U.S. and the rest of the planet) will still face a variety of wicked problems. 

Getting smarter about how we work as individuals, teams, crowds, competitors and the like remains a priority. My efforts in that regard haven’t yet worked their way to visibility here, but they will. Being part of the conversation is important. Listening is half of the process (maybe more). 

As always, my thanks to all of those who’ve been part of the interesting conversations that have taken place over the past year. 

KM Chicago: Collaborating Minds: Solving Tough Problems with a Unique Team

David and I will be talking about the work we’ve been doing on collaboration at next week’s KM Chicago meeting. We’re looking to have a highly interactive session. 

KM Chicago: Collaborating Minds: Solving Tough Problems with a Unique Team: ” Thursday, August 30, 2012 Collaborating Minds: Solving Tough Problems with a Unique Team At 5:30 on Tuesday, September 11th, join Jim McGee and David Friedman at KM Chicago’s monthly meeting to hear a progress report on ‘Collaborating Minds’, their unique problem-solving venture. This meeting will be especially productive in person, but participation online is also available. See details on the right.   As Jim points out, we continue to make progress in developing tools to support the efforts of teams to conduct complex knowledge work. At the same time, we are deepening our understanding of what differentiates highly effective teams from average teams. But these two streams of progress rarely intersect.   Collaborating Minds is the business concept that Jim and Dave have developed that functions at that intersection of complex knowledge work and highly effective teams.    Collaborating Minds tries to answer three related questions:

1. Given what we know about high-performance teams and current social technologies, can we create a virtual high-performance team with several hundred members?

2. If such a team existed, what kinds of problems could it solve that are currently unsolved?

3. Is there an acceptable business model to sustain that team over time?

On September 11th Jim and David will tell us what they’ve learned to date and will lead participants in a design collaboration that will help shape Collaborating Minds’ next stage of development.

Headshot DavidFriedmanDavid Friedman is passionate about problem-solving and about relationship building as fundamental human activities. That’s why he’s developing Collaborating Minds. He wants people to be much more productive and enjoy themselves much more too. He writes about collaboration at Positive Structures.  David was a partner at McKinsey & Company (a global consulting firm) and through his firm Bridgewell Partners has advised professionals on growing their practices through systematic relationship building. You can contact David here.  

 

 

McGeeJimHeadshot 20120807Jim McGee is an expert in knowledge management and knowledge use. He also knows a lot about technology, and about where technology and knowledge work intersect (or should). That’s why he’s a founder of Collaborating Minds. He’s been writing about these topics since 2001 at McGee’s Musings. Jim was a founder of Diamond Technology Partners (a technology and management consulting firm) and has been, among other roles, a faculty member at the Kellogg School at Northwestern University. You can contact Jim here. Posted by KMChicago at 5:15 PM “

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: