(Originally posted at: Engelbart Book Dialogues as an interview with Eileen Clegg)
I’ve been committed to Doug’s ideas since I attended his week-long seminar in March of 1992, at Stanford University, and subsequently brought him in to consult with our small team developing analytical and visualization tools for a branch of government intelligence analysts. I was inspired by his comprehensive and innovative approach to boosting the collective intelligence of people and teams. Since that first exposure, I have sought to apply his ideas in every professional (and even non-professional) role I’ve had. In the early 1990’s, I was honored to serve as chairman of his Bootstrap Alliance, and today, am working with my Program for the Future associates to further disseminate Doug’s vision for enabling teams (and all of humanity) to solve complex problems.
Doug is well-known for his amazing technology innovations, but even Doug doesn’t call himself a technologist. His focus is how technology can be leveraged for problem-solving. He has warned that if we do not evolve our ability to apply technology more effectively at a rate that keeps pace with the evolution of technology itself, the end result will likely be detrimental to our intentions. I share Doug’s concern that humanity is running out of time to effectively counter those threats we’ve created for ourselves.
Engelbart’s conceptual framework encompasses a multi-layered approach to boosting the collective intelligence of people—using technology to improve human capabilities, and then using tool-augmented behavior and habits to influence the further refinement of the tools, in a continual “co-evolution.”
Engelbart has an appreciation for the complexity of organizational processes that take place within and among teams. His focus is on how tools and practices can make human beings and teams collaborate, and how to integrate our work across disciplines. These processes can then scale up, so that ever-increasing groups of people can work together to address impending phenomena that threaten our existence.
Unfortunately, often people fail to increase their own capacity. We fail into the “ease of use” trap and don’t choose to evolve our behaviors and practices.
Engelbart illustrates this concept with a simple question, “Would you rather go across town on a tricycle or a bicycle?” A tricycle is obviously easier to learn to ride, but clearly nowhere near as efficient as a bicycle. There’s a learning curve from tricycle to bicycle. There’s a learning curve moving away from tried and true traditional methods, to new practices and ways of thinking that will enable us to become more highly functional beings and teams capable of collaboration.
Engelbart devoted his life to a paradigm shift to move us away from our current dysfunctional political and organizational models. Right now, we have no solution to urgent and complex global problems: disparity between poor and rich, environmental problems, evermore dangerous diseases, religious strife—those can kill the human race. (In one extreme perspective, we have proven we are the world’s most destructive virus.)
Engelbart’s framework proposes a new way of thinking about problems—changing the competitive, power-based models and focusing on how to integrate our ideas toward a greater whole.
Engelbart does not offer a formula to follow. The framework necessitates that you start somewhere and build your collective capabilities by learning as you go—improving your tools and practices, reflecting, and using your insight to develop better tools and practices. Do this often, and do this quickly.
That’s the essence of bootstrapping and the co-evolution of human and tool systems. (By the way, some call it “agile” these days.) But it has to be done on a massive scale. If we have a lot of uncoordinated small efforts, or working at cross-purposes, we likely won’t accelerate our achievement of human survival.
As a professional tool builder, I’ve seen too much emphasis placed on the tools and not enough on the human systems. According to Moore’s Law (which even Gordon Moore has acknowledged was inspired by Doug, as reported in the New York Times by John Markoff), we’ve grown multiple orders of magnitude in our computing capacity. Our collaboration skills have seen little improvement— namely, our ability to align, to detect miscommunications early, and to be clear about our objectives.
We are still working off of Robert’s Rules of Order and Quarterly Reports. The ways we measure and manage ourselves is shortsighted. Westerners are surprised to learn that in China, it’s common practice to make 50-year plans. In our society, we don’t sincerely reward people for thinking much beyond the next fiscal quarter or year. Our systems are organized around short-term achievement, rather than in terms of scalability, sustainability and strategic objectives—at the highest levels. It’s sobering to think that our federal administrations think in four-to eight year time frames.
Ironically, Doug’s own teams over the years have not sustained themselves to perform continuing, directed, coherent activity around his vision. Some say Doug is hard to work with. Others say the problem is people do not have the patience for Doug’s long-term vision, so they take a small subset of his ideas and go off to make their fortunes. A third hypothesis is that visionaries like Doug are not skilled in leading groups to deliver. For whatever reason, there has not been a critical mass of people organized around his principles for solving complex, global problems.
Though Doug’s ideas are immortal—and have changed the world in terms of personal computing—Doug is human and has suffered from not being able to carry his big ideas forward. That leaves it to the rest of us, who believe in collective IQ, to figure it out.
I hope we’re not too late.
My dream is to build a community around Doug and his vision for humanity that can rebalance the views, and explore and push the capacity of teams so we can catch up and keep pace with our tools and technological capacity. I’d like to see this applied toward the threats to humanity and our habitat. I’m interested in the modern day rules of engagement. I want to understand what limits teams, and explore ways to counter those dynamics.
I want to understand and bring to light the barriers to scalable collaboration, and am working with others to evolve the means to counter these obstacles. The barriers often seem traceable to miscommunications, misunderstanding, misalignment, fears, and hidden mixed agendas—egos protecting themselves versus the greater good. Self-protectionism keeps people from fully committing to teams. There is a fear their needs will be jeopardized if they commit to the team. All too often, team problems come down to personal fears and the need to “hang onto what you have,” which prevents people from reaching to the higher plane where over-arching goals are aligned.
If we could each put our fears and agendas on the table, and develop effective ways to counter them, then we could unleash our aligned energy toward a higher purpose. We could then begin working together to accelerate toward positive results that, in uncoordinated fashion, would take too long to achieve. Perhaps with conscious massive cooperation, this accelerated ability to solve complex problems could happen in our lifetimes. That would be worth any effort we can imagine.
Doug devoted his life to a beautiful vision, one that we must realize if we are to survive as a race, and as a healthy ecosystem. Doug deserves a vibrant, aligned, collaborative, inspired, dynamic, effective community to carry forth his ideas and his vision. Humanity deserves a chance to see what might be possible. It is also great fun to be a part of such a program: a program for the future.
(originally posted at SVProjectManagent.com)
On Wednesday I mentioned that I carry a digital voice recorder with me at all times. I like to record meetings. I like to record them in person, and I like to use conference call services that make it easy for you to record conference calls (eg. *9, PIN, done).
Though you and I both are trained since early schooling to take notes in “real time”, I can’t but observe that any part of my brain that is focused on writing notes is part of my brain that’s not entirely plugged into the discussion at hand. If I’m writing what was said 2 seconds ago, I’m not spending that brainpower picking up on the nuances of phrasing, of pauses and their meanings, of who’s wanting to follow up or respond, of shifts on body language around the room, of glances between individuals, etc.
On the other hand, if there is a person whose role is scribe, or better yet, VISUAL scribe, who can take the ideas as they float into the “pool of meaning” and give them visual manifestation – as objects on a white board, or on a mindmap, or in Axon representation, or other idea-representation canvas – then it is valuable for the entire team (whoever’s in the discussion) to see the same representation, and give feedback on whether that visual capture of what was said IS what was said. This role of visual scribe isn’t yet a skill that’s often and regularly leveraged in common meetings (even here in Silicon Valley)
So I like to record these meetings (at least the audio) so that I can focus as much as possible on picking up those nonverbal cues so that I can better understand the positions and their shifts around the room as the discussion unfolds. I also like to record these so that I can extract from them specific items that I didn’t pick up the first time around.
That’s the obvious reason for recording these session.
There is at least one more reason I consider recordings important:
Collaboration practices need to evolve. I like collecting these instances of collaboration in order to study them and to see whether the method practiced was effective, comfortable, imposed, emergent, pleasant, top-down, timely, wasteful, confrontational, quick, complete, incomplete, or a number of other dimensions on which I like to study collaborative practices.
As a proponent of evolving collaborative practices, I hold that both human and tool systems must evolve in order to optimize our collective objectives – those reasons for collaborating in the first place. One practice, of which Doug Engelbart is a strong and early proponent, is that a team keeps a permanent and accessible log or journal of all events, including communications. One might see this is one application of the scientific method – always knowing what you did, so that you can trace back what might have led to an observation or result that one later finds one doesn’t immediately understand. This recorded journal – if available – stands as a “ground truth” against which one can base subsequent inquiry, analytical study, or even other methods to study the interaction. This ground truth can then be used to create derivative works, of which action items and notes are only a small and obvious set.
Agile project team values and their embodiment in actual practice are highly subject to personal interpretation on the parts of practitioners, and thus necessarily suffer criticism for its wide-ranging variety of acceptable variations, all claiming to be agile. So a significant percentage of projects that claim to be agile, yet not adopting all of the Agile Manifesto values have at least themselves to blame when they do not produce the results promised and hoped for.
Those projects aside, even considering the projects that are faithfully adopting all of the agile values (early and continuous delivery, welcome change, deliver frequently, daily multi-stakeholder collaboration, support and trust motivated teams, face to face conversation, working software, sustainable development, technical excellence, simplicity, self-organizing teams, and continuous improvement) still often meet with less than ideal results. It’s useful (and necessary) to ask “Why?”
Agile (and Scrum in particular) rely heavily on direct interaction between the business users and the developers. In most projects, it is not possible to get direct interaction between the user communities and the developers, due to a variety of factors.
It is often necessary for someone (typically designated “Product Management” in the old dictionary, but “product owner” in the new) to step into the team interactions, to represent the “customer”.
Done well, this of course has many advantageous benefits.
It is also quite possible to perform this role poorly. In such circumstances, we often see these questions asked:
These questions reveal a lack of certain customer understanding among the development team. It is not sufficient that one member of the team understand these points (usually the PM or PO); it is often not possible to predict when such information can be useful and critical in tradeoff analysis decisions, many made daily by each product development team member.
Therein lies the key omission of Scrum (and most other agile methods): The backlog of user stories are taken as a starting point. They are not examined for their “quality”, “completeness”, “cluefulness”, budget impact, etc. The user stories are assumed “good”, and used as an “input” to the Scrum process.
[These thoughts are work-in-progress towards a white paper Jeff McKenna and I are collaborating to produce. More coming... - Sam][Originally posted at SVProjectManagement.com - Reposted here with permission.]
These (except Augment) are past discoveries that I still use today, though the latest updates to them were more than a decade ago.
What makes good software?
(You may liberally validly insert "for me" or "in my opinion" anywhere in a blog, as you know.)
Here, I'm not so much referring to software that does a precise mission-critical thing very well. There's a role for such software, and these can be specified by "experts" and built by engineering teams. ERP, CRM, HRM, checkbook management, etc. are all very useful categories of software that have defined function, and therefore defined ROI models.
I'm more interested in how the human being can do more, via the tools s/he employs. More in a deeply qualitative sense. I'm interested in software that magnifies the power of a human being, through augmentation and amplification of one's thinking, pattern matching, reasoning, and modeling functions.
Power vs Specification: ERP, CRM, Financial management, etc. applications have no end of feature backlog that product managers can document and justify, in order to flesh out the functionality breadth (use cases, boundaries, NFR's, etc) of an application. The above products were driven primarily by single individuals (or at most, small teams).
Power vs Size: The popular applications these days take entire CD's to install (some several DVDs). But if you look at the applications above, they were each delivered with packages amounting to just a few megabytes.
Non-specific Semantics: Unlike popular applications that embed the semantics of the problem space into the objects and actions of the application, the ones above *don't* exhibit such verticalization. They are "horizontal" in the sense that the objects are very general objects, and that the power of the application lies in the ability of the user to map these objects into the objects of the user's specific problem space.
Therein lies the unfortunate corollary. Due to the non-immediacy (and therefore, perceived relevance) to any specific problem space, these power tools were less embraced, because they didn't obviously help solve any particular individual's problem. The segment of the human population that can appreciate such tools is understandably several standard deviations from the mode, and therefore represent a small (commercially unviable) audience.
Another corollary? Perhaps these need to be removed from commercial relevance. Perhaps the only way these will survive and thrive is via an open source model.
Chan Bok's "Axon" is of course an interesting argument against this corollary. He's been able to keep this alive because he uses a development tool (Visual Prolog) that magnifies *his* effectiveness.