Collaborapology

Scaling Human Capabilities for Solving Problems that Threaten Our Survival

2011-02-21T15:33:00Z

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

A “Journaling” Mindset

2011-02-01T14:25:00Z

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

Simple skills, like learning to count…

2011-01-23T01:02:00Z

Luckily for me, I learned how to count in early life… probably elementary school. Or sometime… (This used to be called math, for those of us who are not math majors.)

I find now that learning to count was a pretty good skill, once I learned how to apply the skill.

I am a pretty forgetful person. Perhaps it’s my age. Perhaps it’s my nature. (Perhaps it’s irresponsibility.) For whatever reason, remembering details is not one of my strong characteristics. This used to manifest itself when I’d go somewhere, and forget my wallet, or keys, or cell phone… So now I count to 8.

I count to 8 thusly:

Money clip with credit cards
Office keys
Car and house keys
Apple iPhone
HTC Incredible Android phone
Flip mino HD video camera
Olympus 7600PC digital voice recorder
Samsung Bluetooth headset

Usually this is accompanied by a pat-down of self as I physically verify as I’m counting that each item is in my possession. (Your number would likely be different from mine.)

OK, this is pretty trivial. But you can’t believe how often this has saved me from a missed opportunity. Any time I see or walk through a door (office, home, car, etc), I do a quick mental count to 8. This habit had to be learned in at least 3 steps.

First, I had to realize this would be a useful habit to establish. (need or problem-driven realization)
Then I had to decide how many items would be on this list. (design the solution)
Third, I had to develop the habit of actually applying the counting skill (knowing WHEN to recall this skill and practice it)

Learning a skill and Learning WHEN to apply a skill are two separate cognitive contexts.

I went through too many years of not applying this counting skill though I clearly KNEW how to count since before I was riding a bicycle. Learning that this skill could apply in real life took a while longer to integrate into my habits. I had to pass through too many locked doors to realize that “passing through a door” was a key trigger that made counting a relevant skill. So now it’s a habit I’ve cultivated that’s made life simpler and made me look less forgetful.

In the larger picture, so what?

I’m in possession of a lifetime of acquired skills. I’ve gone through (more than a couple decades of) schooling and job experience.

I wonder what other skills I am sitting on that I’m not yet applying yet to make my job performance or life experience “better” in some sense? Simple skills get ignored or overlooked too easily. Too often, I think that the hard stuff is the important stuff. In actuality, the easy stuff can still make life and job results significantly better, if we only realized the “new” contexts in which to apply the skill.

What skills and simple practices have you and your team found effective in past contexts, but are not currently applying in your current position / project?

Idea #1 in Agile

2011-01-17T22:37:00Z

(originally posted at SVProjectManagement.com )

Agile isn’t about producing products faster than other methods. Agile isn’t about working faster than other people.

The single most fundamental concept in “agile” is the speed of feedback.

There are at least 2 very important sources of feedback that can be leveraged in this way.

One is the work accomplished to date, seeking confirmation and reaction from its potential customers / users / buyers. Users’ experiences with a product can provoke appropriately creative new ways to extend that product, or product concept. These are ideas that weren’t stimulated into existence PRIOR to an interaction with that product. Action sequences can be reorganized, refactored, based on mockups, prototypes, and indeed, even complete iterations on infrastructure and end-to-end use cases or user stories, as the work takes shape. This is appropriate and ought to be leveraged by teams with good work practices – why let good ideas go to waste just because they weren’t in the “signed off spec”?

Another is life itself. What can break other execution models and methods is that in the time it takes to perform a a plan, or even just a single stage of a plan (be it specification, elaboration, design, coding, etc.), the world can change in the time it takes to perform that stage. Big plans have big components of the plan, typically. These stages take time to perform. If during this time, the world (read: customer needs, business ecosystem, market conditions, world events, available technologies…) changes, then there is little opportunity to reflect these changes, except via laborious and high-overhead (speed-killing) “change control boards”. So viewed this way, you can see that complex plans that involve months of execution, where planning is done in detail up front, historically haven’t accommodated the “life changes” reality of “s*** happens”. If you cannot adapt a plan to the reality of business, as it happens, then you operate in another world than the one you’re trying to execute in.

Corollaries

