Bucky Fuller, Trim Tabs, and Trains

Posted on Published by Eugene Eric Kim

One of my great deficiencies is my lack of literacy regarding Buckminster Fuller, someone who has greatly influenced many people in my sphere. Last Friday, I was having lunch with Kaliya Hamlin, Karri Winn, and Tiffany Von Emmel at the beautiful Thoreau Center in the Presidio. Kaliya was explaining my philosophy about identifying the pain points in order to catalyze a system, and Karri responded, “Oh, like a Trim Tab.” Kaliya and Tiffany both nodded their heads, while I just looked confused. So Karri explained to me what a Trim Tab was, and it is an apt metaphor indeed. Bucky Fuller explained it best in an interview with Playboy in 1972:    (M8W)

Something hit me very hard once, thinking about what one little man could do. Think of the Queen Mary — the whole ship goes by and then comes the rudder. And there’s a tiny thing at the edge of the rudder called a trim tab.    (M8X)

It’s a miniature rudder. Just moving the little trim tab builds a low pressure that pulls the rudder around. Takes almost no effort at all. So I said that the little individual can be a trim tab. Society thinks it’s going right by you, that it’s left you altogether. But if you’re doing dynamic things mentally, the fact is that you can just put your foot out like that and the whole big ship of state is going to go.    (M8Y)

So I said, call me Trim Tab.    (M8Z)

(I did a little research after lunch that day, and ended up incorporating what I had learned into Wikipedia.)    (M90)

The Trim Tab story reminded me of a puzzle I heard on Car Talk almost ten years ago. A train with 750 cars has stopped in a freight yard. It starts to move, when the engineer realizes there’s a problem with the caboose. The engineer stops the train, they remove the caboose, and the engineer tries to start again. But the train doesn’t move. What happened?    (M91)

The train doesn’t move because the couplings between each car are rigid. When they’re rigid, the engineer is essentially trying to move the entire train at once. You have to back up before you can move forward. This loosens the couplings. Now, when you start the engine, you’re pulling one car at a time, building momentum as you go.    (M92)

The lessons?    (M93)

  • Small shifts can catalyze great change.    (M94)
  • Sometimes you have to back up before you can move forward.    (M95)

April and May Gatherings

Posted on Published by Eugene Eric Kim

Normally, I love to travel, but last year tested that love. I was out of town almost twice a month for work. It was exhilarating, exhausting, and ultimately, too much. I resolved not to travel for the first four months of 2007. It’s now April 2007, and I’ve successfully fulfilled my resolution (depending on how you count), wonderfully refreshed and ready to travel again.    (M5D)

As I noted earlier, I’ll be in Baltimore next week for Creating Space VIII, the Leadership Learning Community‘s (LLC) annual gathering. The theme is Collective Leadership. They’ve already got record attendance, and I believe registrations are still open, so if you’re in the area and want to attend, I encourage you to register. I joined LLC’s board late last year, participated in some of their gatherings, and was blown away by what I saw. Can you tell I’m excited?    (M5E)

Next month, May 2-3, I’m co-chairing the Compendium Institute‘s 2007 workshop at the NASA Ames Conference Center in Mountain View, California. It’s going to be awesome — highly practitioner-oriented, with lots of close interaction with some of the most experienced folks in our community. If you’re already a Compendium user, or if you’re interested in learning more, I strongly encourage you to register and attend.    (M5F)

May 14-16 is Internet Identity Workshop 2007a, once again at the Computer History Museum in Mountain View. There will be some major Identity Commons announcements there, as well as cool demonstrations of the latest advancements in interoperable Digital Identity systems. If you’re at all interested in the identity space, I strongly urge you to register.    (M7H)

I get a day to recover, then it’s off to Montreal May 18-20 for RoCoCo (RecentChangesCamp Montreal), hanging out with my fellow Wiki compatriots and other community builders. I’ll be releasing a vision paper on Wiki interoperability that same week. I’ve had tremendous fun researching and writing it, and I can’t wait to hear my community’s reaction to it.    (M5G)

Finally, I just joined the advisory board of Tiffany Von Emmel‘s Dream Fish. They’ll be holding a workshop on Leadership for Sustainability on May 30 in San Francisco. It will feature four outstanding teachers, including Alexander Laszlo and Kathia Laszlo, two of the smartest and most decent people I’ve ever met. Register before the end of this month for a discount.    (M5H)

Talking Technology

Posted on Published by Eugene Eric Kim

