Many folks believe that there are basically two kinds of people. The rest of us, of course, are different; we know better. So it is when it comes to work and organizations. There are those who think the choice is between orderly authority and unbridled anarchy—or between freedom and oppression—and that's it! The rest of us know it is never that simple. Whatever managers and management consultants may do to simplify the story, real people in real organizations defy the limitations of simple dichotomies and slip out of the one-dimensional conceptual boxes into which we try to stuff them.
On the one hand, we have the hierarchical model for work organization discussed in Chapter 11 and on the other, its exact opposite, the creative anarchy explored in Chapter 12. And in between the extremes of ordered traditionalism and freestyle innovation are scattered as many variations as there are projects and people to work on them.
Not every working group falls somewhere along this line, however. Some, quite far off in left field, do not see the basic issues of work organization as trade-offs. These are the people who think “both/and” rather than “either/or,” who say, “We can work it out.” Both traditionalists and their free-spirited competition tend to see an essential tension between “me” and “we.” In the traditional hierarchy, the interests of individuals are subordinated to those of the team or group or organization; in innovative individualism, the individual reigns supreme and collective interests are moved backstage.
Others, however, believe there is no essential conflict between the whole and its parts, just as there is no need to choose between change and stability. Their approach to working together, officially known as the “open paradigm,” is a model for flexibility based on egalitarian cooperation and communication. In descriptive shorthand, we could call this model “adaptive collaboration,” an open-ended architecture for human organization.
Adaptive collaboration is tailored for technical problem solving. It values neither tradition and stability nor innovation and change in themselves. What is important in this view of projects and progress is the adaptive fit between how the team is working and what it is they are working on. Today we're designing independent programs, so we work separately; tomorrow we have to come up with a common communications protocol, so we meet as a group; everyone has something to say about database architecture, so let's get all the ideas out on the table.
The aim in such a group is to hang loose and talk things through so that competing goals can be integrated and alternative approaches can be synthesized. They are, in a sense, continually reinventing themselves, changing the way they work to fit the needs of the moment and the group's long-term goals. Who is “in charge” and how they are in charge depends on what the group is doing.
Development groups organized along these lines tend to be more of a flat circle than a pyramid. Team members work as colleagues with interchangeable roles. Unlike the free radicals of “breakthrough” teams, who may work quite independently and even competitively, these colleagues closely coordinate their efforts. Decisions are made collectively, through discussions, negotiation, and consensus building. This does not mean that everyone agrees on everything, but that they work on the basis of a technical consensus. A technical consensus is one in which all team members can support the group's actions and choices on all essential matters. This requires getting everyone's input on matters of importance. Technical consensus assures that co-workers “buy in” to the joint effort and feel pride of personal ownership in the collective product.
Because they talk things through together, these groups really shine on solving complex problems, especially where substantial quantities of information have to be exchanged and examined (which sounds suspiciously like a lot of software development). In fact, the more factors and facets and widgets and whatsits to the problem, the greater the relative advantage of open teams over tactical teams, where information may be too tightly controlled, and breakthrough teams, where information can get lost in the competition and chaos.
Breakthrough groups, putting a premium on free-thinking originality, may also come up with brilliant innovations that fall short of being completely practical. Their stolid counterparts in tactical teams may produce dependably routine programs but miss out on more creative possibilities in data structures or algorithms or user interfaces. Collaborative problem-solving teams are in the best position to pull together disparate ideas from all their members to produce solutions that are both practical and innovative.
Real collaboration requires the right kind of leadership, leadership that encourages free discussion and helps to build technical consensus. The best managers for open problem-solving projects tend to be working colleagues, competent professionals themselves who play an active technical role in analysis, design, and construction. Typically, they do not lead meetings or technical discussions themselves, because they don't want to bias the outcome. Instead, they let others facilitate the discussion, drawing out the best contributions of all members. This takes a certain act of faith, a belief that the group as a whole knows more and can come up with better solutions than any one member—including the manager! Managers who are convinced that they are the smartest and best and can lay out programs better than everyone else on the project put together are not likely to fare as well as collaborative colleagues. They might do better on their own or heading a traditional tactical team.
Not surprisingly, the strong suit of adaptive collaboration can also be a handicap. These people can talk up a storm. When an hour's discussion won't resolve an issue, they're ready to spend a couple more. Not only do they haggle over the technical issues, but the philosophy behind the issues; not only do they question the development methods, but the assumptions on which they are based. Even the way the group itself operates is grist for the mill, as they examine their own methods and structures and try to adapt them to fit the problem. (“Hey, guys, maybe we need to split up into subgroups on this part of the system, work for a few days, then reconvene to try to pull it together.”)
There are ways to cut down on the wheel-spinning tendencies of problem-solving teams. Decisions can be time-boxed. If a technical consensus is not reached by a specific deadline, the issue may be set aside, or defaulted to some set solution, or put into the hands of the manager for arbitration. Although each of these options somewhat violates the rules of consensual decision making, as long as they remain uncommon exceptions, the payoffs in efficiency can offset some loss in the sense of ownership in the results.
But it depends; there is no simple formula. To remain open, each group has to find its own way, negotiating its own procedures and exceptions.
One of the best collaborative groups I ever knew was known as the Theory Construction Workshop, an independent working group loosely affiliated with a professional society. Members met as colleagues trying to advance a common enterprise of theory construction in an atmosphere of free discussion and mutual support. Its meetings were completely open to anyone who shared an interest in building better theory. The content and format of meetings were negotiable within the group's strong tradition of enhanced cooperation and communication. Inevitably, at almost every annual business meeting, some newcomer, flush with the excitement of joining in such a rare and wonderful interchange, would propose some form of institutionalization—incorporation, membership credentials, bylaws, printed proceedings, or the like. Every year we would dutifully discuss and debate these proposals; every year they would be defeated, the consensus being to stay open, informal, and flexible.
Then one year, without thinking it through, I arose with a radical proposal. Henceforth, to avoid wasting time deliberating these perennial proposals, all attempts to institute fixed and formal rules or structures would be banned. Even before I could finish my thought, I started laughing at my own self-contradictory suggestion. Our sincere and serious consideration of even the most ill-considered suggestions from the rankest newcomer were precisely what made the group process work. Everyone smiled, I sat down, and we went back to debating the latest plan for formal proceedings. To stay open, an open process must remain open to alternatives.
Steven Sondheim ends his brilliant theater piece, Sunday in the Park with George, in a wonderfully open-ended way with words attributed to Georges Seurat: “White, a blank page or canvas, his favorite: so many possibilities.”
My favorite, too.
From Software Development, Volume 1, #6, June 1993