Life skills for knowledge workers

In his post Some qualities of a knowledge worker, which I also mentioned yesterday, Jack Vinson (@jackvinson) mentioned a few skills needed by knowledge workers and notes

These are things that aren’t part of the standard training curriculum.  Maybe these things should be in the next generation of “life skills” classes they teach in high school.

This gets right at the heart of a question I’ve pondered for several years: How do knowledge workers learn how to become knowledge workers?

Is “knowledge work” something that should be taught in school, in high school as Jack mentions or maybe in college? Or is this something that individual workers need to learn on the job, as part of their professional growth, as part of their development of their craft?

Schools are, for the most part, set up for you to learn the skills/knowledge that you need (or they think you will need) to do your job. But they don’t really teach you how to actually do the job. (It’s been a while since I’ve been an undergrad, so maybe this has changed somewhat?) I think, though, that with a little bit of thought and a lot of effort these skills could be incorporated into a schools curriculum, either formally or informally by individual teachers. The case for social media in school provides some good ideas on this front.

The other approach is to look at knowledge work as a craft. Obviously, “knowledge work” is much too general of a description to be a craft in and of itself [my dad is a knowledge worker!]. But just like the trades – plumbing, carpentry, electrician – you can look at the various forms of knowledge work as a craft – accountant, engineer, lawyer, software developer.

