Gatekeeper

Problem: Balancing the need to communicate with typically introverted engineering personality types.

Context:

An organization of developers has formed, in a corporate or social context scrutinized by peers, funders, customers, and other "outsiders."

Forces:

Isolationism doesn't work: information flow is important.

Communication overhead goes up non-linearly with the number of external collabor ators.

Many interruptions are noise.

Maturity and progress are more highly correlated with being in control than being control

Solution:

One project member, a Type A personality, rises to the role of Gatekeeper. This person disseminates leading-edge and fringe information from outside the project to project members, "translating" it into terms relevant to the project. The Gatekeeper may also "leak" project information to relevant outsiders. This role can also manage the development interface to marketing and to the corporate control structure.

Resulting Context:

This pattern provides balance for the pattern Firewalls, and complements the pattern Engage Customers (to the degree Customers are still viewed as outsiders). Gatekeeper and Firewalls alone are insufficient to protect developers in an organization whose culture allows marketing to drive development schedules.

Design Rationale:

Gatekeeper is a pattern that facilitates effective flow of useful information; Firewalls restricts flow of detracting information.

The value of the Gatekeeper pattern has been verified in practice. In the discussion of this pattern at PLoP/94, many of the reviewers noted that creating a Gatekeeper role had served them well.

Engineers are lousy communicators as a lot; it's important to leverage the communication abilities of an effective communicating engineer when one is found.

Alexander notes that while it is important to build subcultures in a society (as we are building a subculture here in the framework of a company, or of the software industry as a whole), such a subculture should not be closed ("Mosaic of Subcultures", [Alexander 8]); also, cp. Alexander's pattern "Main Gateways" [Alexander 53]. One might muse that the Gatekeeper takes an outsider through any rites of passage necessary for more intimate access to the development team, by analogy to Alexander's ``Entrance Transition'' [Alexander 112]

Gatekeeper can serve the role of "pedagogue" as in Alexander's pattern ``Network of Learning'' [Alexander 18].

Maranzano notes that the same person often must fill both the Manager and Gatekeeper roles, because of the relationships to external people who need the info.

Next: Shaping Circulation Realms