Learning via Artifacts: A Conversation with Dave Gray

Next Wednesday, April 2, 2014 at 12:30pm PDT, I’ll be participating in a public Google Hangout with my friend, Dave Gray. The conversation will be about learning via artifacts. All are welcome to watch. We’ll also be using a public Boardthing to take notes during the conversation, and we encourage everyone to join in that as well.

Why are we doing this, and what exactly is “learning via artifacts” all about?

The short answer is that this is a response to my recent blog post over on Faster Than 20, “Documenting Is Not Learning.” That post was a mini-rant on how many people seem to equate “learning systems” with trying to get people to write down and file everything that’s in their heads so that others can read and access them. It’s an incredibly naive approach, but people often pour thousands of dollars (and sometimes orders of magnitude more) into trying to build these kinds of systems, most of which inevitably fail.

My overwhelming desire to make this point caused me to wave my hands past a subtle, but equally important point, one that is foundational to all the work that I do: The process of documenting is one of the most powerful ways of catalyzing learning.

Dave (and a few others, actually) called me out on this point on Facebook. I agreed, and I said I needed to write a followup. But since I was already talking with him about this, and since he happens to be one of the foremost practitioners in this space, I figured it would be much more interesting to highlight his voice. Thus, next Wednesday’s Google Hangout was born.

The Boardthing is a huge bonus. Dave and his team recently created a wonderful collaborative tool that is the online equivalent of putting stickies on walls. If that sounds simple, it is, but when done right, it’s also incredibly powerful. Up until now, no one has done it right. We’ll use Boardthing to model what we’ll be talking about, and we hope that many of you will jump in as well.

The long story starts with this gift from Dave on October 18, 2006:

Designing for Emergence

Dave was participating in a collaboration workshop I was facilitating in St. Louis. To him, this isn’t anything special. This is simply the way he takes notes.

To me, this was a gift on many levels. Whenever I think about that workshop, I think of this image first. I actually took copious notes from that workshop, some of which I even blogged. I wrote a piece about the things I said that led to Dave drawing this. I also posted pictures from that workshop, including shots of the flipcharts from the day.

There are lots of great knowledge nuggets, most of which have been sitting around, collecting virtual dust for years. Until I think about this picture, that is. This image, for me, is the start of a trail, and whenever I start poking around it again, I remember old insights, and I look at them in new ways. I’m willing to bet that this holds true for whomever reads this, that you are far more likely to start poking around than you would have had you not seen the picture. There is something about the visual that draws us in, that stirs our emotions, that makes us want to know more.

This is all after-the-fact learning. But what about in-the-moment learning? What was happening in Dave’s head as he drew that picture? How did the act of drawing help him learn? What would happen if you made that synthesis process collaborative? How would that impact learning?

I’ll leave you all with these questions for now. This is the stuff that we’ll be talking about this coming Wednesday. But I do want to say a few more things about Dave.

Dave is and has been my hero in so many ways. I’ve known many brilliant visual thinkers and learners for many years, but there has always been something about Dave’s style and presence that has encouraged me to practice these skills myself more actively in a way that others haven’t.

The first time we met, he explained to me how he draws stick figures. His trick? Draw the body first. Why? Because body language says so much! That’s really the essence of what you’re trying to communicate. How freakin’ simple and brilliant is that?!

My partnership with Amy Wu over the years has been strongly influenced and inspired by Dave and his work, and you can see that in the evolution of my slides over the years and even in the Faster Than 20 website. What you don’t see in those final products are all of the sketches that both Amy and I drew to help us think through these ideas. Dave is one of the people who strongly inspired me to work this way.

To me, Dave personifies the learning mindset. At XPLANE, the wonderful design consultancy he founded years ago, he started something called Visual Thinking School, one of the ideas that inspired me to start Changemaker Bootcamp last year. He is a great speaker and writer, but he is also constantly making things — tools like Boardthing, companies like XPLANE, brilliant books like The Connected Company, beautiful paintings.

When he learns, he learns out loud, so that others can participate in and benefit from all aspects of his process, not just the beautiful, final artifacts. He wanted to learn more about Agile processes, so he decided to write a book about it. He’s interviewing great practitioners in order to learn, and he’s doing them live on Google Hangout, so others can learn with him.

I love every opportunity I have to chat with and learn from him, and I hope many of you will join us this Wednesday!

I’ll write a followup blog post on Faster Than 20 after our conversation about learning via artifacts, but in the meantime, you can read and watch some of the things I’ve said on this topic in the past:

