To conspire, in its literal sense, means “to breathe together.” It is an intimate joining.
Here’s what Google has to say about the etymology of “conspire”:
To conspire, in its literal sense, means “to breathe together.” It is an intimate joining.
Here’s what Google has to say about the etymology of “conspire”:
Sunday, December 9 was the 50th anniversary of Doug Engelbart’s The Mother of All Demos. There was a symposium in his honor at The Computer History Museum and much media and Twitter activity throughout.
Among the many things said and written that caught my eye that weekend was a Twitter exchange between Greg Lloyd and Mark Szpakowski. Greg tweeted a quote from this Los Angeles Review of Books article:
“At the very heart of Engelbart’s vision was a recognition of the fact that it is ultimately humans who have to evolve, who have to change, not technology.”
And yet 99% of the Engelbart tribe work has been on the techie Tool System. http://www.dougengelbart.org/firsts/human-system.html … used to say “coming soon”; now it has disappeared. Time to join up with recent progress on Social Technologies for Complex Adaptive Anticipatory Human Systems?
I agree with Mark, with one caveat: It depends on how you define the “Engelbart tribe.” Let’s explore this caveat first.
There are many folks specializing in process design (what Doug would have categorized as “Human Systems”) who consider Doug a mentor or, at worst, an inspiration. I’m one of them, although I didn’t start (exclusively) from this place when I started working with him in 2000.
Three others in this group have been direct mentors to me: Jeff Conklin, who spent a good amount of time with Doug, and Gail and Matt Taylor, who didn’t, but who knew of him and his work. David Sibbet, the graphic facilitation pioneer, came across Doug’s work in 1972 and worked some with Geoff Ball, who was on Doug’s SRI team doing research on facilitating groups with a shared display. Those four people alone make for an impressive, accomplished, world-changing group.
There are also many, many more folks doing important work in human systems who aren’t familiar with Doug’s work at all or who don’t identify with him for whatever reason. Doug himself thought that lots of what was happening in both open source software development communities and in the Agile Movement were highly relevant, although he had nothing to do with either. At the Symposium celebrating Doug, Christina Engelbart, Doug’s daughter and the keeper of his intellectual legacy, connected the Lean movement to her dad’s work and invited Brant Cooper, the author of The Lean Entrepreneur, to speak.
An effective movement is an inclusive one. What matters more: Seeing Doug’s vision through, or establishing tribal boundaries? If the former, then it’s important to acknowledge and embrace the work of those who may not have the same heroes or conceptual frames of reference.
I don’t think many of us who loved Doug and were inspired by his vision have been very good at this, and unfortunately, our tribalism has extended to technologists too. After the Symposium, I had drinks with my friend, James Cham, who is a long-time fan of Doug’s, but who wasn’t lucky enough to spend much time with him. James told me that Dylan Field (co-founder of Figma Design) was inspired by Doug and that he had hosted his own celebration of the Demo that same Sunday that 300 people attended. Amjad Masad (founder of Repl.it, a tool that Doug would have loved) gave a thoughtful toast about Doug’s work there.
I didn’t know either Dylan or Amjad, and I certainly didn’t know that they tracked Doug’s work and were inspired it. I’m fairly certain that the organizers of the official celebration didn’t either. That’s pretty remarkable, given how small of a place Silicon Valley is. Now that we know, I hope we can start making some fruitful connections.
The movement of folks committed to Doug’s larger vision is much larger than the “official” tribe to which Mark referred in his tweet. But even if we take into account this larger group, I think Mark’s criticism still holds.
Doug sought to make the world collectively smarter. He believed the path to achieving this would be a co-evolutionary process involving both tool and human systems. In other words, new tools would give us new capabilities, assuming we learned how to master them. Those new capabilities would inspire us to create even better tools. Rinse, and repeat.
As my friend, Travis Kriplean, pointed out to me this morning, we can already test this hypothesis. Technology has already evolved exponentially. Have our collective capabilities — or even more importantly, our collective wisdom — evolved with it?
Let’s narrow the question. Our ability to capture, store, and share information has improved by leaps and bounds since Doug’s Demo in 1968. Has our collective memory increased as a result of that?
If you were pinning me down, I would guess, “no.” The mere existence of those tools don’t guarantee that we remember more. Furthermore, the tools have a nasty side effect of overwhelm. But, these tools certainly create the potential for us to remember more — we just have to figure out how.
Right now, my eight- and 14-year old nephews have access to this blog, where they can read many of my innermost thoughts, including stories I wrote about them when they were younger. Right now, they can explore my Flickr, Instagram, and YouTube accounts without even having to ask for permission. If they asked for permission, I would probably let them go through my Google Maps Timeline, which is automatically harvested from my cell phone’s location data and which contains a comprehensive journal of my every day travels over the past few years. They already have access to lots of information about me, including my efforts to distill little bits and pieces of my experience. Most of this is purely the result of technology, with a little bit coming from my occasional discipline of sharing thoughts here and there.
But does any of this help them become wiser? If not, is it because our technology has not evolved enough, or is it because our human practices have not evolved with the technology?
The best example I know of a human system that evolved with the technology are wikis in general and Wikipedia in particular. Not enough people realize that wikis and Wikipedias aren’t just tools. They are a wonderful marriage of human and tool systems that created fundamentally new collective capabilities, exactly the type of thing that Doug envisioned. They are also 20-year old examples. I think this speaks very much to Mark’s critique.
For the past four weeks, I’ve been doing a little experiment as part of a cohort in which I’m participating. Every week, I’ve set aside three hours to write about lessons I’ve learned from different people (Doug Engelbart, Jeff Conklin, Chris Dent, Gail and Matt Taylor, and Kristin Cobble) and projects. I’m doing it primarily as a bottoms-up exercise to surface the core principles of my work, but I’m also curious to see if the stories themselves help people better understand my own story — why I do the work that I do and the core principles underlying my practice.
It’s been challenging and fun. It’s definitely helped me get clear, and I’ve also gotten good feedback from peers. I’ve benefited from decently organized notes over the years, several of which I published on this blog.
At times, I find myself flummoxed by how long I’ve been doing this. I “officially” started focusing on collaboration in 2002 — 15 years ago! — and I started this blog the following year. I’ve been pulling up lots of posts that I wrote a decade ago or longer, and while it’s been fun to revisit work that I was doing and questions I was exploring, it also leaves me wondering where the years have gone.
Then I think about my mentors. Jeff had been doing this work for 20 years when I first met him, Matt and Gail for almost 30, and Doug for 50! One of the many things that all four of these good folks had in common was that they were still curious, still learning. They had strong points of view that they had earned through many years of real practice, but they never let that interfere with their hunger to learn more and from anyone, regardless of age or background.
Compared to my mentors, 15 years still squarely places me in the beginner category, which is good, because that’s about how I feel. Maybe I’m in second grade now. It’s firing me up for what I’ll learn in the next 15 years, at which point maybe I’ll graduate to third grade.
More importantly, it reminds me how lucky I’ve been to have important mentors in my life and how important it is for me to pay it forward.
Last year, I co-led a project called the Delta Dialogues, an effort to rebuild trust and shared understanding around critical water issues in the Sacramento-San Joaquin Delta. I’m very proud of that work, and knowing that I would have to let go of this project was one of the things that made leaving Groupaya last year very difficult. However, I also knew that I left the project in the capable hands of Kristin Cobble and Jeff Conklin. Moreover, the success of this project ultimately hinges on the participants themselves, and we had a wonderful core.
From the start, we designed the Dialogues to be a transparent process. We hired my friend, Joe Mathews, to be the storyteller, and we gave him one task: Write what you see. He’s been doing that beautifully from day one, from the monthly blog posts on the Delta Dialogues website to his beautiful narrative in the Phase 1 Final Report.
Tonight, I came across Joe’s latest blog post, a description of last month’s meeting. On the one hand, it was hard to read. It was clearly not a good meeting, and clearly, my old team contributed to that.
On the other hand, I felt very proud. I’m proud of my old team, I’m proud of my old client, the Delta Conservancy, and I’m proud of all of the Delta Dialogues participants for continuing to demonstrate a commitment to transparency. It could not have been easy to experience a meeting like this, and seeing it described in this way for all to see could not have made it feel any better.
However, any attempt to solve a truly meaningful problem is, by nature, complicated and messy. When I see stories like this, I trust that I’m getting an authentic picture of what’s happening, and I also get an opportunity to actually learn from it. That doesn’t happen when you whitewash your story, prioritizing perception over learning. Most of the “failure movement” in the nonprofit and philanthropic sector feels whitewashed to me. We need to see a lot more authentic sharing if we’re going to get better at this kind of work, and I’m proud that my old team is modeling this.
I wrote previously about including a checkbox for failure in your list of success metrics, where I told a story of a failure we had at one of the Delta Dialogues meetings that I facilitated. Honestly, that story is like a badge of honor to me. We failed, because we tried something that was hard, we learned from that experience, and we made things better as a result. I’m betting that this most recent failure will turn out to be the same for the current team.
What can others learn from this particular failure? I’m sure there were a thousand things that could have been better, and I’m sure that Kristin and Jeff have been exhaustive in cataloging all of them. I’m also quite certain that they violated the first rule of Changemaker Bootcamp a thousand times over, and I probably would have done so as well if I were in their shoes. It’s easier to see the bigger picture from the outside. I had two major takeaways.
First, I was struck by the simplicity of Joe’s observation that 40 percent of the participants at this meeting were new. That should have been an immediate red flag, and yet, I can also understand how easy it might have been to miss that.
In Phase One, we brought a wide array of sophisticated tools, and yet, these only contributed in small ways to our success. The vast majority of our success was due to our ability to co-create a safe container with the participants in which to have a very challenging discussion.
This was less about sophistication and more about effort. We devoted an incredible amount of time discussing this among ourselves and with the participants. We even threw in an additional meeting for free, because we felt it was critical to get right, and we needed more time in order to do so. We spent almost half of our precious time with participants doing site visits, rotating the location of the meetings, and giving participants a chance to viscerally experience each other’s lives and livelihoods. None of these ideas were particularly sophisticated, but the decision to prioritize these things in the face of many other pressures required skill and discipline.
In many ways, the current team was a victim of the original team’s success. Once you successfully create a container, people start taking it for granted, and it’s much harder to prioritize. If I were still leading the project, I don’t know if I would have had the skill and discipline to focus on these things in the face of intense pressure to do otherwise.
But, at the end of the day, facts are facts. Seven out of 17 of the participants that day were new. That’s a very large number. In that situation, you either have to commit time to reinforcing the container (either before or during the meeting), or you have to turn participants away.
Second, Jeff clearly had a bad day. I have worked with many great facilitators, and I have seen several of them have bad days. One of the things I learned from Matt and Gail Taylor was the importance of building a great support team and structure around the facilitators to increase the likelihood of their success. Otherwise, the only way a facilitator can be successful — especially when dealing with a wicked problem and a challenging environment — is by being superhuman.
No one is superhuman. Everybody has bad days, even with a great support structure around them. I think a lot of facilitators forget this, and when they have a bad day, they punish themselves relentlessly. Jeff is one of the truly great facilitators in the world. If he can have a bad day, then anyone can. This stuff is hard. It’s important not to lose sight of that.
The Delta Dialogues participants are committed and resilient. They’ll be back, and the process will get back on track.
For the last exercise of my guest stint at Alexander Laszlo and Kathia Laszlo‘s Evolutionary Leadership class a few weeks ago, I decided to have the group come up with a working definition of “collaboration,” as well as thoughts on patterns of and metrics for effective collaboration. If this sounds boringly familiar to regular readers of this blog, it should. This conceptual framework is fundamental to everything I do, and I spend a lot of time thinking, writing, and leading workshops about it. (MMQ)
It was all par for the course for me, except I only had 90 minutes. The way I usually approach this in my workshops is to start with storytelling, model the collaborative experience, then have the participants synthesize the framework themselves based on their own learning. We didn’t have time for that. I thought about giving up and doing a traditional lecture, and if I had had slightly less time (say, an hour), I probably would have. But, that would have been extremely lame, and I wanted to see if I could pull off something interesting in 90 minutes. (MMR)
What I decided to do in the end was create a makeshift anthropology experiment, with the students acting as both the subjects and the anthropologists. I divided the class into four teams. The first three teams would spend half an hour working on the same problem: Define collaboration. However, each team would have different process and tool constraints. The fourth team would observe the other three working. (MMS)
The three teams were Team Nike, Team Wiki, and Team Taylor. Team Nike’s constraints were simple: It had none. I gave them the challenge without guidance or constraints, and it was up to them to figure out how to go about solving the problem. Their task was to just do it. (MMT)
Team Wiki was divided into three subteams. They were allowed to interact as much as they wanted and however they wanted with their subteams, but they were not allowed to verbally communicate between subteams. There was a laptop projected in the middle of the room running a text editor. The team’s final product would be whatever was written on the text editor at the end of their time. Only one group could be at the keyboard at a time, and they could write whatever they wanted on the editor. (MMU)
The final team, Team Taylor, was given a process similar to one I’ve used in many other workshops. They initially broke up into small groups and shared personal experiences with great collaboration. They then regrouped and worked through a series of “Is it Collaboration?” scenarios. Finally, they were given the final exercise and asked to put together a definition given their previous work. (They were named after Blue Oxen advisor Gail Taylor and her husband, Matt Taylor, who were my advanced introduction to workshop designs like these.) (MMW)
Why this breakdown? I really wanted the students to think carefully about their experiences collaborating with each other as much as the content of the exercise itself. By having three processes going simultaneously, it was clear that the compare-and-contrast would be an important element in this exercise. By having full-fledged observation teams, this process discussion would be a major part of the report-out as well as the resulting work products. (MMX)
I think the exercise worked moderately well. The participants seemed to enjoy the process, and the comments in the debrief were excellent. The timing was predictably tight, and there were some aspects of the exercise that could have been tightened up some. The most frustrating omission for me was the lack of a collective synthesis process, but I knew that would be the case from the start. (MMY)
I was most curious to see what Team Nike would do, since they had the least constraints. Both the team itself and its observers noted that initially, there was a lot of talking past each other. I think that’s very natural for large groups that are new to each other, especially when under time constraints. I observed something similar during the Hidden Connections breakout I participated in earlier in the day, and we all saw this during the group counting exercise as well. (MMZ)
There are several ways to counter this phenomenon. The method most people tend to default to is “stronger facilitation” — having a designated facilitator maintain tight control over the process. There’s a time and a place for this, but I think the resulting order is largely artificial, and that the group will likely fail the Squirm Test. If you do have a designated facilitator, one simple technique that is remarkably effective and underutilized is to simply ask the group to listen to and respect their peers. We saw this work with the group counting exercise, and I’ve seen it work again and again in other meeting contexts. (MN0)
Although there was no designated facilitator for Team Nike, a few individuals stepped up to take on that role. There was no decision-making process up-front. One student simply started acting as the facilitator, and the others followed. (Leadership is action.) Another student started taking notes and often validated what other people said, which helped slow down the discussion and validated individual participation. This is an outstanding example of the artifact playing a strong, facilitative role, a premise underlying patterns such as Shared Display and processes such as Dialogue Mapping. (MN1)
At one point, Alexander Laszlo, who was participating in Team Nike, approached me and asked, “Can we collaborate with other groups?” I laughed and said, “You can do anything that wasn’t expressly forbidden.” Because of the time constraints, Team Nike didn’t end up pursuing this, but I was glad they had this insight in the first place. It’s always one of my favorite moments when somebody realizes, “Is there any reason why we couldn’t collaborate with others?” It often takes surprisingly long for someone to figure this out, even at workshops where collaboration is one of the stated goals. It’s a sign of how culturally engrained it is for us not to collaborate with each other. (MN2)
In my opinion, strong design is much more powerful than strong facilitation, and those were principles I hoped would emerge when comparing Team Wiki and Team Taylor’s processes with Team Nike’s. Two design constraints all three teams shared were a concrete goal and a time constraint. Nothing motivates a group to collaborate more effectively than a sense of urgency, and both of these constraints help to create that urgency. One of the most important elements of Blue Oxen‘s definition of collaboration is the notion that the goal is bounded — that it has both a beginning and an end. If there’s an end, then the goal is measurable, and you can have a time constraint. None of the teams identified this in their definitions of collaboration, although I’d be willing to bet that it would have emerged if we had more time. (MN3)
Another useful design constraint is the power of small groups. Conversation flowed better within both Team Wiki and Team Taylor, and that flow carried over when Team Taylor got together as a large group. It’s a simple principle, and yet it’s also vastly underutilized. (MN4)
Besides being broken into small groups, Team Wiki’s major design constraint was the use of a Shared Display as a medium for both creating their deliverable and communicating between the group. My goal was to simulate a Wiki-like collaborative pattern in a very short timespan. Given my well-known love of Wikis, I enjoyed watching this group the most. The content itself evolved predictably in a way that was reminiscent of Wikis, starting with a straw man of content, some side conversations in the document itself, and plenty of refactoring. The group dynamic, however, was anything but predictable. One group went directly to the laptop and started working. Another group saw this, realized only one group could type at a time, and decided that it would spend most of its time talking amongst themselves. Throughout the half hour, two groups regular switched off on the laptop while the third group didn’t participate until the very end. The last few minutes was mostly frantic typing while everyone else stood around and watched. (MN5)
Several people noted the challenge of having only a single keyboard, and expressed curiosity about the possibility of having multiple people work simultaneously. We could have accomplished that a number of ways, the best of which would have been to use a real-time collaborative editor such as Gobby or SynchroEdit. However, the point of this exercise was to simulate asysnchronous collaboration. I think this was an exercise that would have benefited from a bit more time. (MN6)
Two interesting things emerged from Team Taylor, one which I expected and one which I didn’t even notice until the team itself pointed it out. At one point, the team observed that two people were monopolizing the conversation, and that they were both men, even though the majority of the group comprised of women. This observation was complicated by the fact that the observation team — in this case, all men — were sitting with the group in a circle rather than outside of the group. As a result, it was hard to say whether this was indeed a gender dynamic, or whether the two who spoke the most just happened to be the biggest talkers in the group. Nevertheless, the awareness of the gender dynamic was an important one that a lot of facilitators — especially males — miss. (MN7)
Team Taylor didn’t do a particularly good job at the stated exercise, but one participant observed that if they had five more minutes, they would have done an amazing job. I believe this, and I think the resulting definition would have scored the highest on the Squirm Test. The reason for that was that their process was optimized for building Shared Language and trust. The personal storytelling was especially important for trust-building. When you have both of these in great amounts, the actual collaboration is far more effective. Truthfully, they were also hamstrung by the fact that I didn’t tell them what their actual goal was until the final ten minutes of their exercise. That would have been an appropriate thing to do if they had much more time, but given the time constraints, it probably would have been more fair to tell them the exercise ahead of time. I agonized over this when designing the exercise, and I chose not to tell them the exercise in advance because I was afraid the urgency of the deadline might cause them to skip through the first two exercises. (MN8)
Finally, a word on the actual definitions. I wasn’t expecting to be blown away by any of the definitions, again largely due to the time constraints. I was more interested in the group learning. However, I thought all three definitions were pretty good, and I was impressed by the context and the patterns that emerged: the importance of trust, communication, and Shared Language, for example. I also saw something that I’ve seen with other folks and with other definitions. Everyone tried to define “effective collaboration,” when in fact, the exercise called for simply defining “collaboration.” I think it helps to separate the two. Ineffective collaboration is still collaboration. There is something cognitively liberating about separating the question of whether or not you are collaborating from whether or not you are collaborating effectively. (MN9)
I was very impressed by the quality of the group, and I had a blast working with them. I recommend folks interested in learning more about collaboration, systems thinking, and leadership in a business context to check out the Presidio School program, and in particular, to take a look at the various classes that the Laszlos teach. (MNA)