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)