Conway's Law and the three org archetypes

Your software ends up shaped like your communication structure. That's not a metaphor — it's a constraint. So org design is an architectural decision, and three archetypes (Functional, Matrix, Market) lead to predictably different software.

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. The larger an organization is, the less flexibility it has and the more pronounced the phenomenon."

// Dr. Melvin Conway — Conway's Law, 1968.

Eric Raymond's restatement in The Cathedral and the Bazaar: "If you have four groups working on a compiler, you'll get a 4-pass compiler." Done well, Conway's Law makes teams independent. Done poorly, every small change creates global, catastrophic consequences.

// the three archetypes

ARCH_01

IDLE

apartment

Functional

Optimize for expertise

Centralize expertise into deep silos — server admins, DBAs, network admins, security. Tall hierarchies. Great for cost and skill mastery; terrible for end-to-end flow because every value stream crosses every silo and waits.

ARCH_02

STANDBY

grid_view

Matrix

The compromise

Combine functional + market. Reality: individual contributors report to two or more managers, achieve neither goal cleanly. Common in big enterprises; rarely the right long-term answer.

ARCH_03

ONLINE

bolt

Market

Optimize for speed

Organize around the customer / product / value stream, not the function. Each team has everything it needs to ship — including ops, QA, infosec. This is the DevOps target shape.

// the functional failure mode

Traditional IT Ops, organized by function, is optimized for cost. What you actually get:

— Long queues between every step (ticket waits weeks for a DBA, then weeks for network, then weeks for security).
— The person doing the work has no visibility into where it fits in the value stream — "I'm just configuring servers because someone told me to."
— Creativity and motivation vacuum at the worker level; finger-pointing across silos when things break.
— Even small features cross every silo: combinatorial coordination, multi-month lead times, predictable rework.

// this isn't a personnel problem. it's a system-design problem.

// the market-oriented target

To get DevOps outcomes — fast flow, high quality, motivated workers — organize teams around the value stream. Each market-oriented team owns:

owns

Product/service end-to-end — design, code, test, deploy, run, support.

includes

Dev, Ops/SRE, QA, Infosec — together, in the same standup.

enables

Decisions without waiting for handoffs. Daily deployments. Real ownership.

// the warning

"As tempting as it seems, one cannot reorganize your way to continuous improvement and adaptiveness. What is decisive is not the form of the organization, but how people act and react."

Reorganizing alone is theatre. Combine market orientation with the behaviors from Modules 01–02 (visible work, fast feedback, blameless culture) or you'll just have a different shape of dysfunction.

help Knowledge Check

Question 1/2

An org has four siloed teams: Dev, QA, Database, and Security. Every release requires sequential handoffs through all four. Conway's Law predicts:

// pick one to verify

help Knowledge Check

Question 2/2

A CIO restructures IT into "feature teams" but keeps a single shared database team that owns all schemas and gates every change. What happens?

// pick one to verify

arrow_back mod-03 / overview mod-03 / teams arrow_forward