The paper in front of you
The paper on your desk this quarter proposes teams, reporting lines, an executive sponsor and a committee structure for a new AI capability. A group product manager reports to the CIO. A model risk officer reports to the CFO. A data platform lead reports to the CTO. Deployment is contracted through the delivery function. Two committees are proposed to co-ordinate across all of them. The paper asks for your sign-off before vendor selection begins next month. It has already been through the people function. It is the last major decision before procurement starts.
In Brief
- Conway's Law: the org design paper approved before an AI program starts decides more about systems than the platform choice made later.
- Groups that ship AI systems ship architectures that mirror the group — its reporting lines, hand-offs, and committee memberships.
- Placing model risk and deployment under one accountable owner produces an AI pipeline where risk is part of the release, not a gate after it.
- Once teams are stood up and platforms procured, the window to shape system architecture through org design closes.
- Ask your transformation lead which reporting lines produce the system properties your executive committee actually wants.
The decision looks like an org design decision. In practice it is the first decision about the AI systems those teams will build, and it is being made before any technical work has started. By the time the platform is chosen and the pipelines are built, what those pipelines can do will already have been constrained by who is talking to whom.
What was decided in 1968
Melvin Conway named the pattern in 1968. Writing in Datamation, he observed that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” (Conway, 1968). Any group that ships a system ships an artefact that looks like the group that shipped it: the hand-offs, the meetings, the reporting lines, the places where information stops moving. Conway’s Law has held for nearly six decades and every generation of technology since has produced fresh evidence for it.
For an executive sitting in front of a fresh org design paper, that observation is not academic. Conway’s Law is already deciding the architecture of the AI systems your organisation will build. The org chart you approve this quarter is a specification for the systems those teams can produce together. Conway’s Law will apply whatever you decide. Your choice is whether to use it deliberately, by picking an org structure that produces the systems you want, or accept whatever the default arrangement generates.
Why Conway's Law keeps holding
Org design decisions and system design decisions look like they belong to different functions, and that is why Conway’s Law reliably survives contact with strong leadership teams. Org design sits with the executive committee and the people function. System design belongs to the technology function and its vendors. Each side treats the other as context, rather than input. The org paper gets written without a systems architect in the room, and the system paper gets written after the org has been set. Neither side is being negligent. The decision-making structure itself keeps the two sides from meeting on the same page.
So the org decision, which is upstream, silently constrains the system decision, which is downstream. Teams that report through different lines produce components that talk through the same choke points their people do. If model risk sits under finance and deployment sits under delivery, the AI release process will feature a formal risk sign-off as a gate at the end, because that is the only shape the two functions have available for talking to each other. If model performance belongs to data science and cost belongs to the platform function, the operational picture will fragment along the same seam. The architecture mirrors the organisation because the organisation is the drafting instrument.
One deliberate move
Naming this is not a warning. It is an instrument that most transformation programs leave unused. A single, deliberate change to the org design produces a specific, predictable change in the systems that follow.
Take one concrete move. In most organisations, the model risk officer sits inside a second-line risk function reporting to the CFO or the Chief Risk Officer. The deployment lead reports through the delivery function to the CIO or CTO. Model risk reviews happen at the end of the model development cycle, before release. Under the default org design, this looks correct: separation of duties, independent oversight, clear accountability.
Now move the model risk officer into the same team as the deployment lead — reporting to the same accountable owner, sitting in the same standups, working from the same backlog. The formal risk mandate stays intact; the reporting line and daily proximity change. The system that team ships will look different from the one produced by the default arrangement. Risk decisions become part of the release pipeline rather than a gate applied to it after the model is built. Testing incorporates risk scenarios early. Release criteria include risk metrics as first-class conditions rather than attachments. The audit trail is generated by the release process, not reconstructed for the committee after the fact. Six months later, your organisation has an AI capability where risk assurance is a property of the system rather than a compliance step performed against it.
That system property emerged from the org decision, because the org decision was what created the working conditions that produced it.
What the org paper is deciding
If Conway’s Law is the drafting instrument, then the org design paper in front of you this quarter is doing more than allocating people. It decides which AI system properties become natural for your organisation to produce and which become expensive. It settles whether risk assurance is integrated or bolted on, whether the AI operational picture is coherent or fragmented, and whether the model lifecycle is a single flow or a hand-off between functions. These are architectural decisions, made in the language of reporting lines rather than the language of systems, but architectural decisions all the same.
The cost of leaving these decisions to default is not visible at approval. It becomes visible eighteen months later, once the platforms have been procured, the pipelines have been built, and your organisation discovers an AI capability that mirrors an org chart no-one deliberately designed. The distance between the systems your executive committee intended and the systems the organisation is running widens with each new AI use case built on the same foundation. By the time the pattern is legible from the outside, changing it costs as much as unwinding the platforms as it does the org.
The question for your transformation lead
What this means for senior leaders: the org design paper is the highest-value AI architecture decision available to you this quarter, and it is available now in a way it will not be six months from now. Before the next AI program is stood up, put a direct question to your transformation lead: for each of the three or four system properties we most want this AI capability to have — integrated risk, unified operational visibility, model portability across products, single lifecycle governance — which reporting lines, team compositions and committee structures produce that property as a natural output of how these people work together? That question turns the org design paper from a staffing document into an architecture specification.
The executive who sees the AI systems being decided in the org design paper, before the paper is signed and the vendor selection begins, is working with a different organisation eighteen months later than the one who inherits the architecture chosen by default.
References
Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31. https://www.melconway.com/Home/Committees_Paper.html
