MGTaylor – Eugene Eric Kim

Babble Voice Privacy System

Published November 24, 2007 by Eugene Eric Kim

Kirsten Jones recently pointed me to Herman Miller‘s Babble Voice Privacy System. Babble is a small device (about the size of a tape player) that takes sound within a certain radius and rebroadcasts it as nonsense. In other words, it allows you to have private conversations in open spaces. (MQP)

Babble is being marketed as a privacy device, but it’s actually an important productivity device. People are good at ignoring white noise. When our brains hear sounds they don’t recognize, they ignore them. People are bad at ignoring recognizable sounds. Every ambient conversation we overhear is a concentration breaker. (MQQ)

The list price for a Babble is $695, which is steep for most mortals. However, there’s a simple trick you can use for similar effect: music. People do this all the time on their own: When they need to concentrate, they put on their headphones. However, you can do this for an entire space as well. (MQR)

The added benefit of using music in this way for Open Space-style events is that you can use this as a transitional device. Raise the volume when you want people to move, and lower the volume when you’ve achieved your goal. MGTaylor does this all the time, but they’re not the only ones. Open Space facilitators often use Tibetan prayer bells to signal transition. Allen Gunn (Gunner) will often start singing when he wants people to transition. (MQS)

Cisco’s Workplace of the Future

Published November 23, 2007 by Eugene Eric Kim

I’m a big fan of Cisco Systems. Sure, they’re a $200 billion behemoth. But they don’t act like it (not in an anti-competitive way, at least). They make quality products, they acquire great companies for good reasons, and they seem to generally care about bootstrapping and collaboration. My colleagues at MGTaylor and the Value Web have done quite a bit of work with Cisco and John Chambers, and they’ve only said good things about them. Cisco also used to have an internal research group focused on collaboration that was doing great work, although I don’t know if it still exists. (MPX)

A good friend of mine works there and had been promising me a tour of its “workplace of the future” for quite some time. A few years ago, Cisco designated one floor in Buildings 11 and 14 as experimental spaces, designed to be a more collaborative environment in today’s network world. My friend had spoken glowingly of portable workspaces, movable walls, and open space, and I was excited to see it for myself. (MPY)

This past Monday, on my way down to Southern California for the holidays, I stopped at Cisco for my promised tour. As we walked over to Building 14, my friend told me that employees who worked there had complained about the space, particularly the lack of private space to get work done and a “home base” they could call their own. (MPZ)

I got my first experience of the “workplace of the future” in the lobby, where a virtual receptionist badged me. The space was like any receptionist area, except there was no receptionist. On the desk, there was a badge machine, and behind the desk, there was a large LCD screen with a camera. We pressed the button, and a person appeared on the screen. My friend identified herself, explained who I was, and out popped a badge. It was cute, but gimmicky. I’d be curious to know how much money they save (if any) by doing this. (MQ0)

Then, the coup de grace: the space itself. The first thing I noticed was the eating area, an enclosed circle at the center of the space. “A Watering Hole, positioned nicely,” I thought. Next, I noticed rows and rows of lockers. (MQ1)

Then I noticed the cubicles. Rows and rows of cubicles. “When do we get to see the space?” I asked my friend. Then I saw the look of shock on her face, and I realized that we were looking at it. Cisco had given up. They had listened to the complaints and had replaced their experimental space with cubicles. (MQ2)

My friend felt really bad, but I wasn’t disappointed, not by the tour at least. (Not that I passed on the opportunity to poke fun at her and Cisco. “So this is the workplace of the future?” I asked. “Looks an awful like the past to me.”) There were some great lessons to draw from the experience. (MQ3)

First, designing effective spaces is hard. It’s one thing to design an effective collaborative space; it’s another to design an effective work space for lots of people. You have to account for the Intimacy Gradient, and if there’s cultural change involved, you have to decide whether the cultural shift is actually desirable. (MQ4)

