Scaling is a design problem

Here is a question I like to ask founders: if you doubled your engineering team tomorrow, would you ship twice as fast?

Most hesitate. The honest ones say “probably slower.”

They are right, and the reason is worth understanding in detail, because it decides whether the money you just raised turns into product or into meetings.

The arithmetic nobody budgets for

Add an engineer and you add one unit of capacity. You also add a communication path to everyone already there. Fred Brooks did this arithmetic in 1975: a group of n people has n(n-1)/2 possible connections. Five engineers have ten. Fifty engineers have 1,225.

Capacity grows in a straight line. Coordination grows like a square. Somewhere between those two curves sits every scale-up that hired aggressively and got slower.

The tax never appears on a budget line as “coordination.” It appears as a design review that needs four teams in the room. A release train that waits for its slowest carriage. A migration that has been three sprints from done for two quarters. Each of those is a dependency; every dependency is a meeting, and every meeting is latency. Latency compounds.

This is why “we need more engineers” is so often the wrong diagnosis. You do not have a capacity problem. You have a dependency problem, and hiring makes dependency problems worse.

Technical debt is organizational debt that learned to code

Conway noticed in 1967 that systems mirror the communication structures of the organizations that build them. Sixty years later we still treat that as a curiosity rather than a design constraint.

It is a design constraint. If two teams have to negotiate every release, you will get an architecture that requires negotiation, because that is the only architecture those teams can successfully build. Your org chart is your architecture, whether you designed it that way or not.

So when a codebase is tangled, look up before you look down. The spaghetti is usually downstream of a team topology that made sense at fifteen engineers and was never revisited at sixty. The database that seven teams cannot stop fighting over is rarely a database problem; it is an ownership problem with a schema attached.

Technical debt, in most of the organizations I have worked in, is simply organizational debt that learned to code.

How to tell, without hiring anyone

You can diagnose most of this yourself. Ask five questions and listen for the hesitation:

1. Can a single team ship a customer-visible change to production without another team’s calendar? If not, your boundaries are in the wrong place.
2. How long from an engineer’s first day to their first production deploy? Weeks means the paved road is missing, and every future hire pays that same toll.
3. When something breaks at 03:00, does one team own both the fix and the decision? Split ownership turns incidents into conference calls.
4. How many people approve a routine change, and what have those approvals actually caught? Governance that catches nothing is theater with a calendar cost.
5. Could you show an auditor today every system you run, who can access it, and where the data goes? If assembling that takes a quarter, it will take a quarter every single time.

None of these are technology questions. All of them determine your technology outcomes.

The four designs that decide it

Design the boundaries first. Draw team boundaries around things a team can own end to end: build it, test it, deploy it, run it. Then let the architecture follow those boundaries, because it will anyway. The goal is not microservices; the goal is that shipping a feature requires exactly one team’s agreement.

Guard the invariants, free everything else. You cannot govern everything without paralyzing the company. Pick the handful of things that must not change casually: data contracts, security boundaries, public interfaces. Guard those seriously, with real review. Then make everything behind them cheap to change. A team that wants to rewrite its service in Go on a Tuesday should be able to, provided the contract holds.

Treat the platform as a product, not a side quest. You cannot ask every product engineer to be fluent in Kubernetes, Terraform and NIS2. Give them a paved road: templated, self-service infrastructure that is secure and compliant by default, where the standard path is also the easiest path. Internal platforms have users, and users have alternatives; if your engineers route around your platform, the platform is the problem.

Engineer governance into the floorboards. In a regulated environment this is where scale-ups lose quarters they cannot afford. If every service is created through one standard route, the asset inventory writes itself. If access is provisioned through one automated path, access is provable. A DORA or NIS2 audit then stops being a spreadsheet panic and becomes a report you print. Compliance by design is not a compliance strategy; it is an architecture decision that happens to satisfy your auditor.

What an honest audit looks like

Investors have learned that operational risk destroys returns, and technical due diligence has sharpened accordingly. It no longer stops at ARR and a demo. Who can deploy? What happens when the lead engineer leaves? How long does a rollback take? Is the compliance posture designed, or documented after the fact?

The uncomfortable part is that you can predict almost every question. Which means you can answer them before someone else asks, while fixing the answer is still cheap and does not happen under term-sheet pressure.

That is the entire argument for auditing yourself early. Not because an audit is enjoyable, but because the findings are the same either way; only the leverage changes.

None of this is exotic

There is no new framework here, and nothing that requires a platform migration or the reorg of the year. It is design: deciding, deliberately, where the boundaries sit, what must not change, and what your teams should never have to think about.

Most companies never make those decisions. They inherit them from a whiteboard drawn when the company was a third of its current size, then hire against the consequences.

Scaling is a design problem. Stop hiring your way out of it; start designing your way through it. And design, unlike headcount, is a decision you can take this quarter.