Producer Roles ★

...once you have identified the roles in the organization, you are in a position to optimize the role structure. This usually involves reducing the number of roles, particularly for mature organizations.

✥ ✥ ✥

The overhead and bureaucracy in the organization is excessive, as manifest by the presence of too many roles. Yet all the roles seem important. It looks like there is no way to reduce the bureaucracy.

An organization needs some bureaucracy to keep projects running smoothly; there is much administrative work to be done. Programmers don't want to bother with it. But left unchecked, bureaucracy tends to grow: new roles get created and the communication overhead increases.

People tend to gravitate to those roles they are most comfortable with. This is healthy. However, some people need the recognition associated with titles (German: Titelsucht), and roles are obligingly created to fill that need. Such roles have no intrinsic value to the project.

Over time, the responsibilities of roles evolve. In some cases, the real benefit of a role drains off to other roles, leaving little more than a shell behind. In one organization, the chief responsibility of a particular role was "worry." It added no value to the project. But because of the history of the role, it is easy to simply assume that the role is important.

Therefore:

Identify each role as a producer, supporter, or roles that add no value to the project (deadbeats). Eliminate the deadbeats, and in some cases, eliminate or consolidate some supporters. Nurture the producer roles; they are the ones that pay the bills.

Producer roles are those roles that contribute directly to the end product; there is an obvious connection between their work and the revenue of the company. The canonical producer role in software organizations is "developer".

An organization has numerous support roles. These roles contribute to the effectiveness of the producer roles, but don't directly develop the products. Many support roles are vitally important, such as FireWalls, GateKeeper, and PatronRole. Roles that provide computing support, for example, are also essential. But support roles are inherently higher in overhead than producer roles. There may be opportunities to gain efficiency by combining support roles.

Deadbeat roles, as other types of roles, can be identified by their responsibilities. They may do nothing more than receive information and pass it on without adding any value to it. Watch for other responsibilities that add no value to the project, such as the aforementioned "worry." If a role truly adds no value to the project, it should be eliminated.

Note that in some cases, a role that passes information adds value by doing so. For example, a person who passes information by "pushing" it to those who would normally not get the information may prevent project inconsistencies, or might even detect such inconsistencies before they get out of hand (see WiseFool). Such a role is an important support role.

✥ ✥ ✥

Although eliminating roles fosters greater organizational efficiency, it may lead to bruised egos, or even feelings of insecurity. In some cases, roles might be preserved, but reshaped to contribute more directly to the project. Refer to FormFollowsFunction and ShapingCirculationRealms for further help.

It sets up ProducersInTheMiddle. There is a link to DomainExpertiseInRoles. See also FireWalls, GateKeeper, and PatronRole.