Wiring the Winning Organization
Summary, Thoughts, and My Recommendation
I recently finished reading Wiring the Winning Organization by Gene Kim and Dr. Steve Spear. The book introduces readers to the core ideas with two vignettes (a descriptive short story). The vignettes reveal the author’s mental model of organizations and how to wire organizations to win. Organizations win by making time to solve problems, making those problems easier to solve, and amplifying the need to solve them.
The book contains practice advice using case studies on government, automotive, technology, and healthcare industries. It’s best read by managers and leaders—or those aspiring to be.
In this post, I’ll give you a summary of the book's best parts, along with some of my highlighted passages, my thoughts, reference lexicon, and answer FAQs.
On to the vignettes.
Vignette One: Moving a Couch
The first vignette features the authors, Gene and Steve, trying to move a couch. This seems simple: both people pick up the couch and move it. Simple, but not easy. Gene and Steve must collaborate to move the couch. How do they tell each other to move? Who tells whom to move? How does the couch fit through the doorway? What about down the stairs? Gene and Steve navigate using trial and error, continually collecting feedback from the environment by observing things such as how fast they’re moving, fatigue levels, and how much farther is left.
Readers can imagine this going two ways: the couch moves with minimal friction, or the couch doesn’t for various reasons. Miscommunications, poor visibility, or distractions can cause problems, including serious injury. That’s just with two people. Consider what happens when the helpful friend joins in to coordinate the process. This creates a new bottleneck. All information must flow through that person, and they must fan it back out to Gene and Steve. They are the only two people coupled to the couch. The third person only adds cognitive load.
This vignette demonstrates three key concepts. The first is coherency. Gene and Steve have everything they need to move the couch. The second is coupling. Gene and Steve are physically coupled to the couch. Changes on one end mean changes on the other. Gene and Steve are not independent. They are coupled. Adding a hypothetical third person breaks the cohesion and changes the coupling. Three people are the coherent unit, but only two are coupled to the couch. Third is that all work is knowledge work. It may not feel like it, but moving the couch requires a bit of thinking, adapting, and real-time problem-solving to move the couch.
Vignette Two: Moving Furniture and Painting and Old Victorian Hotel
Everything you need to know is in the second vignette. Gene and Steve are assisting renovating an Old Victorian hotel. They’re responsible for repainting the rooms. That requires moving furniture. Constraints require them to hire separate groups of painters and movers. Gene and Steve become the managers responsible for managing two functional teams towards a common goal.
The vignette shows multiple ways Gene & Steve fail spectacularly before learning to organize the operation. The first iterations see Gene and Steve trying to schedule the entire house simultaneously from a top-down command and control position. This scenario puts Gene and Steve into constant fire-fighting mode, reacting to problems in different rooms from the different groups.
Fast forward a few iterations. Gene and Steve discover it’s better to break down the house into rooms and create flow in each room. First, movers remove the furniture, then painters paint, and movers return the furniture after the paint dries.
This approach has multiple benefits. Now, the cohesive unit is a room, not the entire house. Rooms are not coupled to each other. Teams of movers and painters can complete a room and move on to the next.
They’re also able to solve novel problems as a group. Rooms may have different types of wood that need different stains. Rooms may have odd furniture or layouts. The point is that teams know what to do by looking at the room and knowing how and when to call for help. The work becomes self-synchronizing. There’s no need for central control.
Decentralizing the operation allows Gene and Steve to solve problems at a higher level. They can swarm problems that may block individuals or teams. They may keep a reserve force of movers and painters to deal with oversized or overloaded rooms.
This vignette demonstrates most of the ideas in the book. Knowledgeable readers will see pull-based work, batch size controls, kanban, the andon cord, and problem-solving.
Bonus Vignette: Rejigging Pagerduty and Datadog
Wiring the Winning Organization is not specifically a software book. It’s intended for all audiences. My team was doing an unofficial case study on slowification, simplification, and amplification while I was reading the book. Check out this shoutout I gave the team after they finished.
So, if you want a vignette that is entirely software-focused, then listen to this Small Batches podcast episode.
Organizations as Sociotechnical Systems
Wiring the Winning Organization models organizations as a sociotechnical system in three layers. Layer 1 is the technical object, like code in software. Layer 2 is tools and instrumentation, like cloud providers. Layer 3 is the social circuity, how ideas and information flow in the organization. This includes how teams are structured, collaboration, and general organizational culture. Layer 1 and 2 are the “technical” side and Layer 3 is the “social” side of sociotechnical system.
Consider this mental model through the lens of the Victorian house vignette. Gene and Steve’s attempt at command-and-control creates a Layer 3 problem. Everyone depends on Gene and Steve to do anything. This creates problems in Layer 2 when movers and painters must phone HQ for anything extra or to solve problems. Layer 1 is impacted because there are conflicts on who is doing what and where.
Contrast this to the distributed approach. Information flows differently. Teams address Layer 2 and Layer 1 problems on their own. The organization is wired to stop and swarm on problems. That’s an outcome of wiring in Layer 3.
Wiring the Winning Organization primarily focuses on Layer 3, since if that’s not set up correctly, then there will be conflicts.
The second vignette introduces the three ways to win. One is slowification: slow down to enable deep problem-solving. Two is simplification: making those problems easier to solve. Three is amplification: ensuring the problems are seen and solved.
Read the FAQ and Lexicon section for more information on these three techniques.
Thoughts
This book coalesces multiple related models into a single coherent description. It’s part The HIgh-Velocity Edge and part The DevOps Handbook with key bits of Dr. Deming and Lean mixed in. This venn diagram from the conclusion conveys where the book sits.
The vignettes are the best thing in the book. They explain enough of the mental model better than any examples I’ve come up with. I prefer the vignettes because they’re broadly relatable for technical and non-technical audiences.
Moving the couch describes the cost of coordination and synchronization. Painting the house demonstrates everything else. Basically, Gene and Steve discovered kanban, pull-based work, swarming problems, and decentralized leadership. The two vignettes are worth the price of admission alone.
The “layer” model is also useful. It helps build a common mental model for describing where problems are and where your gemba is. For example, management’s gemba is different than an IC’s gemba.
My biggest critique is it’s a lossy compression of its tributaries. Wiring the Winning Organization focuses entirely on problem-solving. It does not go deep enough into the cultural aspects needed to execute slowification, simplification, and amplification. They allude to core concepts but are not part of the book. Yes, problem-solving is a core Lean competency, necessary but not sufficient.
Don’t expect Wiring the Winning Organization to cover everything. I think it’s best viewed as an entry point into multiple related ideas or as a supplemental resource to those already familiar. I’ll put it another way. If you’ve read The High-Velocity Edge, The DevOps Handbook, or The Toyota Way, you’ll find the same ideas expressed in a new way in Wiring the Winning Organization.
Next are a few of my highlighted passages from the book.
Passages
Even if they had all that information, creating an accurate schedule is still hopeless. It was mathematically proven over fifty years ago that it is often impossible to compute a correct and optimal scheduling solution in finite time for schedules of any significant size.
This passage is from the second vignette on the futility of planning the moving and painting the entire house at once. Scheduling is an NP-complete problem. Yet, why on earth, is trying to schedule an entire month (or quarter, or sometimes even years) of software engineering time even attempted? It’s a fool’s errand.
Teams were no longer able to solve Layer 1 (the work) problems because they were too mired in Layer 3 (organizational circuitry) problems—communicating and coordinating to get even small things done. This is because the smallest coherent unit at Amazon became all the software engineers at Amazon, where in development or operations. Every engineer had to talk to every other engineer because everything was coupled together, depriving everyone of the ability to act independently of each other.
This passage comes from a section on how shipping software at Amazon became too coupled. Development had practically become a monolith. This demonstrates how nonismorphism between Layer 1 and Layer 3 can create huge delivery challenges.
I’ve seen this happen time and time again. Layer 3 (management) assumes a structure (information, people, delivery) that is orthogonal to Layer 1 (the code, services, deployments, etc). If these problems persist long enough, drastic action is required to fix the problem.
Jeff Bezos did it at Amazon with his famous memo on two-pizza teams and collaboration only via APIs, thus shifting Amazon to a more decoupled and decentralized Layer 1 system. These changes can only succeed with buy-in from top management (Layer 3).
An often-overlooked area of testing is business processes and communications. Systems and processes are highly intertwined; and separating testing of systems from testing of business processes isn’t realistic: a failure of a business system will affect the business process, and conversely, a working system is not very useful without the right personnel.
This passage comes from a section on running game day exercises. Game day exercises commonly simulate Layer 2 and Layer 1 problems. That’s necessary but not sufficient. Game day exercise should also simulate Layer 3 problems. For example, the company Slack has been deleted. What happens? Another example: top management has been killed by zombies while annual off-site. What happens? Focus on the social and technical aspects of the sociotechnical system.
FAQ
How do I support you?
Subscribe so I can continue producing long form-content on Software Kaizen and supplementary short-form content on Small Batches.
How do you rate this book?
I rate it 4/5 because it adds something new to the conversation but falls short of the premise. Consider this line from the publisher: “DevOps, Lean, and Agile got us part of the way. Now, Wiring the Winning Organization gets us over the finish line.” I don’t think it got us over the finish line. I think it’s a lossy compression of those ideas. Wiring the Winning Organization focuses exclusively on problem-solving, whereas DevOps, Lean, and Agile encompass much more. The book is a 5/5 as a mental model and reference work for problem-solving, but not as references to the other ideas.
Should I read this book?
If you’ve read The High-Velocity Edge, The DevOps Handbook, and a bit of Deming, skip this book. Summaries and author interviews will give you the gist, and then you can google specific terms or references. I think the summary and lexicon sections hits that 80/20 rule sweet spot.
Why did you read this book?
I knew this book was in the works for a few years as a collaboration between Gene Kim and Dr. Spear. Two people I have immense respect for. That made it a no-brainer follow-up to The High-Velocity Edge and The DevOps Handbook.
Where can I hear more from the authors?
I recommend this three-part series with Gene Kim on the Troubleshooting Agile podcast. Here’s a link to part one. I also recommend this episode of Chain of Learning with Gene & Steve.
What is the book missing?
There is no discussion of visual management. That’s an unfortunate omission because it’s the Layer 2 approach to the book's Layer 1 and Layer 3 techniques. Want to do pull-based work? Well, you need to see the kanban. Need to know if there is too much WIP? Well, you need to see the board. Visual management is a natural fit for the house vignette. How do Steve and Gene know all the rooms are complete? Make the status visual. How do Steve and Gene know which rooms have andon pulls? Make that status visual. There are (great) visual explanations of what’s happening in the house to the reader, just no mention of how management can visualize the work.
The concepts in Leadership is Language are also missing. redwork and bluework overlay slowification, simplification, and amplification. Redwork is doing the thing. Bluework is the thinking and creative work. Leadership is Language states that how we speak controls our movements between these two types of work. “Calling a pause” is a play to exit redwork and enter bluework. This connects directly to slowification’s planning and practice. Imagine this conversation: “Hey wait, we need to stop. There’s a problem completing the work. Can we pause to look for viable alternatives?” Notice “amplification” in highlighting the problem and “slowification” by calling for a pause for planning and practice.
The authors seemingly created new terms for the same concept in the first vignette. “brainwork” is same as bluework. “brawnwork” is the same as redwork. I shook my head while reading these paragraphs.
What is one surprising takeaway?
The Nyquist-Shannon Sampling Theorem from 1928. It states that any control system must sample the underlying system at least twice as fast as the underlying system operates. This sets cadence rules (see Principles of Product Development Flow).
It struck me because it explains many past frustrations. Here’s an example of adequate sampling frequency: weekly planning with daily samplings of WIP status. Here’s an example of inadequate sampling frequency: reviewing reports once a week for conditions changing daily.
Here’s the theorem explained another way. If you “plan” every month, the “plan” can only manage conditions stable for two months. Conditions changing faster than every two months may not be detected or controllable. This has stark implications for top-down management.
Fun fact: Jeffrey Fredrich, host of the Agile Conversations podcast, had the same surprising takeaway.
What should I read next?
There are two paths to follow. One goes deeper into the tributaries leading to this book. One continues exploring the ideas at the 10,000 feet view.
If you want to study deeper, I recommend The Toyota Way, The Fifth Discipline, or The New Economics, or my study-guide to software delivery excellency.
If you want to keep exploring, I recommend The High-Velocity Edge or The DevOps Handbook.
Also, see this post by the authors with more book recommendations.
What did the book do well?
The included visuals and comics convey the core ideas. I’m noticing more books doing this. I hope the trend continues. It makes the book more enjoyable and less like a big wall of text.
I think it also demonstrates IT Revolution Press’ incremental progress in quality. The typesetting and use of color create a better reading experience.
What is Slowification?
Slowification is shifting problem-solving from performance (operation, execution) back to practice (preparation) and planning with forceful backup, stress testing, and other deliberate ways of finding flaws in the thinking before they become flaws in doing.
What is Simplification?
Reducing the number of interactions one component of the system has with other components of the same systems (e.g. technical interactions between component parts in an engineered system or among people in a working group). Simplification contains three techniques: incrementalization, modularization, and linearization.
What is Amplification?
The act of calling out problems consistently so help is generated and swarms the problem to contain it and investigate, so causes can be found and corrective actions created to prevent recurrence.
What is a Layer 1 problem?
This is a problem with the object on which work is being done. Example: “I don’t understand the API between the model and controller.”
What is a Layer 2 problem?
This is a problem with the instrumentation or equipment used in the work. Example: “I can’t get the test environment running.”
What is Layer 3 problem?
This is a problem with the social circuity or organizational wiring. Example: “I don’t know what my team is supposed to be doing right now.”
Lexicon
Coherence: The quality of having a unified whole, which requires that elements that interact frequently and intensely are included in the same grouping so their interactions can be well managed, and that those that are not are excluded. This is necessary behavior of the whole to be logical and consistent.
Incrementalization: A technique within simplification of partitioning a large problem-solving effort (a great leap) into small, incremental steps. This involves establishing a stable base and then iterating and testing changes in a few factors at a time as opposed to testing the effect of changing many factors at once.
Isomorphism: The quality of related items having similar structures so they can fit and operate together (e.g., “hand in glove”). In our context, we use isomorphic more frequently to describe to what extent the Layer 3 (social circuitry) supports and enables the work being done in Layer 1 (technical object) and Layer 2 (tooling and instrumentation).
Linearization: A technique within simplification of sequencing tasks associated with completing a larger set of work so that they flow successively, like a baton being passed from one person to the next. What follows is standardization for those sequences, for exchanges at partition boundaries, and for how individual tasks are performed. This creates opportunities to introduce stabilization, so when a problem occurs, that triggers a reaction that contains the problem and prevents it from enduring and from its effects spreading. Those allow for self-synchronization, so the system is self-pacing without top-down monitoring and direction.
Modularization: A technique within simplification of partitioning a system that is unwieldly in its size, complexity, and inter-wiredness of relationships among its many component pieces into more, smaller, simpler, and coherent pieces.
Social circuitry (organizational wiring): The connections by which ideas, information, services, and support can flow from where they are to where they are needed so that effective, collaborate problem-solving and value creation can occur. It is the overlay o processes, procedures, routines, and norms by which individual efforts are integrated through collective action toward a common purpose.