Second, good companies aren’t perfect. I need to find out why exactly they changed the space, but the fact that they reverted to cubicles disappointed me greatly. It’s one thing to make a mistake; it’s another thing to give up entirely. If any of you know the story behind these spaces, I’d love to hear it. (MQ5)

Group Information Hygiene

Published January 3, 2007 by Eugene Eric Kim

Last August, I wrote: (LPS)

When we founded BlueOxenAssociates, we were supposed to be a place for those on the cutting edge of collaboration. I quickly discovered that most people who want or claim to be on the cutting edge are held back by poor PersonalInformationHygiene. People need to start with themselves before they worry about the group if they want to improve their ability to collaborate. (This is a general theme that extends beyond KnowledgeManagement.) T (LPT)

Poor Personal Information Hygiene can often interfere with group trust, and trust is a prerequisite for good collaboration. (LPU)

In an ideal world, everyone on your team would be masters of Personal Information Hygiene, but in reality, that’s rarely the case. Frankly, I’m not sure if it’s always desirable. People have different kinds of intelligences, and it may be that certain kinds of intelligences are critical to a high-performance team, but are also orthogonal to good Personal Information Hygiene. (LPV)

Is it possible to have good Group Information Hygiene if people on a team have poor Personal Information Hygiene? Moreover, is it possible for the whole to be greater than the sum? (LPW)

You all know what my answers are. (LPX)

Part of the MGTaylor facilitation philosophy is to offload all potential distractions so that the participants may focus entirely on the task at hand. When you attend an MGTaylor Design Shop, there are several Knowledge Workers present, who are responsible for managing the distractions (among other things). They set up and reset the environment. They scribe your conversations. They manage the clock. (LPY)

The philosophy is not exclusive to MGTaylor. The Aspen Institute follows a similar process. So do high-level politicians and actors in big-budget films, where their schedules are minutely managed so that they can focus entirely on acting… er, and policy-making. So do fancy restaurants. The food at Gary Danko in San Francisco is fantastic, but the service is unbelievable. There are literally six servers hiding in the shadows, anticipating your needs and making sure your table space is always pristine. Your glass is always full. Your napkin is always folded. If you’re about to go to the bathroom, a server will pull out your chair and point you in the right direction. Remarkably, they pull this off without being overbearing and creepy. (LPZ)

We can debate whether or not this is always a good thing. (I think the answer is no.) We can certainly agree that this level of service is not always practical. What’s indisputable is that in a collaborative situation, these things need to be done by somebody. The question is by whom? (LQ0)

The Sacrificial Lamb (stolen from Jim Coplien and Neil Harrison‘s SacrificeOnePerson pattern) is both a pattern and an antipattern. Most of us are familiar with it as an antipattern, where someone “takes one for the team” and essentially does someone else’s job because that other person isn’t doing it. (We discussed this in great detail at last year’s St. Louis Collaboratory workshop.) (LQ1)

When it’s a result of broken trust, Sacrificial Lamb is short-term positive, because the job gets done, but it’s long-term negative because it hurts your working chemistry and often overloads your most productive team members. When it’s intentional and explicit, it’s net positive, because it’s not breaking any trust relationships. The essence of Jim and Neil’s pattern is that instead of dividing the necessary but dreary tasks among multiple peers, you designate one person as the Sacrificial Lamb and that person handles all of those tasks, at least for one cycle. You increase the likelihood of the tasks getting done and getting done well, and you increase the productivity of your other team members. If done right, the whole will be greater than the sum. The Knowledge Workers in the MGTaylor process are essentially Sacrificial Lambs. (LQ2)

The role of the Sacrificial Lamb is most often to maintain good Group Information Hygiene. Project managers will find this role familiar. For example, when scheduling meetings, you send frequent reminders, both to compensate for others who are not good at maintaining their own calendars and to correct potential miscommunications. These tasks are laborious, but they’re necessary for High-Performance Collaboration. (LQ3)

