Naval air base, Corpus Christi, Texas. A top notch mechanic, Mary Josephine Farley expertly rebuilds airplane engines. Although she's only twenty years old she has a private pilot's license and has made several cross country flights.
...you know the key atomic process roles (FormFollowsFunction) including a characterization of the Developer role.
✥ ✥ ✥
Matching staff with roles is one of the hardest challenges of a growing and dynamic organization. All roles must be staffed, and, all roles must be staffed with qualified individuals. Just as in a play, several actors may be assigned to a single role, and any given actor may play several roles.
You'd like to use domain-inspecific qualification criteria like college grades or years of experience to qualify people for jobs. Such an approach gives the project flexibility in staff allocation; it helps it avoid being overly dependent on individual skill sets and experience. In short, the hope that such criteria might work provides project managers a basis for keeping the project from becoming overly dependent on certain individuals; such individuals may leave or may hold the organization hostage for higher salaries or to see their own policies implemented unilaterally. Yet successful projects tend to be staffed with people who have already worked on successful projects.
Spreading expertise across roles complicates communication patterns. It makes it difficult for a developer or other project member to know who to turn to for answers to domain-specific requirements and design questions.
Therefore:
Hire domain experts with proven track records, and staff the project around the expertise emodied in the roles.** Teams and groups will tend to form around areas of common domain interest and focus. Any given actor may fill several roles. In many cases, multiple actors can fill a given role.
Domain training is more important than process training.
Local gurus are good, in all areas from application expertise to expertise in methods and language.
✥ ✥ ✥
This is a tool that helps assure that roles can be successfully carried out. It also helps make roles autonomous. Empirically, highly productive projects (e.g., QPW) hire deeply specialized experts. OldPeopleEverywhere ([BibRef-Alexander1977], ff. 215), talks about the need of the young to interact with the old. The same deep rationale and many of the same forces of Alexander's pattern also apply here.
This is also a systems principle that one finds in software development; see http://gee.cs.oswego.edu/dl/rp/roles.html.
A seasoned manager writes, "The most poorly staffed roles are System Engineering and System Test. We hire rookies and make them System Engineers. (In Japan, only the most experienced person interacts with customers.) We staff System Test with `leftovers'; after we have staffed the important jobs of architecture, design, and developer."
Other roles (ArchitectControlsProduct, DeveloperControlsProcess, MercenaryAnalyst, and others) are prescribed by subsequent patterns.
If expertise becomes too narrow, the organization is at risk of losing key expertise if a single person leaves, is promoted, etc. Temper this pattern with ModerateTruckNumber.
Domain experts can naturally come together in ProgrammingEpisodes. The pattern ApprenticeShip helps maintain this pattern in the long term. DiverseGroups is, in some sense, a more general version of this pattern.
See also SubsystemBySkill and UpsideDownMatrixManagement.