Applying Conway’s Law to Improve Architecture and Team Productivity: Lessons from Credera at SpringOne

At the SpringOne conference, Credera’s Jason Goth, Micah Blalock, and Patricia Anderson described how they used Conway’s Law to adjust a client’s technical architecture and processes, helping reverse a productivity decline and increase the speed of high‑quality code production.

Conway’s Law states “the design of a system is the product of the organization that designs it… its output mirrors the communication structure of the organization.” In other words, what teams create depends on how they communicate internally.

While building a custom analytics platform for a healthcare client, Credera discovered that an architecture and process that worked for one or two parallel development teams quickly hit a deadlock when the number of parallel teams grew to five. Their solution was to reinterpret the problem through Conway’s Law and adjust the architecture and processes accordingly. After sustained effort, they reversed the productivity decline and increased the speed of high‑quality code delivery. Credera shared this experience at SpringOne in August 2016.

Initially, with only two parallel Scrum teams, Credera achieved modest success. The client then added extra work, requiring several additional parallel development teams to meet simultaneous deadlines. This scale‑up caused work to stall: simple code changes cascaded across multiple downstream services, meeting frequency between teams grew exponentially, workload disparities emerged, some team members left early while others worked late, morale fell, deadlines were missed, and issues remained unresolved.

To align the communication structure, the Credera team technically improved the software design. They applied the open/closed principle to the code base, which reduced cost when multiple teams touched similar code but led to duplicated code. They called this practice GARY (“Go Ahead, Repeat Yourself”). To decouple most of the code, they created a “horizontal plane” to prevent many defects related to the duplicated generated code from forcing repeated “brutal refactoring”.

Goth, Blalock, and Anderson enacted organizational change, stopping practices that violated Conway’s Law. Code standards were removed, and developers were given a guideline that allowed rapid migration from one code set to another. One member acted as a single point of responsibility for all teams, driving communication. Another senior member, Blalock, became the “sacrificial lamb,” meeting with the client and handling legacy code. Although uncommon, team members rotated between sprints across teams. As a result, meeting frequency dropped, workload normalized, morale rose, and deadlines became less anxiety‑inducing.

The team was inspired by Fred Brooks’s book “The Mythical Man‑Month.” From that book they learned that communication cost combined with work partitioning drives efficiency changes. Only when work can be partitioned can adding team members improve efficiency.

Click to read the original article and view the full transcript.