1. You don’t have to consider or adopt agile if your world isn’t likely to change much (id est, the ways you plan and execute aren’t going to be changed much by days that pass by). Perhaps the construction industry is like this. Perhaps flower shops, or dental offices. (In our business, maybe accounting software…?)

2. You don’t have to consider or adopt agile if your user customers’ experiences with your product isn’t like to change, and you are quite familiar with those experience modes and patterns, and can predict

3. If your world *does* change… as in plans could be affected by world events, details that are only realized as prototypes become available, then what in your current methodology allows you to adapt to such change? Is it that you can reneg on commitments? Is it that your colleagues and/or customers are just really “reasonable” and tolerant? or do you need something more explicitly aware that such change is not just possible, but likely?

The Take-Away

Inertial guidance systems that controlled expensive long-range missiles gave way to real-time dynamic control systems that could course-correct on the way to a target. Point, shoot, and hope-for-the-best was fine when that’s all that was available. With expensive business weapons like teams of software engineers and architects would your business trust a point, shoot and hope-for-the-best method of execution, if real-time dynamic course-correcting methods are available?

What's the Difference Between Theory and Practice?

2010-08-01T20:02:00Z

In theory, there is no difference.

Is Agile Enough? (part 1)

2007-09-02T21:56:00Z

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.

Customers aren’t bothered to spend large amounts of time with product development teams
The PM / PO can distill the multiple wants and desires of a large user community and arrive at the crystallization that is the core of what the community appears to be asking for, but in different ways and words

It is also quite possible to perform this role poorly. In such circumstances, we often see these questions asked:

“What is the customer really doing with this feature?”
“How often is this done?”
“Is this more important, or is that?”
“Is there a way to cut back a little on this fancy feature, so that at least the user / customer is happy, without taking another 2 months of development time?”
“My design had to change this way; what customers are affected?”
“How much business is the company going to get with this feature?” and of course the related “If I do it this way, how much more (or less) business will the company see?”
“Where is the customer when they are doing this?”

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

The Best Underappreciated Software Applications

2006-12-09T17:57:00Z

Chan Bok - Axon
Lotus - Improv
Arabesque Software - Ecco
(That's right: Arabesque, not NetManage...
NetManage didn't do a clue-influenced act with this acquisition)
Living Videotext - More
Douglas Engelbart - Augment

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.

What looks like step 1... Just the next step in a long sequence from 1995

2006-06-09T15:18:00Z

In summer of 1995, StoneSpring.org was one of the first 20,000 domains registered on what is currently known as "the internet". In those days, there was no domain registration alternative other than what is now "Network Solutions" part of Verisign, the government-authorized monopoly that charged $35/year for domain registration. My first ISP was Aimnet, staffed by local and knowledgeable people, (since aquired by multiple companies, now via Mindspring a part of Earthlink). There were no web-based blogging or site authoring tools back then; I used emacs via a shell account (and ange-ftp) to manage the site.

I've been through many ISP's. In 1993 I was one of Bob Parson's first customers at Netcom. I tried AOL back before they became notorious for shiny coasters, when they used to send the stiff "floppies". I was one of PacBell's first DSL customers, signing up the very first month that was available in my neighborhood. (Since I was within 5000 feet, I was able to get 1.5Mb downlink right away on a standard retail account. I was also given a static IP; this was before they standardized on DHCP to their DSL customer.). I've been through Aimnet, Netcom, AOL, Compuserve, Mindspring, Earthlink, PacBell, SBC (now AT&T), GoDaddy, and probably many others I've forgotten to mention.

I was "blogging" on StoneSpring.org before it was even understood by most of the current bloggers. I remember being awarded a "10" rating by site rating services, back when encouraging good site content and design was a way to support the growth of the internet. I used StoneSpring.org as a family blog site, posting updates on the kids, easily accessible by other family members (every family member was in a different time zone, even back then), and then extending to the larger family network of my grandfather's descendants (on my dad's side).

And to add to some more trivia: I was a witness to emails sent when the internet was only a handful of non-government nodes (other than the government sites when it was Arpanet): sitting in HT Kung's office at Carnegie Mellon University while he was sending email to someone at Stanford, in the summer of 1976 (and sitting in on an APL class there that was one of the most turgid and incomprehensible hours of my life).

So, yes, I've seen "the internet" evolve, devolve, become useful, become abused, and yet it is still only a sliver of its potential for peoplekind...