Work Flows Inward

If you want information to flow to the producing roles in an organization, then put the developer at the center and see that information flows toward the center, not from the center.

## Relationships

### To be applied before

* Developer Controls Process is refined by Work Flows Inward.

### To be applied after

* Work Flows Inward is an input for Interrupts Unjam Blocking.

### Alternatives

* Day Care has a similar intent as Work Flows Inward.

*Contents of following sections belong to the original Organizational Patterns website[1] and have been divided into following parts: Context, Problem, Solution, Discussion.*

## Context

...an organization is in place and has been doing work long enough that it can introspect about its structure and workings. There is some management pecking order or hierarchical decision-making structure in the organizational network. Work instructions flow through this structure, with the possibility that each role makes decisions, adds constraints, or works to carry out decisions within some set of constraints.

## Problem

**An organization must seek a structure that best insures that the most authoritative roles make the decisions and carry out the work that adds value directly to the product.**

Some centralized control and direction are necessary. During software production, the work bottleneck of a system should be at the center of its communication and control structure. If the communication center of the organization generates work more than it does work, then organization performance can become unpredictable and sporadic. The developer is already sensitized to market needs through Fire Walls and Gate Keeper (no centralized role need fill this function).

Katz & Kahn’s analysis of organizations shows that the exercise of control is not a zero-sum game [KatzKahn1978, p. 314].

## Solution

**Work should flow in to developer from stakeholders, especially customers. Work should not flow out from managers.** You should not put managers at the center of the communication grid: they will become overloaded and make decisions that are less
well-considered, and they will make decisions that don’t take day-today dynamics into account.

Where work flows from the roles across the organization to the roles at the center (Developer, Architect, Ambassador), there is a healthy distribution of inward-directed inputs. And in large part, the central roles do work, not make work.

## Discussion

The work should focus at the center of the process; the center of the process should focus on value-added activities (Developer Controls Process).

Organizations run by professional managers tend to have repeatable business processes, but don’t seem to reach the same productivity plateaus of organizations run by engineers. In programmer-centric organizations, the value-added roles are at the center of the process (Developer Controls Process; Architect Also Implements). The manager should facilitate and support these roles and their work (Patron Role; Fire Walls).

Mackenzie characterizes this pattern using M-curves, that model the percentage of task processes of each task process law level (planning, directing, and execution) as a function of the classification. [Mackenzie1986]

The rationale is supported with empirical observations from existing projects.

The broad goal of this pattern is to separate overhead work from central work; Day Care is another pattern with a similar intent.

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html