This article is part of the How Do YOU CM2? blog series in collaboration with the Institute for Process Excellence (IpX). Although I receive compensation for writing this series, I stand behind its content. I will continue to create and publish high-quality articles that I can fully endorse. Enjoy this new series, and please share your thoughts!
On 14 October, Jos Voskuil published Conway’s Law – the PLM killer!. In his view, PLM is not failing; companies build their strategies on a siloed organization, and only top management can lead the way out. He calls Conway’s Law the elephant in the room. In the comments, I wrote that the change process “forces” cross-functional collaboration, although breaking down silos completely is hard.
So here is the extended version of my comment. I believe configuration management already works against Conway’s Law by enabling collaboration through the change process, without waiting for a reorganization. It is the same problem as in Ignorance is Bliss! (till it isn’t), seen from the change process.
What does Conway’s Law actually say?
Most of us know the one-liner: an organization designs systems that copy its communication structure. The paper behind it is Melvin Conway’s “How Do Committees Invent?” from 1968, and it is not only about software: one example is two military services that had to develop a common weapon system and ended up with a copy of their organization chart.
Three points from the paper matter for configuration management. Whenever two subsystems connect, the two groups that designed them had to agree on the interface, and in a footnote he adds that a group rarely compromises its own design for another group unless it really has to. He also names incentives, such as managers who gain prestige with a bigger budget. His advice is to organize a design effort around the need to communicate and keep that organization flexible, because the need changes when the design changes. In other words, Conway never says that the reorganization has to come first.
Why do silos survive?
Colfer and Baldwin reviewed 142 studies and found that products often, though not always, mirror the organization behind them. Take, for example, a Pratt & Whitney jet engine program, where Sosa, Eppinger, and Rowles compared the design interfaces with how the design teams talked to each other. Inside a design group, about one in five interfaces had no conversation behind it. Between groups, it was about half, which the authors mainly attributed to people staying within their own group. If that happens when most teams share one building, how many interfaces between your departments and your suppliers have nobody talking about them?
In a small company, you know almost everyone, but in a large company your network might be 1% of the people, and it is easy to stay anonymous and assume somebody else checks the impact. My old post told the story of an engineer who found a way to save 20% on material cost. Nobody aligned with manufacturing; the factory layout had to change to drill a hole, and after more than ten years, the investment still hadn’t paid back because nobody looked after that interface. As I wrote back then, “The system allowed them to become ignorant.” If that is true, the fix has to be in the system as well.
How does a change process force collaboration?
Think about a change request coming in. In CM2, the Change Leader has to identify all affected items and datasets, plus the impact on cost, schedule, risk, customers, the supply chain, and internal sites. You cannot fill that in from your own desk. You need the planner who knows the open orders and the service engineer who knows what is installed in the field. The alignment with them happens in a meeting: the technical review, or enterprise change assessment, where the owners of the impacted items assess the change together.
The result is captured in the impact matrix, which lists for every impacted baseline the items and datasets that are superseded and what supersedes them. Basically, every function gets one picture of the change that it can read in its own terms.
A high-risk change goes to a change review board of senior managers, who decide. An approved change goes to a change implementation board with representatives from every activity the change affects. When the impact crosses the company boundary, the supplier belongs at the table too. Who sits in these meetings follows the impact matrix, based on dependencies in the product, not the organization chart. For every change, the process builds the communication structure that this change needs, as Conway recommended.
The organization chart decides who you report to. The impact matrix decides who you talk to.
Imagine a change to the fasteners of a bracket. In the organization chart, it is an engineering change. Still, in the impact matrix, it is also a new part number for purchasing and an updated work instruction in the factory, while service can stay away if no spare parts are affected. Without a change process, each of them finds out when the first bracket does not fit. With it, they sit at the same table before implementing anything.
Reactions from the discussion
In the discussion under Jos’s post, Benedict Smith asks why communication got shaped this way and who benefits from keeping it that way. That is a fair question, and Conway pointed at incentives himself. CM2 has one small structural answer: program managers do not chair the change boards, so the person who owns the schedule does not decide on the change. It does not fix local KPIs; that remains a leadership job.
Martin Eigner finds Conway’s Law software-centric and asks whether it isn’t the other way around, with our fragmented, siloed structures driving the fragmentation of IT. Read that way, it is Conway’s Law itself, and Conway’s paper is not limited to software, so we may agree more than it seems. Martin is right that a PLM system is too much of a niche to change an organization. Configuration management, however, is a discipline rather than a system, and it governs the interfaces between the other disciplines.
In a follow-up article, Oleg Shilovitsky questions whether value should depend on organizational change first and proposes a product context layer around one decision. At the same time, people keep using their own tools. It is a good idea, and he adds that the result still goes through the agreed revision process. That is where configuration management comes in, because a change notice with its impact matrix has been the context for one decision for decades.
Uthayan Elangovan added in the thread that an engineering change rarely stays within engineering, and that clear decision ownership is the real challenge. I agree with both. The first is why I wrote Stop Calling Product Changes: “Engineering Changes”!, and the second is what the implementation board gives you. Setting one up still takes some organizational change, but far less than a reorganization, and it grows change by change, as Oleg suggests.
When does stimulating collaboration backfire?
Morten Hansen showed that internal collaboration can destroy value, and CM2 deals with that through proportionality: low-risk changes take the fast track, and only full-track changes go to the boards. A board can also turn into theatre, where people attend but nobody owns their part of the implementation plan.
Jody Hoffer Gittell found something similar in hospitals: team meetings between care providers only improved patient care when they built shared goals and knowledge.
The biggest risk is CM itself. In my old post, everyone assumed John would review it anyway, and if the CM function carries all the coordination, the new excuse becomes “CM will check it anyway,” and the silos never meet. I think a change process alone cannot prevent that; it takes leadership commitment to the change process.
Conclusion
Alex Bruskin compared Conway’s Law to gravity in the thread: you cannot switch it off, but you can still build things that fly. The title asks whether configuration management can beat Conway’s Law. Well… “beat” may be too strong a word, but the change process works against it every time a change crosses a boundary. More on the impact matrix in CM2: the cross-platform standard for impact analysis!.
My advice: look at the meeting structure of your change process, who sat at the table for your last ten full-track changes, and who should have. Feel free to start with one product line.
Jos, Benedict, Martin, Oleg, Uthayan, and Alex, thank you for the discussion. If it is not the change process, what else makes the right people talk before a change is implemented? Let me know what you think.