Todd Johnston posted an outstanding summary of our informal session this past Saturday. He mentioned our first exercise, which was to have Todd, Gail Taylor, and Tiffany Von Emmel explain how email worked to Matthew O’Connor and myself, who had had sudden bouts of amnesia. Todd wrote, “This exercise, as you may imagine, did a lot to uncover assumptions, vantage points and metaphors we use to shape our understanding.”    (LX9)

The point of the exercise was two-fold. First, we wanted the group to have a better understanding of how the Internet worked. Second, rather than tell them how it worked, we wanted them to figure it out by thinking through the problem. Most of us have the mental tools to understand technology; we just choose not to use them. We wanted to get them to use them.    (LXA)

What was interesting about the exercise was that they did an excellent job of drawing a basic conceptual picture. However, when Matthew and I started asking probing questions to help fill in the gaps, they abandoned their mental models and started reverting to buzzwords. They mentioned things like packets and algorithms and server farms, all of which demonstrated knowledge of Internet lingo, but none of which was necessary to explain how email worked.    (LXB)

Matthew pointed out that techies often do the same thing. When confronted with basic questions about technology, they often start throwing around concepts and language that aren’t critical to the core question. In these cases, they do this because they’re unaware of the other party’s mental models and are feeling around for context.    (LXC)

Why would non-techies do the same thing? In this particular case, it was for the exact same reason. Even though Matthew and I were playing dumb, they knew that we knew the answers. When we started asking questions, they abandoned their model and started feeling around for the answers we might be looking for, hence the lingo.    (LXD)

When one person has knowledge that the other person doesn’t have, that often results in a power relationship, and power relationships affect how people behave. What makes this relationship dangerous is when people assume that this knowledge is somehow sacred and unattainable. Many non-technical people are guilty of this. It’s evident when people preface their statements, “I’m not a techie,” as if that makes them incapable of understanding technology. It’s an attitude problem that stems from fear.    (LXE)

The important thing is that everyone is capable of understanding technology. Don’t let those supposedly in the know bully you away from being confident in what you understand and what you don’t understand.    (LXF)

On a separate note, Todd also describes Finding Your Hey, an exercise that the band, Phish often performs. Todd first told me this story two years ago, and I dutifully blogged about it, but I didn’t know what it was called, and I didn’t know the exact quote. It’s a wonderful story.    (LXG)

Collaboration as a System

Posted on Published by Eugene Eric Kim

I spent this past Saturday in Sebastopol “tutoring” Gail Taylor, Todd Johnston, and Tiffany Von Emmel on online Collaborative Tools. I lured Matthew O’Connor into helping by boasting of Gail, Todd, and Tiffany’s deep thinking about and practice of collaboration.    (LVC)

One of our exercises was to walk through all of our respective digital workspaces, demonstrating how we read and wrote email, and worked with online tools. I had gotten some idea of how Matthew worked when we paired at the Wikithon earlier this month, but I was still blown away by his walkthrough. He’s really thought deeply about his work processes and has optimized his online workspace accordingly.    (LVD)

Matthew expressed surprise that he was the only one who had done this, especially since I had proclaimed these folks to be gurus. I didn’t have a chance to discuss this with him on Saturday, so I thought I’d post some thoughts about that here.    (LVE)

To be good at collaboration, you have to treat it as a system. That system includes things like communication, community, Knowledge Management, learning, and leadership.    (LVF)

Most Collaborative Tools companies are either in the communication or the Knowledge Management business. They’re usually selling pipes, PIMs, or document management tools. All of those things have something to do with collaboration, but they are not in and of themselves collaboration. Then again, no tools are. A hammer is a tool for hammering, but it is not itself hammering.    (LVG)

When I think about High-Performance Collaboration, I envision groups with excellent Group Information Hygiene. Ideally, you’d also like every member of the group to have outstanding Personal Information Hygiene (like Matthew), but it’s not a prerequisite. You’d like to see every member to be past a certain threshold of competence for all aspects of the system, but I don’t think it’s necessary for everyone to be great at all those things. On a great basketball team, you’d like everyone to be in good shape and have good fundamentals, but some players are going to be superior shooters while others will be great rebounders. It’s not necessary, nor realistic, nor possibly desirable to have 12 Magic Johnsons on a team.    (LVH)

Implicit in my One Small Change post is that there is no one thing. I can think of a number of small, concrete changes that could result in significant improvements in collaboration. This is one of the main reasons why Pattern Languages — collections of named, concrete patterns — are fundamental to The Blue Oxen Way.    (LVI)

Personal Information Hygiene is a critical pattern, because it fosters trust. My advice to groups with trust issues would be to eschew squishy exercises and look at people’s Personal Information Hygiene instead. However, past a certain level, I don’t see great Personal Information Hygiene as being the primary hallmark of a great collaborator.    (LVJ)