If the idea of knowledge work as craft sounds familiar, it’s not because of me. I first remember coming across that idea several years ago in Jim McGee’s (@jmcgeeKnowledge Work as Craft Work.

All along the way in this old style process, the work was visible. That meant that the more junior members of the team could learn how the process unfolded and how the final product grew over time. You, as a consultant, could see how the different editors and commentators reacted to different parts of the product.

More recently, Jim has written about this in the context of observable work (#owork). His recent post Finding knowledge work practices worth emulating and adapting has some excellent insights that expand on the idea of craft work, putting it in concrete terms of knowledge work, in this case the “trade” of software development.

My brothers both work in a trade (plumbing and electrician), and I’ve had many conversations with them about the process within the trade unions of developing young plumbers and electricians from apprentice through the master grade. It’s made me wonder how I ended up where I am, how I learned to do the job I do. A bit less structured than their experience, that’s for sure.

How did you learn how to be a knowledge worker? Did you spend your early years in an “apprenticeship” or were you just thrown into the fray? How do we help new knowledge workers learn their craft? How do we get knowledge workers, new or otherwise, to accept their profession as a craft? And how do we, as experienced knowledge workers, become even better at it?

For knowledge workers, solving problems is the easy part

I read – and highly recommend – Garry Kasparov’s book How Life Imitates Chess a couple of years ago, and am thinking I should pick it back up again. If not to read in its entirety, then at least to skim through my dog-ears and margin notes. There are a lot of good insights into the nature of work today, especially what we call knowledge-work.

For example, Jack Vinson’s (@jackvinson) recent post Some qualities of a knowledge worker reminded me of the following excerpt:

Knowing a solution is at hand is a huge advantage; it’s like not having a “none of the above” option. Anyone with reasonable competence and adequate resources can solve a puzzle when it is presented as something to be solved. We can skip the subtle evaluations and move directly to plugging in possible solutions until we hit upon a promising one. Uncertainty is far more challenging. Instead of immediately looking for solutions to the crisis, we have to maintain a constant state of asking, “Is there a crisis* forming?”

Solving a puzzle that you know has a solution may require knowledge, but it is knowledge that already exists. Figuring out if there is a solution to a problem, or even if there is a problem at all, requires the manipulation of existing knowledge, the gathering of new knowledge / information, and the creation of something new.

This is when knowledge work becomes art.

What we need are knowledge curators, not managers

The concept of “knowledge curator” has been creeping slowly from the back of my mind to the front over the past couple of years, and received a couple of jolts over the weekend that resulted in one of those elusive “aha moments”.

What we need are curators of knowledge,
not managers of knowledge.

First, I noticed the blurb “curated content from Flickr” when I used the Flickr module on a Squidoo lens.

Second was a quote from Liz Danzico (that I found via Signal vs. Noise blog).

A portfolio of work is a curated experience. … but oftentimes, a portfolio only contains final pieces, as applicants are overly concerned about presenting perfection. Polish doesn’t communicate process though, and therefore I’m left with only part of the story. Messy problems — and how applicants work through them — can show a great deal more in a portfolio than one finished, airtight solution.

I didn’t know it at the time,but this all started back in November 2005 with an article titled Technology makes it easy to ‘remember,’ the trick is learning how to forget, in which I wrote:

My early days in Knowledge Management included a lot of time developing, deploying, and getting people to use “knowledge repositories.” (At least trying to get people to use them.) … I finally realized one day that the problem has become not, “How do we remember all this knowledge that we’ve learned?” but rather, “How do we forget all this knowledge we’ve accumulated that we no longer need so we can focus on what we do need?”

I also noted a quote from the book The Trouble with Tom by Paul Collins related to the need to “eliminate” memories:

Memory is a toxin, and its overretention – the constant replaying of the past – is the hallmark of stress disorders and clinical depression. The elimination of memory is a bodily function, like the elimination of urine. Stop urinating and you have renal failure: stop forgetting and you go mad.

It was this latter quote that was in my mind last summer when, in The importance of forgetting,  I wrote about John Medina’s thoughts on the question of memory and forgetting in Brain Rules:

The last step in declarative processing is forgetting. The reason forgetting plays a vital role in our ability to function is deceptively simple. Forgetting allows us to prioritize events. Those events that are irrelevant to our survival will take up wasteful cognitive space if we assign them the same priority as events critical to our survival.

As I noted then, this is no less true in the organizational context of knowledge/concept work.

Simply capturing everything in document repositories and best practices, without the ability to forget – or supercede – any of it, takes up a lot of “cognitive space” that organizations could be putting to other wise good use.

The trick is figuring out how to forget, and how to figure out what to forget.

Which do you fear more, failure or mediocrity?

What motivational methods make some of you cringe (or worse)?

This is one of the questions that Dan Pink posed to the group participating in his live chat at The Book Club on the New Yorker. In response to the “Don’t make mistakes because I (mgr,owner, boss) will think less of you” motivational method, he said:

That’s one of the most insidious, imho. To me, it’s one of the greatest flaws in organizations. People are more scared of failure than of mediocrity. It should be the reverse. (emphasis mine)

Making a mistake is like breaking a leg. It happens and you fix it. Mediocrity is like a chronic, cancerous disease that gradually destroys you and from which recovery is far more difficult.

In the short term, mediocrity is “safe” and “going for it” is not. Or at least it doesn’t seem to be. (I can’t go for it, what if I make a mistake?)

Personally, I’d rather get a few broken bones along the way than spend my life trying to avoid those things that might cause them.

How about you?

A checklist for checklists

It’s easy to say, “Make a checklist for your complex process and use it”. It’s another thing altogether to actually make a checklist that is good and that works.

One of the things that I like most about The Checklist Manifesto is that it recognizes and addresses the challenges inherent in designing a good checklist. In fact, a good part of the story revolves around making the WHO surgical checklist a good one. In the acknowledgements section of the book, Gawande credits Boeing engineer Dan Boorman (who is also mentioned in the book) as an “essential partner” in the ongoing development of new checklists, and from the looks of it they’ve been hard at work.

Most relevant to my ongoing thread here is the Checklist for Checklists, pictured below. If you have decided that checklists can help you, this is an excellent place to start as you begin the process of developing your checklists.

Simplifying the execution of complexity

My review of Atul Gawande’s latest book The Checklist Manifesto focused, by design, on the broad scope of the book. Within that “big picture” lesson, though, are many smaller, more specific lessons to be learned.

For example:

No, the real lesson is that under conditions of true complexity – where the knowledge required exceeds that of any individual and unpredictability reigns – efforts to dictate every step from the center will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either – that is anarchy….

[U]nder conditions of complexity, not only are checklists a help, they are required for success. There must always be room for judgment, but judgment aided – and even enhanced – by procedure.

During this discussion, he refers back to what he had learned from the skyscraper-building industry, that they had figured out how to put an understanding of complexity into a series of checklists. That they had, in Gawande’s words, “made the reliable management of complexity a routine.”

What makes this even more fascinating is how the checklist, the lowly checklist that Steven Levitt had no interest in (until reading this book), can help simplify the execution of complexity even when the team members have never before worked together.

Just think what they could do for a team that works together all the time.

Navigating complexity with checklists (a book review)

Atul Gawande’s latest book, The Checklist Manifesto: How to Get Things Right is an incredible book that I highly recommend to anyone that works in a complex environment, especially if that involves working with multi-discipline teams. And most especially if this involves frequently working with people you have never worked with before.

I picked the book up not really knowing what I was in for. Talking about checklists, I thought maybe it would be a discussion of how to document and implement best practices, or something similar. Boy was I wrong.

At the surface, the book is the story of how Gawande, as part of a World Health Organization initiative to reduce surgical complication rates around the world, discovered the power of checklists to help avoid “avoidable failures.” Looked at more closely, it is a study of the importance of team building, team work, and communications between team members as they tackle the complex problems we all face today.

The first chapter, titled “The Problem of Extreme Complexity”, sets the stage. Later chapters build on this problem statement and uses examples from many diverse fields including aviation, construction,  and the operations of corporations and government. The common thread through each of these examples is the checklist – the lowly, simple checklist.

The challenges face by Gawande and the WHO team were (are) two fold: figuring out how to take what worked in these other industries and translating it into the needs of the surgical community; and getting past the culture of surgery and surgeons. The former was a relatively simple matter of trial and error, see what works and give it a try (in simulation first, where possible). The latter, on the other hand, remains a significant issue.

Part of the resistance is, according to Gawande, a misconception about what checklists are and the purpose they serve. This is a lesson he learned as he worked with engineers from Boeing in trying to understand what makes a good checklist:

It is common to misconceive how checklists function in complex lines of work. They are not comprehensive how-to guides, whether for building a skyscraper or getting a plan out of trouble. They are quick and simple tools aimed to buttress the skills of expert professionals. And by remaining swift and usable and resolutely modest, they are saving thousands upon thousands of lives.

As a systems engineer I recognize many of the issues, challenges, and solutions that Gawande discusses in the book. I was (am) quite appalled at how little of this systems type thinking seems to exist in the world of surgery and am quite hopeful that the idea of checklists catch on at all hospitals. If I ever have to go in for surgery, one of the first questions I ask the surgeon and his team is going to be, “Do you have a checklist prepared for this procedure?”

Perhaps the greatest insight about checklists in the book is that checklists – a lowly, simple, well crafted checklist – can take a group of individual experts and quickly turn them into an expert team.

All you have to do is use it.

Update: For more on the book, links to various media interviews, and some examples of effective checklists, visit Atul Gawande’s website.