How do knowledge-workers train?

Pilots can practice for real flights using simulators. Sport teams can train for real games through training matches and team exercises. Disaster responders can prepare for real-life events by running simulation exercises. Musicians can rehearse, writers can draft. But what about teams of knowledge-workers? How can we train to prepare for real-life projects? Are we doomed to only learn through theoretical studies or by making mistakes in real projects? Cannot we find ways to practice techniques or spot challenges in the collaboration process?

At Manas we periodically take one or two days off to run different exercises. Sometimes the exercises take the form of an organizational retrospective, other times we do introspections aimed at developing personal mastery, and other times we simply play or build things together. The purpose is to grow both personally and as a team, and to spot areas where we could improve.

There are plenty of team-building games around, but personally, I have always found most of them stale and even childish. There’s obviously a benefit any team gains from spending time together having fun or solving a problem, but I think we can do better.

Here’s a simple game I designed to train for collaboration:

1. Find a “sequential picture story” that has between 4 and 8 vignettes.
2. Cut the vignettes in individual pieces of paper.
3. Split your group in teams the size of the number of vignettes in your story.
4. Give one random vignette to each team member and allow them to take a look at it for a few seconds. Each person should only see one vignette, for a brief period and then return it.
5. Each team goes to a different space where they can work together.
6. The goal is for the team to reconstruct the story and figure out the sequence of events.

Now, this sounds much simpler than what it actually is. Here’s what happens:

1. The team needs to agree on a way to share their portions of the story with the rest. They might simply share it verbally or decide to draw a sketch of what they saw.
2. Without the context of the full story, it’s not easy to understand the meaning of each individual vignette. Since individuals have to rely on their memory, the process of translating their observations (objective) into interpretations (subjective) and communicating those to the team, triggers all sorts of biases and confusions.
3. Once all portions of the story have been shared, the team needs to converge on a process to define the overall story arch. A well-knit horizontal team might do this effortlessly, a team with a strong leader might unconsciously relinquish that responsibility, while a group of strangers will probably go into a more chaotic situation where each individual defaults to their personality comfort mode.
4. The team will finally need to find a way to process disagreement and come up with a single proposal of what the story might have been.

The whole process takes less than half an hour but it’s a great micro-world that reflects the tensions of a real-life project. Here are a few of the lessons that are easy to extrapolate from this exercise:

We each have a part to contribute to the project

Nobody saw the whole story; each and every member had something that the rest needed in order to put the story together. Reminding ourselves that the story we are trying to build is much bigger than the vignette we have in our minds, can help us learn to hear what everybody has to share and contribute.

Our contributions only

make sense when they fit coherently into the whole

In our game, teams had to struggle until each and every contribution was put in the sequence in a meaningful way. That is not the case in real-life scenarios, as sometimes individuals need to accept that they might not have much to contribute to a particular project. A nice variation to the game, to simulate that situation, would be to introduce a vignette from another story into the pool. The team would have to resolve the incoherence and the individual would have to let go of his ego and accept there might not be a contribution from him this time.

Horizontal collaboration does not mean undifferentiated roles

To achieve their goal, each team relied in horizontal collaboration, in which the contribution of each and every member had to be valued and fit into the whole story. Nevertheless, differentiated roles, mainly leaders, quickly emerge in almost every team. A single information-hub (usually acting as leader) is still our best shot a building a coherent story. The key difference was whether the leader acted as facilitator, organizing the discussion between all the team members and ensuring that all voices were considered, or imposed his or her will on the rest of the team, trampling their essential contributions which were required to reach the common goal.

Learn to recognize and use individual expertise

I have facilitated quite a few groups where we realize too late that we have the perfect expert in the room. Particularly in ad-hoc groups (think hackathons, design workshops, etc.), if the experts aren’t very outspoken or assertive, their relevant expertise might go undetected.

In one of the game teams, one member had an uncanny familiarity with the Hansel & Gretel story, immediately recognizing it just through his single vignette. His colleagues quickly trusted him and they started fitting their vignettes into the sequence without questioning the story they were trying to put together. Across the room, someone in another team suggested the same thing, but they failed to detect the valuable ‘expertise’ and pushed on without knowing what the story was about.

Be ready to change the framing if it’s not working

One of the teams was blessed with a very creative member that quickly put together an amazing but convoluted story. However, once a competing but simpler solution was proposed, the team applied Occam’s razor principle and gravitated towards it.

The team that had the Hansel & Gretel “expert” could have gotten stuck in a similar way: if the story were a different one that happened to be similar to the Grimm Brothers tale, the team would then have had to overcome the Confirmation Bias, contradict the “expert” and come up with a new framing.

During projects, and particularly after the initial phases, we need to be watchful not to assume that just because we have been using a specific framing or model until that point, then we need to stick to it for the rest of the project. It’s usually the sunk cost fallacy or familiarity bias what keeps us pushing through with a model that is not working. Awareness of those tendencies, and willingness to step out of comfort zones and experiment, are key to finding the best framing possible.

Verbal communication is less ambiguous and therefore less accurate than other methods

This one is hard to see in real-life but becomes very tangible through this exercise. When teams tried to describe what they saw verbally, they had to chose words to name characters or objects, sometimes forcing themselves to be more specific than what they were certain of. A stick figure with a hat can play many roles during the ‘whole-story fitting’ process. In our game, different members described the same character with different subjectivities playing out, and what was a boy with a hat for one, was a policeman for another. It took them a while to realize they were talking about the same character.

Sketching the vignettes allowed individuals to communicate the level of detail they recollected with less subjective interpretation; the team could quickly visualize the sum of the parts

Very often we see ourselves moving out of ambiguity too soon and solidifying on a premature conclusion. Lack of ambiguity does not imply precision. You can be vaguely right or precisely wrong. The trick is to learn when to choose one option over the other.

Teams that sketched what they recalled from their vignettes had an easier time finding the underlying history. The lesson here is that during explorative phases of a project, we have to use ambiguous representations of our ideas in order to build a coherent whole . A paper sketch is preferred over an Illustrator wireframe; a quick informal voice call is prefered over a carefully written document.

Allow your contribution to be re-signified by someone else’s

The contribution that someone else brings to the table might re-signify our own. We have to be open to let go of the attachment to the interpretation of our own contribution. We could be sure that we saw a policeman taking care of a lady, but if everybody else is talking about two kids, maybe it’s time to attempt to reinterpet what we think we saw.

In real-life projects, when there are conflicting goals, the best way to work through the contradiction is to verify the underlying assumptions. Often, a change in the agreed assumptions will dissolve the conflict and align individuals again behind the same goal.

We wrapped up the game with a group conversation and sharing of reactions. Overall, the game provided a fun and engaging activity and a kinesthetic ground to experience some of the typical challenges of the design and development projects we do.