[CoplienOrganizationPatterns]

Note: BuffaloMountain needs to be rewritten and broken into two or more patterns. Here is my attempt (NBH): ResponsibilitiesEngage and HallwayChatter (Names subject to change)
external image BorlandGrid.gif
Problem
We want to optimize communications in a large software development organization, whose members are working together on a common product.ContextA development organization straddling several domains, where effective interpersonal communication is key to project success.
A nominal "hub" may already have been established for the organization.

Forces
Communication overhead goes up non-linearly with the number of people.
Information starvation or role isolation cause people to develop unsuitable subproducts.
Being a communication bottleneck leaves no time to do work.Communication bottlenecks cause queues in organizational work flows that keep other people from doing work.Fully distributed control tends to lead to control breakdown.Solution
  1. For any significant project interaction, the distance of the two collaborating roles from the "center" of the organization should sum to a distance less than the smallest distance necessary to span the entire organization.
  2. Avoid coupling with neighbors (those equidistant from the center of the process as yourself; i.e., those equally coupled to the process as a whole as yourself) if you are in the outlying 50% of the organization.
  3. The intensity of any interaction should be inversely proportional to the sum of the differences of the roles' distance to the center of the process.

Means A: Shuffle responsibilities between roles in a way that moves the associated collaborations, to effect the above patterns (MoveResponsibilities, WorkAllocationPattern). This is RobertLai?'s idea; it's simple, but profoundly effective.

(NBH) Ok, I think this is a pattern. What's the problem? You've got schmismogenisis. Or you have people hanging out there by themselves. They aren't getting the information they need, so they can't do their job effectively. And they might quit. But most of all, they aren't happy.
The solution is as above, but more. One key is that two roles in the same person have inherently strong communication. So if you give a disengaged person a hot role (not a hot roll), they get the info they need to do their job. But it comes kind of indirectly.
Note the bridging between roles and people here. Both people and roles are critical elements of the whole equation. But few patterns bridge the two. This one does.
Of the three (possible) patterns, this seems most like the traditional BuffaloMountain.

Means B: Physically relocate people to enhance their opportunity to communicate (see WorkFlowsInward).

(NBH) What's the problem? Maybe it's that it takes a long time to communicate throughout the organization. So you move people close together. But people need to realize that communication is more than email and phone calls. (Hmm. Anybody working on collaboration projects?) You need the face-to-face. So put people together. There is a lot of incidental hall chatter that spreads vital information. See LockEmUpTogether. This one may contain it, perhaps?
Note that this pattern, unlike the previous one, isn't about roles at all. That's one reason that it's a separate pattern from the above.
I get the feeling there's more to it, but haven't put my finger on it yet.

Means C: Increase span of control of a role in the project (akin to merging multiple roles into one). It is probably best to MergeRolesWithSimilar? responsibilities, or better, to MergeRolesWithSimilarCollaborations?. Hey, those are patterns too!

(NBH)I'm somewhat skeptical of this one; it doesn't feel quite right. Maybe it's that we have somewhat less explicit control over the existence of roles than we would like to admit. But there may still be a pattern lurking in here. After all, it is akin to FewRoles.

Resulting Context

The new organization has more balanced communication across its roles.

Rationale

Most of these patterns are empirical, rather than being derived from first principles. I think it important to recognize this path to patterns as a positive and potentially fruitful one. If it works, go with it.Sub-pattern 1 is empirical. It is the dominant sub-pattern. It infuses a level of "distributed control with central tendency" that lends overall direction and cohesion to an organization. Another way of stating sub-pattern 1 is that most points on the interaction grid tend to live near the axes.Sub-pattern 2 avoids cliquish splinter groups. It also helps avoid linear event ordering in the distant (support) parts of a process. Linear event ordering (or pipelining) causes points on the interaction grid to line up right below the diagonal. A pattern that avoids points on the diagonal is likely to encourage more parallelism and independence.Sub-pattern 3 tempers sub-pattern 1, allowing points further from the diagonal but not too far from the origin. Thisallows for a tight "core" at the middle of the process. It also helps to even the distribution of load across roles in the process. Many organizations are bimodal: they interact tightly in the core, and virtually not at all in the outlying roles. This evens the load across all roles.The overall (and difficult-to-explain) nature of these sub-patterns is that they improve product quality and reduce time-to-market. They tend to correlate with high spans of control. That in turn reduces the number of people necessary to complete a project, further reducing communication overhead, improving cohesion, and causing the pattern to recursively feed on itself. It's wondrous to watch this happen in an organization.