The crowded room

I keep seeing the same pattern in enterprise software:

  • The meeting. Twenty people join a planning call, but two or three work through the decisions while the rest listen. Nobody asked each listener for a decision or a specific piece of input. The attendee list records presence, not contribution.
  • The outage. An incident bridge fills with names, but only a few people inspect logs, test hypotheses, and propose the fix. Without assigned roles, each person can assume someone else is working on the next step.
  • The project. Two engineers start the work, and every task or missed follow-up points to one of them. The team grows, ownership becomes “the team,” and a task can sit because no named person must move it.
  • The Slack channel. I ask who owns a component and hear, “Team X.” I post my question in their channel and get no answer. The question names no person, so every reader can assume someone else has more context and will respond.

The rooms differ, but the group result hides each person’s effort in all of them. As the group grows, contribution becomes harder to trace.

The rope

Maximilien Ringelmann measured people pulling a rope alone and in groups. The average participant pulled with 85.3 kilogram-force (kgf) alone. That average fell to 65.0 kgf in groups of seven and 61.4 kgf in a group of fourteen. Ringelmann blamed much of the loss on coordination. Researchers linked part of the loss to reduced motivation, which they call social loafing.

Researchers call that pattern the Ringelmann effect: individual contribution tends to fall as group size grows.

Personal contribution depends on whether anyone can trace it back to a person.

You can see the effect in the meeting where attendance counts but speaking does not, the incident bridge where twenty people share three active tasks, and the Slack channel where a team owns the question but no person owns the reply.

Put a name on it

I keep one rule across projects: I assign a responsible human to every important thing, or I define a process that selects one.

An owner does not have to perform every task. The owner makes sure someone handles it and closes the loop. A component needs a name behind it. An incident needs explicit roles. A support channel needs a rotation. A meeting needs people responsible for decisions, not a larger invite list.

Ownership needs boundaries. If one person “owns” an entire platform, the label gives you a false answer. Name owners at the level where they can act: the API contract, deployment path, service, decision, or support shift.

When you expand a team, add ownership with the people. Otherwise you increase the number of possible contributors while making each contribution harder to see.

Further reading