Doug Engelbart, Human Systems, Tribes, and Collective Wisdom

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.”

Mark responded:

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.

Tribes and Movements

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.

Capabilities and Collective Wisdom

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.

Making Change Safe

My buddy, Justin Lin, has a company that recently migrated from J2EE to Ruby On Rails, and he’s been thrilled by the results. This morning, we were IMing about Agile Programming, and something he said about Unit Tests really struck a chord. He said that their tests softened their fear of change, which changed the team’s entire attitude about change in general.    (KJX)

I’ve written about Unit Tests before in a coding context, and of course, their importance is well understood in the Agile Programming community. What struck me about Justin’s comments was that he was describing how a tool in a very specific context was catalyzing a cultural shift within his company. While he didn’t say this explicitly, I can imagine that shift extending beyond the technical component of the company.    (KJY)

The lesson: Tools that make change safe facilitate a culture of adaptation. An adaptive organization is a strong, effective organization.    (KJZ)

What are some other tools that make change safe? I saw Kellan Elliott-McCrea yesterday (welcome back to California, Kellan!), who reminded me of a suggestion I had made for Social Source Commons a while back: Wiki-style editing works because the revision history is visible. A visible revision history encourages change in the form of Permission To Participate, and that in turn can lead to a larger cultural shift within your team and even your organization as a whole.    (KK0)

Extreme Usability Redux

Another great FLOSS Usability Sprint is in the books. As usual, great people make for great gatherings, and this event was no exception. But we did have a new goal for this event, and it resulted in some different outcomes, many of which were related to this new notion of Extreme Usability.    (JOS)

I have three overarching goals with all of these sprints:    (JOT)

  1. Improve the usability of the participating projects.    (JOU)
  2. Build greater Shared Understanding between the usability and Open Source communities.    (JOV)
  3. Catalyze community collaboration.    (JOW)

Additionally, as an organizer, you also want to “hit a home run,” as Jeff Shults likes to say. You want people to walk away feeling wonderful about themselves and about the group at large. As with baseball, you’re not going to hit a home run with every event, but you’re constantly hoping for it.    (JOX)

I think we hit a triple with our first sprint. We had great camaraderie and positive energy, everyone learned tons, and all of the participating projects made tangible progress. In fact, in the past few weeks, I learned that we made even greater progress with “catalyzing community collaboration” than even I had realized. Kieran Lal, Jan Muehlig, and Rashmi Sinha have all been developing tools for remote usability testing, a critical prerequisite for Open Source usability, where projects are usually distributed. (Our next sprint will most likely be a Remote Usability Sprint, tentatively scheduled for late Fall.) Mimi Yin‘s experiences at the first sprint helped form the seed for her most recent thinking for Chandler. Mimi’s informal discussions with Dave Greenberg at the first sprint influenced the most recent release of CiviCRM, and they worked together more closely this week. Most importantly, the many report-backs generated buzz in the community and helped bring in new talent, like Tony Chang and Jing Wu. There was also room to improve, though, and we incorporated some of that learning into this past sprint. All in all, people walked away feeling good.    (JOY)

This week’s sprint felt like a double. Once again, our projects made progress, people were buzzing and learning, and I think people had fun overall. Nevertheless, there was a cloud hanging over everybody’s head, one that made folks a bit more uncomfortable and the process as a whole more challenging. The cloud was the result of a special goal for this particular event — defining Extreme Usability.    (JOZ)

An Aside on Event Design    (JP0)

We did not define Extreme Usability prior to the event, largely because none of us knew exactly what it was. I had opinions, based on feedback from the first sprint and my own personal experiences, but I didn’t want to dictate the design of the event based on my own biases. One reason for this stemmed from my growing faith in the power of collective wisdom. Another reason was that I didn’t want people worrying too much about whether they were “doing it right.” My main concern was for the projects to get better.    (JP1)

Gathering a large group of folks with diverse backgrounds isn’t the most efficient way to develop a methodology. The vast majority of developers knew very little about usability, and only a handful had ever practiced Extreme Programming. We had 25 people attend, including users. In contrast, two people — Kent Beck and Ward Cunningham — co-conceived Extreme Programming, and they had many years of software development experience between them.    (JP2)

The other complication, which we downplayed, was that this was not simply an experiment in software development methodology. It was an experiment in Open Source software development methodology, which introduced its own constraints. Extreme Programming isn’t rampant in the Open Source community, primarily because its tenets are difficult to practice in this environment. Who is the customer? How do you pair program? What does a 40-hour work week mean, when you’re writing code on the side?    (JP3)

