part of the wiring of a winning organization

I’d been meaning to read Gene Kim and @StevenJSpear’s book Wiring the Winning Organization for a while, so it was a pleasant surprise to see his Tweet connecting the ideas in my QConPlus 2021 talk on loose design-time coupling with those in his book.

I found the book to be a fascinating read.
In particular, it describes how software architecture and loose design-time coupling are key parts of the wiring of a winning organization.
Later in this article, I share a few thoughts about the book.
But let’s first explore the topic of loose design-time coupling.

QConPlus 2021: Takeout burritos and minimizing design-time coupling in a microservice architecture

The key idea in this presentation, which uses the problem of ordering burritos as an example, is that high performance software delivery requires a loosely coupled organization comprised of autonomous teams, which in turn requires a loosely coupled software architecture.
Each team, which Team Topologies would call a stream-aligned team, is responsible for an end to end stream of work that turns requirements into code running in production.
Such a team can, as the Accelerate authors describe, complete their work without needing to coordinate with other teams or creating work for them.

In order for the teams to be autonomous, the software elements (e.g. modules or services) owned by different teams must be loosely design-time coupled.
A change to one team’s element should rarely require changes to another team’s element.
As a result, teams seldom need to coordinate.

Tight design-time coupling kills productivity

Tight design-time coupling is the opposite of loose design-time coupling.
It’s when a change to one team’s element regularly requires changes to another team’s element.
As a result, teams regularly need to coordinate their work.

Tight design-coupling is a pervasive problem within many enterprises.
For example, prior to COVID, almost every organization I visited had a severe shortage of meeting rooms.
I believe that was because teams spent large amount of time coordinating and aligning their work.
As a result, team productivity was significantly reduced.

Now that we have explored the concept of loose design-time coupling, let’s look at how it fits into the wiring of a winning organization.

About wiring the winning organization

This book builds on the ideas of DevOps, Lean, and Agile to describe how organizations can be structured to deliver high performance.
Let’s look at a couple of the key ideas in the book that involve architecture starting with three layer model of organizations.

A three layer organization

One of the book’s key ideas is that there are three layers to an organization:

• Layer 1 (Technical objects) – where the work gets done
• Layer 2 (tools and instrumentation) – tools and instrumentation that enable the work to be done
• Layer 3 (Social circuitry) – includes the team structure and, despite the name, software architecture

To quote the book:

When leaders wire their Layer 3 (social circuitry) well, the people for
whom they are responsible have what they need, when they need it, and
in the format they need it. Problems have been redefined so that they are
easier, safer, and faster to solve. As a result, people can invest their full
creative energies and focus on solving their problems, either in Layer 1
(the work object) or Layer 2 (the tools or instruments to do their work).

This three layer model resonated strongly.
After all, the goal of software architecture is satisfy various requirements, including development-time requirements, such as ease of change.
In other words, architecture makes it easier for developers to deliver changes, and as I described earlier, loose design-time coupling is a key part of that.

What’s more, a key goal of Team Topologies is a highly productive organization structure.
I’ve also spoken to many people who rather than delivering value to customers have to spend their time navigating (or perhaps fighting) the organization’s structure and processes.
One common problem are misaligned incentives, where the goals of different teams are in conflict.

Architecture as a form of simplification

The book also describes three important mechanisms for improving an organization: slowification, amplification, and simplification.
Simplification, which is all about making problems simpler to solve, is particularly important since one of its key elements is architecture, or to be more, precise modularization.

Modularization is all about decomposition of an otherwise large and difficult to maintain system into a collection of simpler, loosely design-time coupled modules.
To quote the book:

The benefit is that small teams gain
independence of action, enabling them to work and experiment on
more manageable parts of the problem in parallel and more quickly and
safely, with lower costs of coordination, .

This sounds remarkably like the goal of the microservice architecture and of the other fast flow architectural style, the modular monolith.

One fascinating modularization case study describes how between 1998 and 2002, the rate of software delivery at Amazon dramatically slowed down because they outgrew their software architecture.
These software delivery problems prompted them to ‘modularize’ their software architecture – adopt what we would now call the microservice architecture.
Because of this change, their deployment frequency went from 20/year in 2002 to an astonishing 49 million/year in 2015.
As you can see, a loose design-time coupled architecture is an essential ingredient of a winning organization.

Need help with accelerating software delivery?

I’m available to help your organization improve agility and competitiveness through better software architecture: training workshops, architecture reviews, etc.

Learn more about how I can help