There is a strange gap in American software. At one end sit the companies large enough to turn engineering practice into infrastructure: Amazon, Apple, Microsoft, and their peers can afford dedicated platform teams, internal tooling, architecture review boards, and years of accumulated institutional memory. At the other end sit the garage companies and small shops that don’t pretend to have a software development life cycle at all — they deploy from a laptop because the product is one person, the customer is waiting, and the alternative isn’t a more rigorous process but no product. Between those poles sit thousands of companies with enough software to need engineering discipline and not enough margin, attention, or organizational slack to make it a first-class concern. That middle is where most software actually gets written, and it is the part of the industry the industry’s own literature has the least to say about.

I. Not a Failure of Knowledge

The missing middle is not missing knowledge. The practices have names — SDLC, domain-driven design, continuous integration, observability, threat modeling, automated testing, incident response, documentation, code review. The books exist. The consultants can explain the maturity model in a conference room, and the engineers can describe the consequences of skipping each step from memory, because most of them have lived those consequences firsthand. The problem was never ignorance. Process arrives in these organizations as a second-order concern, subordinate to whatever the market is punishing this quarter.

That distinction matters. Saying a company “has no engineering culture” makes the failure sound like negligence. Often it’s closer to triage. Sales needs a feature before a competitor ships one. A customer has found a production bug and is threatening to leave. The board wants evidence of growth by Friday. A migration has already slipped twice. Under those conditions process isn’t rejected philosophically — it’s postponed, and postponement repeats until the exception becomes the operating model. Ward Cunningham coined “technical debt” at OOPSLA in 1992 as a metaphor, not an accusation: a loan you take out deliberately, with the expectation of paying it back. What the metaphor leaves out is that in the missing middle, nobody ever schedules the repayment. There’s always a more urgent loan to take first.

II. The Hyperscaler’s Economy of Scale

At the top of the market, process becomes a competitive asset because scale creates room to pay for it. A company serving hundreds of millions of users can justify a whole team whose job is making other teams faster and safer. It can absorb a platform rewrite, run a service catalog, require design reviews, and treat reliability as a product feature, because an outage has a measurable global price. Amazon’s internal machinery — the six-page narrative memo replacing the slide deck, the “working backwards” press release written before a line of code, the two-pizza team as an organizational primitive — is documented in enough detail, notably in Working Backwards by two of its former executives, that it reads less like culture and more like infrastructure with a headcount line item.

This isn’t superior virtue. It’s an economy of scale. Engineering process has a fixed cost: someone must define it, teach it, automate it, measure it, and defend it against the next urgent request. Distributed across enough revenue and enough teams, that investment starts to look obvious. Fred Brooks, describing what actually eats a large software project’s schedule in The Mythical Man-Month, argued that communication overhead grows faster than headcount — and hyperscalers responded not by staying small but by industrializing the overhead itself, building the org chart to match the software, exactly the reverse of Conway’s Law, which observes that systems end up shaped like the organizations that build them. At that scale you can afford to design the organization on purpose.

III. The Founder’s Advantage

The smallest companies escape the same expectations for the opposite reason. A founder can hold the whole system in their head. The person who talks to the customer is the person who changes the code, deploys the service, and notices when it breaks. There may be no formal SDLC, but the feedback loop is short and the domain model is carried socially rather than written down. This arrangement fails as soon as the system or the team grows, but before that point, the ceremony saved may be worth more than the future risk it defers.

The garage company isn’t necessarily immature for working this way. It may be making a rational exchange — speed and survival now for maintainability later. The trouble begins when the company keeps the startup operating model after it has acquired the complexity of a larger institution. A team of twelve can no longer share every assumption. A product with several integrations can’t be safely understood from memory. The organization has crossed the threshold where informal coordination stops scaling, but the market hasn’t granted it the budget to build a formal alternative.

IV. The Priority Tax

This is where the middle gets trapped. Every engineering practice competes with a visible business priority. Tests don’t look like revenue. Refactoring doesn’t appear in the demo. Documentation produces no screenshot for the board. Domain modeling is hardest to defend precisely when the domain is changing fastest. The organization can see the cost of delaying a feature today and can only estimate the cost of weakening the system tomorrow — and estimates lose to line items in every budget meeting ever held.

So the company cuts the corner, ships first, and promises to enforce the process later. Sometimes that’s the right call — software isn’t a bridge, and not every release deserves the same ceremony. But “later” has a habit of arriving attached to another deadline. The temporary exception becomes a precedent, the precedent becomes an expectation, and eventually the team is told the process is failing when it was never allowed to become part of the product’s definition of done. The result isn’t chaos in the dramatic sense. It’s a slow priority tax: each shortcut makes the next change slightly more expensive, each undocumented assumption makes one person more necessary, and each emergency leaves the organization less able to invest in the conditions that would prevent the next one. The company stays functional, which is exactly why the tax is so hard to see. It’s paid in lost options, not in visible failures.

V. What First Class Would Actually Mean

Making engineering process first class can’t mean importing Amazon’s rituals into a company with twenty engineers — that confuses the visible form of scale with the reason for the practice. The question is smaller and more demanding: which minimal habits preserve the organization’s ability to understand, change, and recover its own system as it grows? A test around a revenue-critical rule may matter more than a hundred-percent coverage target. A shared domain vocabulary, the kind Eric Evans called a ubiquitous language, may matter more than a fashionable architecture. A deploy that can be reversed in five minutes may matter more than an elaborate release train nobody has time to run.

The missing middle doesn’t need maximal process. It needs explicit process — a deliberate agreement about which risks the company accepts, which decisions must be recorded, and which shortcuts expire instead of becoming permanent. The hard part was never selecting the tools. It’s giving someone enough authority and time to defend the future against the present, without pretending the present is irrational for asking to survive.

Further reading