Diseconomies of Scale: Why Software Slows Down as Companies Grow

The Myth of Software Scale

Factories scale linearly. Software scales exponentially in complexity.

We've been sold a lie about software development. The story goes: hire more engineers, build more features, capture more market share. Scale up, scale out, scale everything.

But software doesn't work like manufacturing. Henry Ford could double his factory size and roughly double his car output. Double your engineering team and you might halve your velocity.

Why? Because software is pure complexity. And complexity compounds.

The Coordination Tax

In 1975, The Mythical Man-Month nailed it: every new engineer multiplies communication paths. Two engineers have one communication channel. Five engineers have ten. Fifty engineers have 1,225 (using the formula n(n-1)/2).

This isn't just about meetings (though God knows there are enough of those). It's about cognitive load. Mental models. Shared understanding.

When Facebook was 10 engineers, everyone knew the entire codebase. When it hit 10,000 engineers, no single person could understand how Instagram's photo upload connected to the ad targeting system. The same story plays out in open source: small projects thrive with a few maintainers, but as contributors pile on, coordination becomes the bottleneck. Even startups feel it—at 5 engineers everything is in sync, at 50 you're already fighting entropy.

That's not a failure of documentation. That's the physics of complexity.

The Kubernetes Effect

Remember when deploying code meant uploading files to a server? Now it feels like you need a PhD in container orchestration.

Kubernetes isn't evil—it solves real problems at scale. But notice what happened: we turned deployment from a five-minute task into an entire job family. Twenty years ago "DevOps Engineer" wasn't a title. Today it's one of the most in-demand roles in tech.

Every abstraction we build to manage complexity creates new complexity. We're running faster and faster just to stay in the same place.

The startup using Railway or Vercel deploys with git push. The enterprise with their sophisticated Kubernetes clusters needs three teams, two approvals, and a change management board.

Startups do.

The Chat Spiral

Tools like Slack and Teams were supposed to make communication better. Instead, they've multiplied it beyond reason.

Before Slack: limited channels forced prioritization. After Slack: endless pings, constant context switching, and teams drowning in noise.

One study found employees lose hours each week to chat notifications. Big companies now even spin up channels to manage their other channels—a parody of productivity.

If you want a sharper picture of diseconomies of scale, just compare it to Jira or enterprise email. Both started as tools for clarity. Both ended up as bottlenecks of coordination.

The lesson is simple: the more you try to solve communication with more communication, the less real work gets done.

The Microservices Trap

Netflix championed microservices and became the poster child for scalable architecture. Hundreds of services, thousands of engineers, millions of deployments.

But here's what the case studies don't tell you: Netflix spends more on service coordination than most companies spend on their entire engineering budget. They have entire teams whose only job is understanding how services talk to each other—just to keep the whole machine under control. What looks simple on stage is backed by armies of engineers making sense of service sprawl.

Amazon famously mandated that all teams communicate through APIs. Brilliant for scaling organization boundaries. Painful when debugging production issues across dozens of services.

When your checkout flow touches 40+ different services, good luck tracing why payments fail on mobile Safari in Canada.

The monolith might be unfashionable, but it's fast. DHH at 37signals keeps proving this. Basecamp serves millions of users with a Rails monolith and a small team. Their deployment process? Still git push.

The Meeting Industrial Complex

Large companies don't just write code—they write processes for writing code.

Standups to plan the work. Sprint planning to plan the standups. Retrospectives to discuss the planning. Quarterly business reviews to review the retrospectives.

Each process spawns its own meetings. Each meeting spawns its own artifacts. Each artifact needs someone to maintain it.

I've seen engineering organizations where managers spent more hours in weekly syncs than engineers did writing code. Meetings became the work, and coding the afterthought—a textbook diseconomy of scale.

The ten-person startup has one meeting: "What are we building today?" The thousand-person company has 50 different meeting types, each carefully documented and ritualized.

The Security Theater

Small companies ship fast because they can afford to break things. Big companies ship slow because they can't afford to break anything.

Enter security theater: the elaborate dance of compliance that makes everyone feel safe while making everything slow.

Reviews that nitpick formatting while missing logic flaws. Automated scans that flag trivial dependencies while missing real threats. Pen tests that churn out boilerplate reports nobody acts on.

Each gate adds days to your pipeline. Each approval adds cognitive overhead. Each process adds coordination cost.

The irony? The most secure systems are usually the simplest ones. But simplicity rarely survives layers of corporate process.

The Startup Advantage (Until It Vanishes)

Startups have a secret weapon: they're too small for diseconomies of scale.

With five engineers, everyone knows everything. The system fits in one person's head. Bugs are traceable, features ship fast.

But this advantage is temporary. Cross the thirty-person threshold and the magic evaporates. Suddenly you need "process." Someone suggests Jira. And just like that, speed turns into drag.

The Tooling Delusion

"But we have better tools now!" Docker! Kubernetes! GraphQL! Microservices!

These tools are incredible. They solve real problems. But they don't solve the fundamental problem: coordination cost.

In fact, they often make it worse. Your startup used to deploy one Rails app. Now you deploy 30 microservices, each with its own Dockerfile, Kubernetes manifest, and CI/CD pipeline.

AWS makes infrastructure cheap, but it doesn't make complexity any cheaper. You still need someone who understands how your 20 different services interact when the payment processor goes down.

The ten-person startup on Heroku moves faster than the thousand-person company on their sophisticated multi-cloud Kubernetes setup.

Infrastructure scales. Coordination doesn't.

Coordination as Core Competency

Here's the contrarian insight: in a world where infrastructure is commodity, coordination is the differentiator.

The companies that win aren't the ones with the most engineers or the fanciest architecture. They're the ones that coordinate best.

GitHub didn't win because they had better Git hosting. They won because they made collaboration frictionless.

Stripe didn't win because they had better payment processing. They won because they made integration effortless.

Figma didn't win because they had better design tools. They won because they made design collaboration natural.

The pattern is clear: make coordination easier, focus on your core competency, and you'll move faster.

So What's the Fix?

You can’t eliminate diseconomies of scale. But you can manage them.

• Keep teams small. Bezos had it right with two pizzas. Bloat kills velocity.
• Ship, then perfect. Put work in front of customers fast. Perfect is the enemy of shipped.
• Protect autonomy. Trust engineers and PMs to own outcomes. Cut the approval chains.
• Kill zombie projects. Ruthlessly. Don’t let political corpses eat your runway.
• Re-center on taste. Ask “does this make the product better?” not “does this align with our portfolio strategy?”
• Optimize for understanding. Code that five engineers can understand beats code that one engineer thinks is clever.
• Minimize communication surfaces. Every API is a contract. Every service boundary is a coordination point. Design accordingly.
• Automate coordination sinks. Testing, deployment, monitoring—if people have to babysit it, you're paying a tax that machines can eliminate or reduce.
• Document decisions, not just code. Future engineers need to understand why, not just what.
• Build platforms, not just products. Internal tools that reduce coordination overhead are force multipliers.

The goal isn't to eliminate complexity—it's to make complexity manageable. Turn coordination from a tax into a competitive advantage.

The Future Belongs to the Coordinated

We're entering an era where coordination matters more than headcount.

Companies that learn to scale coordination will thrive. Those that don't will stall out—disrupted by smaller, faster players who haven't yet hit the wall.

This isn't a technology problem. It's a systems problem. And systems thinking doesn't come from AWS.

It comes from leaders who see that software is people solving problems together. Code is just the medium.

The real question isn't how to build faster software. It's how to build software faster. That's coordination, not coding.