Collaboration can be a difficult thing to measure, but measuring Group Information Hygiene is relatively easy. I used metrics associated with Group Information Hygiene extensively with a client last year as one indication of the state of collaboration within the community and the potential for improvement in the future. Poor Group Information Hygiene is a natural obstacle to scale. (LQ4)

Visual Thinking and Shared Understanding

Published October 26, 2006 by Eugene Eric Kim

One of my favorite conference moments occured at the Computers and Philosophy 2002 conference, where both Bob Horn and I spoke. I sat next to Bob during the other talks and peeked over his shoulder as he took notes. That man is insane. My notes are barely legible scribbles; his are pristine visual diagrams. (LEX)

A few years later, I got to work with Bryan Coffman at the MGTaylor 7-Domains Workshop. As with Bob, I got to see Bryan’s notebook and concluded that he also was insane. (LEY)

Visual languages are extremely powerful and totally underutilized in collaboration today. Part of the reason for this is that the techniques seem inaccessible. If you can’t draw a straight line, you’re probably not going to be doodling your notes, much less doing it live on a whiteboard in front of a crowd of people. Tools like Compendium and Mind Mapping are great in this regard, but they represent only a fraction of what’s possible. (In the case of Compendium, I think it’s question-orientation is as important, if not moreso, as its visualization capabilities.) (LEZ)

When I found out earlier this month that one of Dave Gray‘s mentors was Bob Horn, I told him I had to peek at his notebook. No problem, said Dave. He posts many of his sketches on Flickr. (LF0)

Dave also told me about an exercise he likes to do at his workshops, which is to ask participants to draw a diagram of a toaster. You can see the results from a workshop he recently did in Toronto. I like this exercise a lot, because it shows the very different ways that people think about a relatively mundane device in a very concrete way. Each of those pictures are clearly different, but they are all also accurate. (LF1)

This technique is great for building Shared Understanding, and there are all sorts of great variations. You can have people draw, build things, and so forth. Luke Hohmann had us design cereal boxes at DCamp last May that would make people say, “DCamp — gotta buy that conference!” (LF2)

Michael Eakes recently blogged about a sixth grade exercise, where the teacher asked her students to draw Mickey Mouse from memory. (LF3)

(LF4)

Read Michael’s analysis of the variation; it’s fascinating. (LF5)

Developing Shared Language

Published June 9, 2006 by Eugene Eric Kim

Drummond Reed recently wrote about the Identity Rights Agreements session at last month’s Internet Identity Workshop. While the outcome was fruitful, Drummond wrote, “The biggest frustration was that after an hour and fifteen minutes we were just really getting started – we needed a good half-day on the subject.” (KNJ)

Jamie Dinkelacker told me a similar story last year in describing a SOA gathering of gurus. The goal was to share knowledge and to advance the state of the art, but the participants spent most of their time arguing over the definition of “services.” (KNK)

The problem in the first case was with expectations. The participants should have expected some ramp-up time would be necessary to get started, because they needed to establish some Shared Language. The problem in the second case was with process. The participants did not have an effective strategy for developing Shared Language, and thus, the latter ended up monopolizing the whole workshop. (KNL)

Shared Language is a prerequisite to collaboration. Without Shared Language, we can’t collaborate. It’s as simple as that. When a group tries to collaborate without having Shared Language, the group will try to create it, whether it’s aware of it or not. This creation process is often frustrating and painful, and as a result, people sometimes try to skip this step or belittle the process. This is a problem. You can’t skip this step. (KNM)

When designing collaborative spaces — both online and face-to-face — you have to build in time and space for developing Shared Language. (KNN)

If you examine every good collaborative, face-to-face process for large groups, you will find that all of them generally recommend a minimum of three days. I haven’t found a rigorous explanation for why three days work so well, but the pattern is consistent, and we can certainly speculate. Much of it has to do with building in enough time to develop Shared Language. (Michael Herman, Open Space facilitator extraordinaire, has suggested that it’s less about the three days and more about the two nights — having our minds go through two natural work-process-rest cycles. I think he’s onto something.) (KNO)

