I’ve spent a lot of my career jumping between two very different worlds: free and open source software and enterprise software.

You might expect enterprise software to be more coherent, since they have the massive budgets and the processes for it. But open source projects usually produce a more unified system, even if they look like uncontrolled chaos on paper.

In the enterprise, you often open an app and literally feel the boundary where one team’s work ends and another’s begins. You see the seams. The navigation isn’t structured around what the user actually needs to do; it’s structured around the company’s org chart. Everything feels like a bolt-on.

Contrast that with a tool built by a small, opinionated open source team. It just makes sense. You don’t have to fight it.

What actually causes that gap? What separates SQLite from a disjointed enterprise app? What’s the real difference here?

Conway’s Law gets cited constantly. “Organizations design systems that mirror their own communication structures.” Brooks’s Law covers the timeline angle. “Adding manpower to a late software project makes it later.”

Both useful. But neither explains incoherence. Conway tells you the shape of the system. Brooks tells you it’ll be late. Neither tells you why the product feels like three apps duct-taped together.

I think the missing variable is simpler than either of those.

The law

Software coherence is inversely proportional to the number of people who can say no.

Not team size. Not org structure. Not how many microservices you have or what your sprint velocity looks like. Just this: how many people hold veto power over any given decision?

I’m calling it Hemanth’s Law because nobody else named it yet.

The evidence

I looked at startups, FOSS, and enterprise software and tracked one thing: how many people have to agree before a decision turns into code.

SQLite: a small team, zero outside contributors

SQLite is maintained by a small team of developers spread across three continents, led by D. Richard Hipp. They don’t accept patches or pull requests from the public. Every line is written by the core team.

What does that produce? ~156,000 lines of C with 100% branch test coverage. Over 92 million lines of test code. It runs on every phone, every browser, every OS you touched today. Airbus uses it in flight software. It follows DO-178B aviation testing standards.

One person holds the entire system in his head. Decisions move from thought to code in the same brain. The internal consistency is almost unsettling.

Decision-makers per feature: 1. Maybe 2 on a bad day.

Linux kernel: thousands of contributors, one funnel

The kernel has seen contributions from over 20,000 developers. But writing code and deciding what ships are very different things.

Every patch goes through a subsystem maintainer, then a lieutenant, then (for anything that matters) Linus Torvalds. The MAINTAINERS file maps every file in the kernel to the person who says yes or no.

Thousands contribute. A handful decide. Linus has rejected patches from billion-dollar companies because they didn’t pass his taste bar.

Decision-makers per subsystem: 1 to 3. For the kernel’s overall direction: 1.

Windows Vista: what happens when nobody owns the picture

Longhorn (which became Vista) started around 2001. By 2004 the codebase was so broken that Jim Allchin, co-president of Windows development, called it “a pig” internally. Microsoft threw out the entire codebase and restarted from Windows Server 2003 SP1.

What happened? The Windows team and the .NET team were fighting over managed code vs. native. Multiple groups built disconnected features (WinFS, Indigo, Avalon) with no integration plan. Nobody owned the whole picture.

They eventually reorganized into two divisions, Core OS and Windows Client. Didn’t matter. Vista shipped in 2007, four years late, and the reviews were brutal. The product felt exactly like what it was: a negotiated compromise between teams that disagreed with each other.

Decision-makers per feature: dozens. Architecture review, security review, feature team, platform team, management chain. Every group could block. The product showed it.

Spotify squads: autonomy without anyone in charge of “the whole thing”

Spotify’s squad model (2012) gave small teams full ownership. Each squad was supposed to be a “mini-startup.” In theory this should work. Small teams, clear ownership, right?

In practice the squads turned into silos. Each picked their own tech and UI patterns, making the product feel horribly inconsistent. “Autonomy without consequence” meant squads optimized for themselves, and nobody minded the store for the overall experience.

Each squad had decision-making power. Nobody had integration power. Nobody could step in and say “these five features need to feel like the same product.”

Decision-makers per feature: 1 per squad (fine). Decision-makers for the product as a whole: 0 (not fine).

AWS: giving up coherence for speed

Amazon’s famous “two-pizza team” mandate removed the integration authority veto entirely. By forcing teams to build decoupled services with their own APIs, they got rid of the “unified product vision” bottleneck.

They got speed, but the cost was coherence. The AWS Management Console is notoriously disjointed. EC2 looks and behaves differently than S3, which is completely different from IAM. When you drop the centralized veto, you gain speed but lose the “one mind” user experience entirely.

The pattern

	Veto holders per feature	Product feel	Examples
1-3	Focused, opinionated	Coherent	SQLite, Rails, early Notion, Sublime Text
4-8	Managed, intentional	Solid, less distinctive	Linux kernel, PostgreSQL, well-run startups
9+	Committee-driven	Fragmented, bloated, disjointed	Vista, enterprise platforms, “three apps taped together”

There’s real data behind this. The HBS mirroring hypothesis study (MacCormack, Baldwin, Rusnak, 2012) compared open-source and commercial software using Design Structure Matrix analysis. Open-source projects with fewer centralized decision-makers produced more modular code. Commercial products with committee-driven decisions had propagation costs 8x higher, meaning a change in one place broke 8x more things elsewhere.