Finally, here’s video from a brown bag I led in 2011 entitled, “Saving the World Through Better Note-Taking.”

The Banana Hoarding Problem

I spent a good portion of this weekend listening to (and laughing at) my friends, Andrew and Elene, who are having a little problem at work. They both work at a large Silicon Valley company that has fresh fruit delivered each week — apples, oranges, and green bananas. Each week, the bananas disappear right away. Why? Because people hoard a week’s worth of bananas at their cubicles, rather than taking only what they’re going to eat right away.    (LXI)

What should my friends do? Here were some answers I and others came up with:    (LXJ)

  • They should hoard bananas for themselves.    (LXK)
  • They should take bananas from one of the hoarders.    (LXL)
  • They should bring their own bananas.    (LXM)
  • The company should order more bananas.    (LXN)
  • The company should appoint a banana distribution manager.    (LXO)
  • They should hoard all the bananas themselves, and become the de facto banana distribution managers.    (LXP)
  • The company should hire an old person to stand in the kitchen at all times, a la Wal-Mart. This will shame people from hoarding.    (LXQ)
  • They should poison one bunch of bananas, then put up a sign saying that one bunch is poisoned without indicating which one.    (LXR)

What would you do? Blog (and link here) or tell me your answers.    (LXS)

Not only was it incredibly funny to see how dismayed my friends were (what can I say, I’m a sadist?), but it was actually interesting to think through the problem. It’s a real-life instance of the Prisoner’s Dilemma, a classic cooperation (but not necessarily collaboration) problem.    (LXT)

At the St. Louis Collaboratory workshop last October, we spent the day working on the Iterated Prisoners Dilemma, appropriate since the workshop was held in a former police station. It was fascinating to watch people work through the problem. I’ve been sitting on a pile of notes about it for months now, and this latest real-world dilemma may motivate me to sort through them and blog about it.    (LXU)

Update    (LY4)

Clearly, the Banana Hoarding Problem is more widespread than I originally thought, as the empathy and some possible solutions are already starting to come in. Once again, we see the Wisdom of Crowds at work (or not).    (LY5)

Keep your answers coming!    (LY8)

Group Information Hygiene

Last August, I wrote:    (LPS)

When we founded BlueOxenAssociates, we were supposed to be a place for those on the cutting edge of collaboration. I quickly discovered that most people who want or claim to be on the cutting edge are held back by poor PersonalInformationHygiene. People need to start with themselves before they worry about the group if they want to improve their ability to collaborate. (This is a general theme that extends beyond KnowledgeManagement.)  T    (LPT)

Poor Personal Information Hygiene can often interfere with group trust, and trust is a prerequisite for good collaboration.    (LPU)

In an ideal world, everyone on your team would be masters of Personal Information Hygiene, but in reality, that’s rarely the case. Frankly, I’m not sure if it’s always desirable. People have different kinds of intelligences, and it may be that certain kinds of intelligences are critical to a high-performance team, but are also orthogonal to good Personal Information Hygiene.    (LPV)

Is it possible to have good Group Information Hygiene if people on a team have poor Personal Information Hygiene? Moreover, is it possible for the whole to be greater than the sum?    (LPW)

You all know what my answers are.    (LPX)

Part of the MGTaylor facilitation philosophy is to offload all potential distractions so that the participants may focus entirely on the task at hand. When you attend an MGTaylor Design Shop, there are several Knowledge Workers present, who are responsible for managing the distractions (among other things). They set up and reset the environment. They scribe your conversations. They manage the clock.    (LPY)

The philosophy is not exclusive to MGTaylor. The Aspen Institute follows a similar process. So do high-level politicians and actors in big-budget films, where their schedules are minutely managed so that they can focus entirely on acting… er, and policy-making. So do fancy restaurants. The food at Gary Danko in San Francisco is fantastic, but the service is unbelievable. There are literally six servers hiding in the shadows, anticipating your needs and making sure your table space is always pristine. Your glass is always full. Your napkin is always folded. If you’re about to go to the bathroom, a server will pull out your chair and point you in the right direction. Remarkably, they pull this off without being overbearing and creepy.    (LPZ)

We can debate whether or not this is always a good thing. (I think the answer is no.) We can certainly agree that this level of service is not always practical. What’s indisputable is that in a collaborative situation, these things need to be done by somebody. The question is by whom?    (LQ0)

