This is the third “Pattern” in a proposed “Socio-technical Pattern Language” that aims to capture best practices in collaboration and coordination at various levels of organization from having a civil society to having small groups work in ways that are: 1) enjoyable in the moment, 2) productive in terms of the end-product, and 3) build skills in the participants. The notions of “Patterns” a “Pattern Language” are described in more detail in the first of this series, “Special Spaces and Wonderful Places.” The idea for the pattern, Small Successes Early, crystalized from reading DeMarco & Lister’s excellent book, Peopleware.
Small Successes Early.
Author, reviewer and revision dates:
Created by John C. Thomas, December 2001.
Reviewed in early 2002 by Alison Lee and Catalina Danis.
Revised and extended, January, 2018.
Many problems in a modern industrialized society require very large teams of relative strangers to work together cooperatively in order to design and build an adequate system or solution or to solve the overall problem. Yet, because of the sense of urgency and artificial “deadlines,” in many settings, people fail to take the time to learn to trust one another as well as to learn one another’s strengths and weaknesses and preferred styles of working. Plunging a large group of strangers immediately into a complex task often results in non-productive jockeying for position, failure, blaming, finger-pointing, etc. Therefore, insure that the team or community first undertakes a task that is likely to bring some small success before engaging in a complex effort.
A complex undertaking often requires the interaction of many people with various backgrounds, skills, and temperaments. Often, whether in an industrial setting, a community building effort, or in political life, many of these people have not worked together before. The group wants to get started and wants to be successful. Although their diversity is a potential source of strength, at first, there is likely to be natural confusion about how to proceed because people will have different experiences about the best way to organize and proceed.
As the pace of change in society increases, a greater and greater proportion of the work that people do cannot be done in a routine or top-down way. Such a “command and control” style can work well under some circumstances; for example, when the solution is knowable before starting and everyone can be counted on to know their exact function and to be motivated toward an outcome agreed upon by all. Even in such extreme cases, it can still be worthwhile for people to learn about each other before attempting a larger effort. Most teams, even when hierarchically controlled and doing repetitive tasks, will improve over time as they gain experience with each other. In complex tasks with emergent solutions, the effect of practice will be even greater.
- Problems are often too complex for all aspects to be addressed simultaneously.
- If a problem is understood, it is logically better to deal with the hardest constraints first.
- The structure of complex problems often becomes more clear as people try to solve the problem.
- A part of any complex problem solving process requiring more than one person is the interaction and relationship among the people.
- People in a new team need to learn about each other’s skills, working styles, and trustworthiness.
- When people get frustrated because of non-success, they tend to blame each other.
- As people work toward a goal, the goal tends to become viewed as more valuable and therefore people are willing to work harder to reach it.
Therefore, when bringing new teams or organizations together, it is useful to begin with a small success. In this way, people begin to learn about each other and trust each other. People learn more about the nature of the problem domain. This makes tackling more difficult problems later relatively easier.
At the kick-off to a new software development project, rather than having the people be invited to “attend” an event that is “thrown” for them, which might typically include a mind-numbing series of powerpoint presentations from executives about how much money the company will earn if the project is successful, instead, encourage the workers themselves to organize a party, cook-out, pot-luck, song-fest, or storytelling event among themselves. In the process of organizing and carrying out this activity, they will learn about each other’s styles, learn about the trustworthiness of others, and be encouraged by having a success.
Alternatively, the team might simply work on one small aspect of the problem to be solved, provided it is something fairly clear that will result in “success” quickly. For instance, the team might initially work profitably on short presentations about the project, posters, or scenarios but not immediately jump into working on a systems design or a requirements document.
At a workshop on “Human-Computer Interaction for Development” held in Florence (at CHI 2007), we began by having the group make a “map of the world” (shown above) with stones and other materials at hands. Although everyone who signed up was presumably interested in the topic, people were mainly strangers from many parts of the world and had not worked together before. We not only jointly created the map but then had people engage in simple tasks that made use of the map; e.g., stand somewhere close to where you were born; stand somewhere you’d really like to visit but never have; stand somewhere representing a wonderful experience. In an earlier workshop on “Cross-cultural issues in Human Computer Interaction” (CHI 1992 in Monterey), the workshop room was set up like a classroom so our first task was to work together to jointly re-arrange the furniture in the room into a kind of “circle.”
As people experience team success, they tend to view the others in the team more positively. Teamwork is often hard under the best of circumstances. In highly complex problems, when people come together from different cultures, backgrounds, or agendas, it often becomes so difficult as to seem impossible. Rather than having people simultaneously attempt to solve a complex problem and at the same time learn to work together as a team, it is often more effective to separate the otherwise tangled problems.
First, have the people solve a tractable problem where it is clear to everyone that they have a common agenda. A successful experience working together to solve that simple problem will help people learn each other’s styles, strengths, weaknesses and so on. With this knowledge and trust, they can now move on to try to solve more difficult problems.
The human factors psychologist James Welford was called in as a consultant to deal with what appeared to be a very large age effect. People over 35 were having a tremendous difficulty learning new hand weaves. The difficulty, as Welford discovered, was in having older people try to solve two tangled problems. On the one hand, it was hard for older workers to see the actual threads and second, it was hard to learn the weave patterns. What Welford did was introduce a short training segment with very large, quite visible cords. Once people had mastered the weave patterns with these large cords, they were then transferred to the much smaller production size. This eliminated the so-called “age effect” and in fact, both older and younger people learned much more effectively and efficiently.
In similar fashion, trying to solve a complex problem with virtual strangers, especially when there is reason to believe there may be a difference in agendas, is a “tangled problem.” Untangling the “getting to know people” aspect from the complex production or design task will help insure ultimate success.
Some care should be given to the task and setting. The “small successes early” task should allow some degree of give and take, some opportunity for expressive (not just instrumental) communication. People should have the opportunity and space for doing something creative, for sharing stories, for physical interaction. Ideally, it should either be somewhat task related, domain related, or be something nearly everyone enjoys (e.g., eating, playing music, dancing, hiking).
DeMarco, T. and Lister, T. ( 1999) Peopleware: Productive Projects and Teams. (2nd Edition). Upper Saddle River, NJ. : Addison-Wesley.
Schuler, D. (2008). Liberating Voices: A Pattern Language for Communication Revolution. Cambridge, MA: MIT Press.
Thomas, J. C. (2012). Patterns for emergent global intelligence. In Creativity and Rationale: Enhancing Human Experience By Design J. Carroll (Ed.), New York: Springer.
I’d be curious whether others find this Pattern to jibe with their experience. I want to add to these patterns two other sections: Metaphors and Fables/Stories to illustrate the points. I’m interested in what others think of that.
Pingback: Small Successes Early: Metaphor & Fable | petersironwood
Pingback: Pattern Language Summary | petersironwood