Jeff Conklin

From Faster Than 20
Revision as of 23:52, 14 September 2021 by Eekim (talk | contribs) (30 revisions imported: Imported from WebFaction on September 14, 2021)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Jeff has been a friend and mentor since the early 2000s. He was one of the first practitioners I met who had a comprehensive, systemic conceptual framework that he had translated into skillful, constantly evolving practice. I learned many of my core principles and practices directly from him, and — in addition to lots of informal gab and jam sessions and ongoing support and encouragement — I had the pleasure of working with him on a project with NASA regarding lunar dust and on the Delta Dialogues.

He is a brilliant, visionary practitioner who has focused his entire career on managing wicked problems. In the process, he has made significant contributions to the framing of wicked problems and the role that artifacts can play in how we work our way through them. He is generous, humble, caring, passionate, and obsessively committed to his craft. Like Doug Engelbart (which is how I met him), he is underappreciated by society and way, way too hard on himself. I owe him a tremendous amount.

For an excellent guide to his work, check out his book, Dialogue Mapping: Building Shared Understanding of Wicked Problems.

How I Met Jeff

My initial work with Doug Engelbart focused on augmenting human processes with technology. Even though Doug cared about hypermedia, we focused largely on hypertext. We also were focused more on high-level group processes rather than... well, meetings! We facilitated meetings in very traditional ways — there was an agenda and a facilitator, and the facilitator would try to get the whole group (regardless of size) through the agenda.

Most folks who self-identify as professional collaboration practitioners focus on meetings. While meetings are important, they are only one potential tool when folks collaborate. I think this overarching emphasis on meetings is problematic. I also think that, while most practitioners are meeting-centric, very few are actually good at designing good meetings, especially as the number and diversity of participants grow and the problems get more complex. --Eekim (talk) 23:01, 9 January 2017 (UTC)

In my work with Doug, two things happened. First, one of my colleagues — Jack Park — kept saying that we should look more closely at Jeff Conklin's work. Jack was particularly interested in Jeff's work with gIBIS — Graphical Issue-Based Information Systems. I took a look, and I thought it was interesting, but I didn't know what to do with it, so I didn't do anything. Jeff's background was interesting, too — software engineer turned researcher who had written a widely cited survey paper on hypertext systems and who was interested in how teams design things. He cited Doug as one of his two intellectual grandfathers, and so I mentally filed him away as one of Doug's people I would like to meet one day.

The other thing that happened was that Doug was extremely hard to work with. He knew it, and one of the original reasons he had asked me to work with him was that he thought I could compensate for some of his deficiencies. In particular, he had big blocks around language and trust. He had a big, complicated worldview with his own language to describe how everything was connected. He had trouble understanding other people's worldviews, and he didn't trust that others understood his, even those with whom he had worked for a long time.

As our technical work petered out, Doug asked me to join a small core team trying to help him re-launch the Bootstrap Alliance. We had been meeting regularly for several months, and we had gotten stuck. We needed some external help to get unstuck.

As it turned out, Jeff had made a bit of a career pivot. He was helping groups tackle hard problems (wicked and otherwise) by facilitating meetings using a process called Dialogue Mapping via a tool called QuestMap, which used gIBIS. He was leading a workshop in the Bay Area on Dialogue Mapping, and he invited me to participate.

All those weird sounding names and acronyms did not do justice to the simple elegance of Jeff's ideas nor to the immense skill with which he wielded and taught them. The technique was mind-blowing, and I couldn't wait to try them. I had a meeting the day after the workshop, so I gave it a shot. I crashed and burned. I was terrible, and half the team got really mad at me. Despite this terrifying experience, I recognized that it was my lack of proficiency and not the technique itself that was a problem, and I felt confident that I could improve. But I needed help.

That help came in the form of hiring Jeff to facilitate one of our Bootstrap Alliance meetings. He was the perfect person to facilitate the meeting with Doug. He was very familiar with Doug's ideas, Doug knew and trusted him (as much as he trusted anybody), and his work was all about developing shared language and trust, which was where we were blocked. In addition to skillfully guiding us through that meeting, I got to see a master practitioner do his work, which made me see some mistakes I had made. Not only was my next attempt at Dialogue Mapping a success, I took away lessons that affected how I facilitated and how I thought about collaboration in general.

