Divide And Conquer

...the roles have been defined for a process and organization, and the interactions between them are understood. The organization has grown to a point where it cannot easily manage itself. Perhaps there are too many people or, more seriously, too many roles, for the organization to hang together. The organization's decision process breaks down and progress bogs down for more and more decisions. Or the organization can foresee growth to a point where these problems arise. 

For example, this organization has no apparent regular structure, and though it is productive, it is not likely to evolve well. 

✥ ✥ ✥

Successful projects must learn to accommodate the growth that accompanies success in projects and that outstrip team dynamics. If an organization is too large, it can't be managed. Incohesive organizations are confusing and engender dilution of focus. 

Separation of concerns is good. Even distribution of responsibility is good because it distributes the work load. Regular structures, such as hierarchies, can easily be grown by adding more people, without destroying the spirit of the original structure. But a regular hierarchical structure does not distribute responsibility evenly. 

It is useful to have organization boundaries that are somehow lightweight. 

Therefore: 

Find clusters of roles that have strong mutual coupling, but that are loosely coupled to the rest of the organization. Form a separate organization and process around those roles. Make sure the organization has identifiable sub-domains that can grow into departments in their own right as the project thrives and expands to serve a maintained market. 

It is sometimes easiest to do this by identifying core roles that can form the root of sub-organizations that precipitate from a larger organization. Let the sub-organizations cluster around these roles. 

You should apply this pattern between releases so as to minimize turmoil that might confuse work in progress. 

This organization has no well-partitioned structures, but one can identify logical partitions within it (Customer, Developer, Management, etc.) 

✥ ✥ ✥

This establishes an overall organizational framework as a basis for organizational growth. Each new sub-organization is a largely independent entity to which the remaining patterns in this language can be independently applied. It makes it possible to have FewRoles in any given closure of interaction. 

Implement this pattern using OrganizationFollowsMarket, OrganizationFollowsLocation, and SacrificeOnePerson. 

In the forces, note that each sub-organization that arises from this pattern is fodder for most other patterns, since each subsystem is a system in itself. Also, to see an organization that has been reverse engineered and redivided into new processes, see the picture for the pattern MoveResponsibilities. 

The business structure is a key consideration in building an organizational structure. Much of the business structure becomes articulated in the architecture, so ConwaysLaw is an important pattern supporting this one. If you can find no core roles around which sub-organizations might form, then the organization may not be partitionable. For example, it is difficult to grow a Chief Programmer Team organization. 

If you need to divide things up in time, rather than across team structure, see GetOnWithIt.