Limiting Cognitive Load with Conway's Law
  • 07 Aug 2021
  • 1 Minute to read
  • Contributors
  • Dark
  • PDF

Limiting Cognitive Load with Conway's Law

  • Dark
  • PDF

Article Summary

Conway's Law

Melvin Conway wrote in his paper "How Do Committees Invent" that:

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure

In essence, the technical architecture of a given system mirrors the management structure.

This highlights the key importance of why Engineering Managers should play a lead role in technical architecture, instead of ivory-tower architects who are isolated from the organisation and cannot change the management structure.

Good team structure leads to both more effective technology and more effective technology.

It is therefore important to organise teams in such a way that they are optimised for flow (minimising handoffs, wait times and communication overhead).

Cognitive Load

Cognitive load was characterized in 1988 by psychologist John Sweller as “the total amount of mental effort being used in the working memory”.

Key to improving team effectiveness is reducing cognitive load. Teams with lower cognitive load can focus on their own flow of work whilst preventing developer burnout.

Poorly organised teams can lead to constant task switching because the team is spread to too thin across a large surface area. As the team grows, this problem gets worse.

Team Topologies

The Team Topologies book presents one way of limiting cognitive load by presenting tested patterns for building technology organisations.

Stream-aligned teams focus on the delivery of work whilst complicated Subsystem teams focus on areas where significant expertise is needed (e.g. cryptography, statistics or advanced technical expertise).

This leaves enabling teams to help overcome obsticles and platform teams to provide the Thinnest Viable Platform (TVP) needed for accelerated delivery of the product.

Four Fundamental Topologies

Three Core Interaction Modes

Why EngProd Matters

Team Topologies cannot be set-up and left alone. The constraints are constantly moving, meaning that the areas of focus for enabling teams and platform teams is constantly changing.

For example; once slow build speeds are fixed, the constraint of a development pipeline may move to local development stacks.

EngProd teams with a hollistic view of product delivery through Cycle Time metrics can adopt a Theory of Constraints approach to addressing bottlenecks.

To be able to continuously improve the flow of work, it's important to have resources to identify and remedy potential bottlenecks.

Typically EngProd ends up representing about 5% of the overall number of developers.

Was this article helpful?