In the ensuing years, I used Dialogue Mapping extensively. Much of my reputation as a facilitator was built on that technique. More recently, for a variety of reasons, I have incorporated the principles of Dialogue Mapping into my practice in other ways using tools other than Compendium (the successor to QuestMap, which sadly, hasn't been maintained for several years). I've been able to do this, because it is the principles that matter, not the specific form that I first learned. Jeff taught me this, and has been supportive of the evolution. Still, I badly wish there were a good successor to Compendium.

Lessons Learned

Framing around wicked problems. Jeff had two intellectual grandfathers — Doug and Horst Rittel, who coined the term, "wicked problems," and who came up with the IBIS grammar. The framing is particularly important, because it speaks to the madness of attempting to: 1. solve a non-linear problem linearly; and 2. solve a problem that fundamentally can't be solved. One of the characteristics of wicked problems is that they are so complex, every attempt to solve them leads to a different formulation of the problem. In essence, the problem keeps changing on you. The goal should not be to solve the problem, but to manage it. The way you do that is by building shared understanding.

To this day, it irks me when I see someone making grand claims about "solving wicked problems." If you say that, you don't understand what a wicked problem is. --Eekim (talk) 00:25, 10 January 2017 (UTC)

The design process is nonlinear (aka the jagged line graph, aka the green-line, red-line graph). When Jeff was studying design processes, his team realized that the way people said they designed (aka waterfall model) and the way they actually designed problems were totally different. Moreover, no one approached design the same way. If that was the natural way folks designed, then trying to dictate one particular model was futile. Design processes and tools needed to account for multiple styles, including the ability to jump back-and-forth between problem formulation and possible solutions.

Here's his explanation in his own words.

It's all about the questions. "IBIS grammar" is a fancy, intimidating way of saying questions, ideas, pros, and cons. That's it. Questions are critical, because they are inherently inclusive and generative. That said, some questions are more inclusive and generative than others. Understanding how to frame things and recognize generative questions is fundamental to critical thinking and good facilitation. There are simple rules that act as good starting points, such as avoid asking yes / no questions.

It's no coincidence that "Asking generative questions" is a core muscle in my collaboration muscles framework, and that the question exercises are core both to Muscles & Mindsets as well as the Strategy / Culture Bicycle. --Eekim (talk) 00:37, 10 January 2017 (UTC)

Left-hand move. In Dialogue Mapping, you typically map from left-to-right. For example, you have a question, you list possible answers to those questions to the right, etc. Often, group insights / convergence happen when a group realizes that there's a more fundamental question than the ones they've been trying to answer. That question is placed to the left of the current discussion, hence the term, "left-hand move." To me, the ability to get to these core questions — i.e. making left-hand moves — is one of the fundamental qualities of a skillful facilitator / leader.

Shared displays and lessons from Tic-Tac-Toe. The very first exercise Jeff had us do at his workshop was to find a partner and play Tic-Tac-Toe. Then he had us play without paper or pencil. Then he had us play 4x4 Tic-Tac-Toe without paper or pencil. This brilliant exercise (which I use all the time) is a very simple way to show how bad humans are at short-term memory. Regular 3x3 Tic-Tac-Toe consists of nine squares. As it turns out, humans are pretty good at remembering seven things at a time (plus or minus two). Any more than that, and our memory starts breaking down, which explains why 4x4 Tic-Tac-Toe (16 squares) is almost impossible for most of us to play without a shared display.

If this is a biological fact, then the notion of trying to have even a moderately complex conversation without the aid of a shared display seems absolutely ludicrous. And yet, we do this all the time.

Note-taking + shared display = facilitation. This is why teachers use chalkboards. This is why sitting around a table with a pen and the back of an envelope is a classic innovation trope. The act of taking notes on a shared display is enough to improve the quality of an interaction, regardless of how the notes are taken or how the display is used. However, how the notes are taken and how the display can take that interaction to the next level.

One important thing to note is that the artifact (i.e. the notes) are being used primarily as a mechanism to help develop shared understanding in real-time. If they can be used to communicate what happened after the fact to folks who did not participate, even better, but those are different, sometimes conflicting goals. Given this...

Balancing transcription and interpretation. Good note-taking — with or without IBIS — required finding the right balance between transcription and interpretation. It was especially important to balance elegance with ownership. You might find a simpler, more elegant way of capturing something, but if it doesn't resonate with your participants, they'll lose ownership. In those cases, better to use their language, even if it feels inelegant or even wrong.

Constantly refactor and validate. Capture, validate, refactor, capture, refactor, validate, capture, refactor, validate. One of the goals is to capture understanding as best you can as quickly as you can, then validate and adapt as quickly as you can. This philosophy is consistent with lots of other methodologies — active listening (where you reflect back what you're hearing), agile, design thinking, etc. — where the goal is rapid prototyping, rapid iterations. With Dialogue Mapping, you're essentially rapidly prototyping understanding. Without that validation, it's impossible to know if you truly have shared understanding.

A key component to this is refactoring — constantly improving and refining your synthesis, using validation as your guide.

Shared understanding and the Squirm Test. How do you know if a group has shared understanding? The thought experiment I developed as a result of my time with Doug and Jeff was the Squirm Test, which is one manifestation of capture + validate, and it was inspired by something I saw Doug do often in meetings, which was to silently squirm in a corner.

Space matters. While Jeff is deeply, intellectually rigorous, he was also a systemic thinker and practitioner. For example, Jeff was the first person to really emphasize the role of space in facilitation. It starts with the display. He talks about a shared display as being another participant in the room. If that's the case, then it should be positioned like a participant, so people can physically engage with it in the same way that they engage with other participants. Similarly, the visibility of what's on the display matters. If people can't read what's on the display, it might as well be invisible.

It kills me when I see people hire expensive graphic recorders and place them in the back of the room where no one can see what they're doing. In those cases, they are simply glorified note-takers. You have no opportunities for validation, unless the recorder speaks up during a conversation (something I've seen Lynn Carruthers do often, but that most recorders seem too intimidated to do) or unless someone validates after the fact. --Eekim (talk) 01:33, 10 January 2017 (UTC)

Your body matters. Similarly, Jeff encouraged me to use my body as a tool in facilitation. My physical presence is something that people feel. I can direct people's attention to the screen by physically standing in front of it and pointing at it. That might encourage others to do the same, and suddenly, their relationship to the screen and the content is completely different. One of the techniques I use often when facilitating is to step in and out of the circle, a simple and powerful way to shift energy without having to say a word.

He keeps teaching this. When we worked on the Delta Dialogues together, he noticed that I was looking at my computer screen rather than the shared display while Dialogue Mapping. "Look at the display," Jeff said. It's hard, but it made a difference!

Deictic gestures (or, the essential human-ness of pointing). One form of embodied practice is to point at something. Jeff taught me the term, "deictic," which essentially refers to the cognitive act of pointing at something. It turns out that our cognitive ability to point at things is one of the things that make humans unique in the animal kingdom. (Other animals that cognitively understand pointing without training include dogs and elephants.) If you think about this, this also speaks to the fundamental importance of the act of linking to something in hypertext.

Mastery requires paying attention to the little things. This is the essence of craft. How you used the IBIS grammar to capture was a fine art, but that included the little things, like always capitalizing node names. (The Compendium community — folks like the late, wonderful Al Selvin and Simon Buckingham Shum — were invaluable in discovering and distilling these nuggets of wisdom.) When I was first given this feedback about capitalization, I asked why. "Because it looks better," folks said. I didn't like the answer when I heard it, but I tried it, and I agree! It does look better!

The Compendium community — Al in particular — often compared Dialogue Mapping to playing the violin — a metaphor that appealed to me because it was in line with Doug's philosophy of expert-oriented interfaces and his bicycle metaphors. What was particularly hard about Dialogue Mapping was that it required literacy in three areas: facilitation, sensemaking, and the mapping tool itself. Folks in the community said that you could find people who were good at two things, but rarely found people who were good at all three.

Don't be a hero. Sensemaking is a powerful tool of skillful facilitators. It's hard in any circumstance, but the more wicked the problem gets, the less likely it is that any one person will be able to successfully make sense of a problem. A good Dialogue Mapper shares that responsibility with the whole room. (This is a lesson that Gail Taylor really elevated for me.) It's not just smart, it's necessary.

Take breaks. Dialogue Mapping is extremely cognitively challenging. The very first time I tried it in a live environment, I quickly became overwhelmed. Watching Jeff the first time, I noticed that he took breaks often. Those breaks are critical for resetting your brain and also refactoring the map. Simple, but very effective. I have generally found taking breaks to be a powerful, underused intervention. In my meeting designs, I have pre-scheduled long breaks that I protect religiously, and I will schedule more frequent breaks if I know someone — facilitator or participants — will be playing a particularly cognitively challenging role. (People like to throw out breaks when they're running out of time. It's misguided and undisciplined. Your brains need rest to be at their most effective.)

Hold a big vision, be humble, think systemically, constantly learn and adapt. Jeff, like Doug, was driven by a big vision — or by his desire to avoid a big collapse. He is concerned about the world, and he's devoted his entire life to doing something about it. His whole story shows someone constantly learning, pivoting, adapting. I especially like the history of Dialogue Mapping. His original vision was to use it as a tool for asynchronous collaboration. But it wasn't working. It was someone else's idea to use it as a tool for real-time collaboration. Jeff learned that it worked, and had the humility and integrity of vision to adapt to what someone else had figured out — then master it.

It's easy to overlook the subtle mastery in all of his work. A simple example of this is the importance he placed on transclusions. People see Dialogue Mapping, and they're reminded of other mapping tools, which holds true in a lot of ways. But there is no other mapping tool that implements transclusions. Jeff understood this obscure concept, and found a way to incorporate it subtly and simply.

See Also

Blue Oxen Barnstars: Jeff Conklin (March 23, 2009)