The first day is always about developing Shared Language. MGTaylor calls it the “Scan” day. Phil Windley calls it the “butt-sniffing” day. Regardless of what you call it, you need to design for it. It’s going to happen whether you like it or not. The question is whether or not it will happen effectively while leaving time for action. (KNP)

There are two myths regarding how you create Shared Language. The first is that “shared” is equivalent to “same.” They’re not. Shared Language means that you understand how others around you are using terminology. Some level of sameness is obviously useful, but when you’re dealing with something relatively complex, sameness is both impossible and undesirable. (KNQ)

I devised a metric several years ago called the Squirm Test that’s similar in concept to Wikipedia‘s Neutral Point Of View. The test is simple. Sit your team around the table. Have each person stand up and give a brief project description and status report. During the pitch, no one is allowed to talk, other than to ask clarifying questions. You have a perfect level of Shared Understanding and Shared Language if you make it around the room without anyone squirming. (KNR)

The second myth is that creating Shared Language consists of creating a dictionary. That’s certainly one way to approach it, but it’s not the only way, and often times, it’s not the best nor the fastest way. (KNS)

There are three elements to creating Shared Language: (KNT)

Share individual contexts (KNU)
Encourage namespace clash (KNV)
Leave enough time and space to work things out (KNW)

Sharing individual contexts is a fancy way of saying, “Know your audience.” Or, more accurately, know who you’re working with — their world view, their values, etc. You don’t have to use the same terminology the same way; you just have to understand what people mean and where they’re coming from. For some techniques on how to do this, see Collab:KnowTheParticipants. (KNX)

I’ve written many times about how Wikis and tagging encourage namespace clash, which in turn encourages Shared Language. From a facilitation standpoint (both face-to-face and online), if you pose questions that stretch the mind, you also draw out namespace clash. MGTaylor is especially good at doing this with its Design Shops. Allen Gunn uses a technique called a spectrogram where you stretch a piece of masking tape across the room, ask a controversial question, then tell people to go to the place on the tape that represents their position on the question. You then ask people along the spectrum why they’re standing where they’re standing, and you give people the chance to move around based on other people’s answers. If you ask the right question, you’ll not only quickly get a great sense of your audience, but you’ll also draw out different interpretations of language. (KNY)

Finally, simply scheduling time and space where Shared Language is the primary goal is useful. People are good at figuring out how to communicate with each other if you give them the space to do it. If you set unrealistic expectations on the first day of a three day event, then you just stress out your participants. If you spend the first day exploring broader questions, your participants may feel flustered or frustrated, but they will find that the work goes much more smoothly in the ensuing days. (KNZ)

Developing Shared Language is an ongoing process. Doing actual work is one of the best ways to build shared context, which in turn builds Shared Language. The trick is to have stagger your work goals based on the Shared Language that already exists. The exercises you go through can become more and more focused over time, as the amount of Shared Language increases. (KO0)

At the Blue Oxen Associates Tools for Catalyzing Collaboration workshops — one-day workshops with about 25 participants — we don’t do participant introductions. We assign teams and have people go straight into their exercises. However, we pay careful attention to how we assign the initial teams, and we structure the exercises accordingly. For example, at our January workshop, we started by pairing people who either already knew each other or were in similar fields, and we had them start their exercises immediately. We then grouped pairs and had them present their work to each other. Finally, we had a plenary session where each group reported on their work, followed by a plenary discussion. Our participants were engaged right away, and the shared experiences acted as an icebreaker, which made it easier to meet new people and to talk in our designated networking times (e.g. lunch). We also had online profiles up on our Wiki, so that people could find out more about the other participants before, during, and after the workshop. Several people commented afterwards about the lack of group introductions. All of them liked it. (KO1)