Given all of these factors, it seems unrealistic to have expected our participants to have contributed consciously to the creation of a new methodology. Why, then, did we try? Why this format?    (JP4)

My framing of Extreme Usability to the participants provides some insight as to why we chose this event format:    (JP5)

  • Agile Programming is an acknowledgement that software development is a collaborative process, and collaboration is hard. Agile methodologies offer a framework for alleviating these difficulties. Iteration and validation, for example, is a way to build Shared Understanding.    (JP6)
  • Methodologies like Extreme Programming lack an explicit role for usability practitioners. Extreme Programming provides rudimentary methods for developers to collaborate directly with customers, emphasizing “soft” forms of communication rather than requiring rigorous structure. User-Centered Design, on the other hand, incorporates into the process a usability specialist who has a range of methods for understanding user behavior.    (JP7)
  • The theory behind Extreme Usability is that usability practitioners should be co-collaborators with programmers for the entire lifecycle of the development process.    (JP8)
  • The biggest roadblocks for developers in this process would be to open up their minds, willingly and sincerely embracing the usability practitioners as codesigners, and accepting the possibility that their assumptions about the users and the design might be wrong.    (JP9)

The challenge is developing the framework in which usability practitioners and developers collaborate. This sprint was a laboratory in which we could experiment with this framework.    (JPA)

Rather than impose a more rigid process up-front, I wanted to test a general premise about collaboration: Eliminating barriers is generally more empowering than problematic. Pair Programming is a perfect example of this. A lot of programmers (and managers) react negatively to Pair Programming the first time they hear about it, because they assume that programmers need to be isolated to work effectively, and that they will be unable to collaborate effectively without this separate space. Experience has raised serious doubts about that assumption. We see a similar phenomenon with Wikis. Most people still assume that we have to impose structure and authority or our information spaces will devolve into chaos. Wikis obviously challenge this premise.    (JPB)

I wanted to watch how developers would work with usability practitioners with no preimposed constraints, hoping that our collective observations and experiences would result in a more useful framework than I could have come up with on my own.    (JPC)

The event was successful in this regard, but it came at a cost. We placed a heavy burden on our participants by making this goal collective and explicit. It’s hard, even debilitating, to be self-reflexive about process while you’re working. This was most evident on our second day. Frustration was palpable among our participants, as they struggled to both work on their projects and think about process. That everybody stayed positive and productive was a testament to everybody’s great attitudes, and for that I am grateful.    (JPD)

What Is Extreme Usability?    (JPE)

The conclusion among most of our participants, in the end, was that what most of us practiced was not Extreme Usability. I concur. Nevertheless, it offered some clues as to what Extreme Usability might be.    (JPF)

It may be a misnomer, for one. Rashmi Sinha suggested that what we were aiming for was actually “Collaborative Usability.” I would go further and say that it was “Extreme Design,” centering attention on the design rather than the overall development methodology.    (JPG)

Other thoughts:    (JPH)

  • “Customers” are not “users.” Once a customer becomes a codesigner, he or she loses value as a user, because he or she becomes subject to major bias from the design process itself. We attempted to include “users” as codesigners, which was wrong. You’re either one or the other (and it’s okay for a “customer” to be a codesigner), but you can’t be both.    (JPI)
  • Pairing is good. We required each project to bring two developers, and we assigned two usability specialists to each projects. However, we did not mandate pairing, and there were also other people working with each project. By the middle of the second day, each of the projects had figured this out on their own. If we do a second Extreme Usability sprint, pairing will play a central role in the process.    (JPJ)
  • Extreme Usability is not about taking shortcuts. Sprints are. The two should not be conflated. Many participants from our first sprint said that their biggest takeaway was that informal usability was valuable. You don’t need to have a high-overhead (i.e. expensive) usability process to develop usable software. I think this week’s sprint reinforced that. At the same time, I think it’s important not to conflate the sprint format with Extreme Usability.    (JPK)

Usability-Driven Projects    (JPL)

We intentionally chose early stage Open Source projects to participate in this sprint, but in doing so, we were still propagating what seems to be a given with all Open Source projects: they are started by developers. That naturally tips the power balance towards developers. I would love to do a sprint where the roles were reversed. Usability practitioners could bring project ideas — perhaps with wireframes or workflows — and developers would come to help with the design and implementation.    (JPM)

In a similar vein, Mimi Yin had a great idea. There should be an “inverted Sourceforge,” a place where usability practitioners — not developers — could start Open Source projects.    (JPN)