The Sacrificial Lamb (stolen from Jim Coplien and Neil Harrison‘s SacrificeOnePerson pattern) is both a pattern and an antipattern. Most of us are familiar with it as an antipattern, where someone “takes one for the team” and essentially does someone else’s job because that other person isn’t doing it. (We discussed this in great detail at last year’s St. Louis Collaboratory workshop.)    (LQ1)

When it’s a result of broken trust, Sacrificial Lamb is short-term positive, because the job gets done, but it’s long-term negative because it hurts your working chemistry and often overloads your most productive team members. When it’s intentional and explicit, it’s net positive, because it’s not breaking any trust relationships. The essence of Jim and Neil’s pattern is that instead of dividing the necessary but dreary tasks among multiple peers, you designate one person as the Sacrificial Lamb and that person handles all of those tasks, at least for one cycle. You increase the likelihood of the tasks getting done and getting done well, and you increase the productivity of your other team members. If done right, the whole will be greater than the sum. The Knowledge Workers in the MGTaylor process are essentially Sacrificial Lambs.    (LQ2)

The role of the Sacrificial Lamb is most often to maintain good Group Information Hygiene. Project managers will find this role familiar. For example, when scheduling meetings, you send frequent reminders, both to compensate for others who are not good at maintaining their own calendars and to correct potential miscommunications. These tasks are laborious, but they’re necessary for High-Performance Collaboration.    (LQ3)

Collaboration can be a difficult thing to measure, but measuring Group Information Hygiene is relatively easy. I used metrics associated with Group Information Hygiene extensively with a client last year as one indication of the state of collaboration within the community and the potential for improvement in the future. Poor Group Information Hygiene is a natural obstacle to scale.    (LQ4)

Granular Editing

I’ve been working with Doku Wiki a lot recently — it was what we used for the St. Louis Collaboratory workshop — and it reminded me of yet another reason why Granular Addressability is more important than we think it is.    (LFO)

My biggest takeaway from working with Doug Engelbart on the HyperScope this past year: Addressability is for more than linking. Indeed, HyperScope takes advantage of addressability to support some powerful navigation capabilities.    (LFP)

Well, addressability can also be used for editing. And in fact, it is. Both Mediawiki and Doku Wiki support granular editing. The reason? Mediawiki is designed for encyclopedias (specifically, Wikipedia. Doku Wiki is designed for authoring documentation. In both cases, you end up having long pages. Editing long pages in your browser is a major pain in the rear. It’s much easier to edit specific sections.    (LFQ)

Augment, of course, also supports granular editing, except the granularity supported is much finer.    (LFR)

This is yet another example of the following law of Collaborative Tools, which I first mentioned in my manifesto:    (LFS)

Good ideas get reimplemented over and over and over again, often independently. It behooves us to identify these ideas, name them, and implement them interoperably.    (LFT)

(This is also the fundamental principle underlying Pattern Languages.)    (LFU)

Designing for Emergence

Towards the end of the St. Louis Collaboratory workshop this past Wednesday, I said something about designing for emergence. Dave Gray thought enough about the point to note it in his own special way:    (LBW)

https://i0.wp.com/static.flickr.com/118/273880986_8153abce06_m.jpg?w=700    (LBX)

(Full size picture at Flickr.)    (LBY)

It’s not an exact quote, and his sketch is a bit stingy on the hair, but it captures the essence of the point. A more verbose version of what I said goes something like this:    (LBZ)

Designing for emergence is scary. I’ve facilitated several of these types of gatherings, and I’ve attended several more, and they always work. But they always stress me out, because you never know what’s going to happen. And that’s exactly the point.    (LC0)

What prevents me from going completely nuts is complete and utter faith in the following principle: If you get great people together and get out of their way, great things will happen. Good processes ultimately get out of people’s ways.    (LC1)

If you have great people, and if you trust your process, you have nothing to worry about. But I still get stressed.    (LC2)

I said something similar, but more general, at the first “Tools for Catalyzing Collaboration” workshop. The gist of it was:    (LC3)

You can’t organize self-organization. You can’t control emergence.    (LC4)

The biggest mistake that people make is that they point to Wikipedia or to MoveOn, and they say, “I want that.” Then they install a tool or spend a lot of money, and they expect some grand end state to emerge. That’s not how things work.    (LC5)

You can create conditions and space, and you can facilitate and catalyze what happens in that space, but you can’t control it. As soon as you try, you break your conditions, and you will fail.    (LC6)

On a similar vein, Kellee Sikes passed along one of Marcia Conner‘s sayings: “Stay on course, not on target.”    (LC7)