Skip to main content

Conways Law

· 8 min read
Lex Lutor Iyornumbe
Lex Lutor Iyornumbe
Senior Software Developer @ Punch Agency

🎭 Submitted for your approval...

🎙 “Imagine, if you will, a perfectly good product… strangled by bureaucracy. A brilliant idea… slowly dismembered by 20 competing opinions. A system design so fragmented, it mirrors a boardroom seating chart. You’ve just crossed over into... Development Hell.” 🌀

🧠 Ever wonder why some tech products feel like they were designed by a game of telephone? Why no two parts quite fit together, and the codebase looks like it’s speaking in tongues?

Let me tell you about a project I worked on that had 20 decision-makers. Not contributors. Not developers. Decision-makers. Each one meant well (I assume, but I doubt it). Each brought something to the table (I assume, but I doubt it). But that table? It buckled under the weight of opinions.

The result?

🚨 Developer turnover.
🌀 Inconsistent design patterns.
đź’Ł A chaotic, bloated codebase.
🔄 And a product that reflected the fractured nature of its creators.

Why did it happen?

Because Conway’s Law—first coined in the classic paper “How Committees Invent”—was not a suggestion. It was a warning:

âťť Any system designed by an organization will inevitably mirror the communication structure of that organization. âťž

So when communication is fragmented, so is the product. And when decision-making is diffused across too many egos, you don’t get innovation—you get a Frankenstein.

🧭 Lessons from Conways Law​

1. Keep Teams Lean, Communication Clear​

“As long as the manager's prestige and power are tied to the size of his budget, he will be motivated to expand his organization... Once the organization exists, of course, it will be used.” — Melvin Conway

Overpopulating a project team might look good on paper—more hands, more progress, right? Wrong. According to Conway, bloated teams often arise not out of necessity, but organizational ego. This leads to fragmentation, slower decisions, and blurred accountability. The more people, the more communication overhead—and the higher the chance for disintegration.

đź’ˇ Lean teams force clarity. Fewer people = clearer channels = faster alignment. Let your communication network reflect the speed and cohesion your system needs.

2. Organize Teams Around How People Must Communicate—Not Hierarchies​

“A design effort should be organized according to the need for communication.” — Melvin Conway

Org charts are great for HR. But when building software systems, they become dangerous if mistaken for the ideal communication structure. The way your team talks should directly inform how it is structured. If two subsystems must work closely, so must their developers.

💡 Structure your teams based on architecture needs, not bureaucratic lines. Let systems and people mirror each other—intentionally.

3. Redesign Your Team if You Must Redesign Your Product​

“The very act of organizing a design team means certain design decisions have already been made… there is no such thing as a design group which is both organized and unbiased.”

Conway makes it clear: your team structure pre-determines what solutions are possible. That means if you're pivoting your product’s architecture or concept, yet keeping the same team setup, you might be boxing yourself into legacy decisions.

đź’ˇ Reorg with purpose. If your product needs a reset, so might your communication pathways and team allocations.

4. Don’t Add People Just to “Go Faster” in Design​

“From experience we know that two men, if they are well chosen and survive the experience, will give us a better system.”

Adding people to meet deadlines—especially in the design phase—is often a recipe for regression. Conway calls this out as a fallacy of linearity: assuming two men working for a year and one hundred for a week are equivalent. They are not. More heads mean more interfaces. More interfaces mean more friction.

💡 In design, small teams win. They're agile, communicative, and aligned. Trust quality over quantity—especially at the system's core.

5. Minimize the Number of Decision-Makers​

“Any system designed by an organization will inevitably reflect the communication structure of that organization.”

The more decision-makers involved, the more the system begins to fracture along political, stylistic, and procedural lines. Conway observed that systems “mirror” their designers. So, 20 decision-makers will not yield one cohesive product—they will yield 20 perspectives poorly stitched together.

đź’ˇ Reduce the decision surface. Delegate execution, but centralize authority. Systems should reflect a clear vision, not a compromise committee.