Those commercial products weren’t badly written. They were badly decided. Too many cooks making different broths and pouring them into the same pot.

When multiple teams solve the same problem

In high-veto environments, you also tend to get redundant solutions. What happens when two different internal teams try to solve the exact same problem?

If you have a strong integration authority, someone decides early. One approach wins. The other is killed.

But in a consensus-driven environment, neither team has the authority to kill the other’s project. Canceling a team’s work is a political fight that no one wants. To keep the peace, the organization just ships both.

Look at Google. They didn’t just ship one messaging app; over a decade, internal team boundaries gave us Talk, Hangouts, Allo, Duo, Meet, and Chat, all competing for the same users. We’re seeing it happen again right now in their AI ecosystem: a developer looking to build with Gemini has to navigate overlapping capabilities across Google AI Studio, Vertex AI, and Firebase Genkit. Even if someone at the very top had the formal authority, nobody was willing to spend the political capital to step in and say, “this is our only path.”

They are externalizing their internal organizational stalemates onto the user. Consensus doesn’t just produce averages. Sometimes it produces duplicates.

How this differs from Conway’s Law

Conway says the product mirrors the org chart. That’s about shape. Four teams, four components.

This is about coherence. You can have four teams and a coherent product if one person has final say on how the pieces fit. Linus runs a massive org, but the kernel feels like one system because the decision funnel narrows to one person.

Conway tells you what the architecture will look like. This tells you whether it’ll feel like one product or a committee report.

How this differs from Brooks’s Law

Brooks is about time. Adding people makes things late.

This is about coherence, which is a separate axis. You can ship on time and still ship an incoherent mess. Vista eventually shipped. It just shipped something that felt like two organizations built it without talking. Which is more or less what happened.

Delivery time

There’s a corollary here:

Delivery speed is determined by decision latency, the gap between “we should do X” and someone writing code.

At a five-person startup, you decide at lunch and ship after lunch. At a large org, you might need architecture review, security sign-off, accessibility review, legal, and three management layers. The coding takes a day. Getting permission takes a month.

Where this breaks

I should be honest about the weak spots here.

Single decision-makers do become bottlenecks. The same funnel that gives you coherence also caps your velocity to what one person can hold in their head. As a product scales, one person can’t hold all that context anymore. Big tech companies design their org charts purely to solve this throughput problem, and they sacrifice coherence to do it.

Also, coherence isn’t quality. One person with a consistent vision can still be totally wrong. If the person in charge lacks the technical “taste” for the domain, you just end up with a coherently bad product. Sometimes, big companies use bureaucracy precisely to dilute the damage an incompetent leader can do.

And sure, some committees do produce good work. The Apollo Guidance Computer came out of a large bureaucracy and landed on the moon. But even there, Margaret Hamilton’s team was only about 100 people, and she had clear authority. The decision funnel was tight.

The awkward truth

This means what most orgs do to “improve quality” (adding more reviewers and approval gates) actually degrades the product. Every new person in the decision chain just sands down one more edge.

You end up with software that offends nobody and delights nobody.

I constantly see this. You open an enterprise app and wonder if the team who built this screen has ever even met the team that built the next one. The joke is, they probably have. They meet every week with twelve other people, and nothing gets decided.

What I’d do about it

Keep the number of veto holders as small as possible. Not contributors. Vetoes. Let many people write code. Let very few people block decisions.

If you can’t eliminate veto holders, constrain their boundaries tightly. Security gets a veto on vulnerabilities, not user flows. As soon as a domain expert is allowed to veto outside their lane, you slide back into committee-driven design.

Start measuring decision latency, not just cycle time. How long do features sit waiting for a green light versus actually being built?

Establish clear integration authority. The funnel has to be narrow enough to share one context. But if you just give the seat to the person with the most seniority, you get architecture astronauts. If you give it to someone who doesn’t code, you get impossible roadmaps.

The integration authority needs to be someone who still understands the codebase and actually uses the product. It’s a curation role. You need someone with the soft power to tell a team their solution simply doesn’t fit. It creates a single point of failure, sure, but it’s way easier to fix one person’s bad call than it is to untangle a mess built by twenty committees.

Know when to resist the pull toward consensus. Consensus matters for standards bodies like TC39 or Node.js. But even they avoid averaging things out by completely separating creation from approval. A single “champion” shapes a feature, while the committee just audits it. Committees can’t design.

When you’re building a fast-moving product, even audit-level consensus is too slow. You need an integration authority who can look at a room full of squabbling teams and say, “I know we disagree, but we’re doing it this way because the product needs to feel like this.”

One more time

Hemanth’s Law: Software coherence is inversely proportional to the number of people who can say no.

Conway gave us the shape. Brooks gave us the timeline. This is about coherence.

The best software I’ve used was built by a small number of people with strong opinions and the authority to ship them. The worst was built by organizations where everyone had a voice and nobody had a decision.

More vetoes, less vision.

---

References: Conway (1968) “How Do Committees Invent?”; Brooks (1975) The Mythical Man-Month; MacCormack, Baldwin, Rusnak (2012) “Exploring the Duality between Product and Organizational Architectures” HBS; SQLite Testing; Linux Kernel Patch Process; Snover (2025) “The Longhorn Story”; Lee “Spotify’s Failed Squad Goals”; Node.js Technical Steering Committee.