🎯 Real-World Case Studies Mapped to Each Principle​

1. Keep Teams Lean, Communication Clear​

🚀 NASA – The Apollo Program (1960s): NASA’s success with Apollo 11 came from a lean, compartmentalized structure where each team owned a specific subsystem (navigation, propulsion, life support). The guidance team led by MIT's Instrumentation Lab had full autonomy over the Apollo Guidance Computer (AGC). Their tight-knit team and open intra-team communication were key to delivering an incredibly complex system under massive time pressure.

âś… Small team + clear mission = launch-ready software guiding humans to the Moon.

2. Organize Teams Around How People Must Communicate—Not Hierarchies​

🍎 Apple – Original iPhone Team (2004–2007): Steve Jobs famously formed a secret, siloed, and cross-functional team that operated outside Apple's traditional hierarchy. Why? Because hardware, software, and UI needed to talk constantly—and traditional divisions would've slowed communication and compromised innovation. This team sat in one building, worked across disciplines, and shared ownership over the final experience.

✅ Team communication reflected system architecture — not departmental org charts.

3. Redesign Your Team if You Must Redesign Your Product​

🏕️ Basecamp – Rewrites as Opportunities for Org Realignment: When Basecamp rewrote their core product, they didn’t just refactor code—they refactored teams. They swapped responsibilities, removed redundant layers, and created “Shape Up” cycles to ensure teams were structured for fast, autonomous work. This made space for redesigning the product’s experience and the way teams collaborated.

âś… Changing the product meant changing how the team was shaped. They aligned both.

4. Don’t Add More People Just to Go Faster in Design​

🚀 NASA Again – The “Too Many Hands” Problem with the Space Shuttle Program: Unlike Apollo, the Space Shuttle program was bloated with contractors, overlapping roles, and government agencies. The result? Communication breakdowns, systemic complexity, and eventually, catastrophic failures like Challenger (1986), which were traced back, in part, to a fractured org and poor communication.

❌ More people ≠ more speed. It increased complexity, diluted ownership, and cost lives.

5. Minimize the Number of Decision-Makers​

🍎 Apple – “Directly Responsible Individual” (DRI): Apple assigns every key decision to a single Directly Responsible Individual. This person is publicly accountable and empowered to make final calls. There’s no design-by-committee. Everyone knows who owns what and where the buck stops.

âś… Reduces confusion, speeds up decisions, and preserves product integrity.

✅ Team Structure Checklist: Apply Conway’s Law Intentionally​

Use this checklist before kicking off (or re-aligning) your next product/project:

🔧 STRUCTURE & ALIGNMENT​

  • Have we kept the core team small (ideally < 6 people)?
  • Are communication lines short and clearly defined?
  • Does our team structure mirror the product’s architecture?
  • Are designers, developers, QA, etc. organized to match how their work must integrate?

🧠 DECISION-MAKING & ACCOUNTABILITY​

  • Do we know who is the DRI (Directly Responsible Individual) for every subsystem?
  • Is decision-making authority consolidated, not distributed across too many?
  • Can we remove or delegate unnecessary approval layers?

🧭 COMMUNICATION​

  • Are there frequent, structured check-ins to sync across roles?
  • Are dependencies between teams mapped and interfaces explicitly defined?
  • Do all stakeholders have access to a shared source of truth (e.g., roadmap, docs)?

⚙️ DYNAMIC ADAPTATION​

  • If our product has changed significantly, have we re-evaluated team structure?
  • Is there flexibility to restructure based on system concept evolution?
  • Have we avoided adding people just to meet deadlines without clear ownership plans?

🎬 Final Thought

"Design your team with the same intentionality you design your system. If your people can't talk, your subsystems won’t either."

🕵️‍♂️ The next time you're tempted to pull more voices into the decision room, remember:

“The more people who must say yes, the fewer things will ever get done.”

Don’t let your next product become another lost episode of... Development Hell 🔦