Issue 0006: Systems Design and Incumbent Disadvantage

Issue 0006: Systems Design and Incumbent Disadvantage

Right now every company with outside investors and a board of directors is having some version of this conversation: we're not freezing hiring right now, or doing layoffs, exactly, but we're also not backfilling natural attrition either. We're piloting Claude, Cursor, and Copilot to see what efficiency gains we can make before we put out any new reqs.

Most CEOs and operating partners are framing this as a cost decision, which isn't wrong. Every one of them has the same goal: keep headcount flat while scaling revenue. The cost of AI tooling is marginal (if managed correctly) compared to the cost of adding people. If you can do $2M EBITDA with 50 people, you can use AI to do $3M EBITDA with 50 people.

That framing makes sense as far as it goes. It just isn't the whole frame. Cost is one variable. The harder one, and the one fewer operators are weighing, is what these decisions are doing to the foundation the company will be running on three years from now. Some hiring decisions are tactical. Some are architectural. In normal times the two get conflated and it doesn't matter that much. In the middle of a platform shift, it matters more, and the conflation gets expensive.

Upstream Systems Decisions

In any system, a small number of decisions disproportionately determine what's possible downstream. The data model. The product architecture. The org structure. The founding team. Get them right and everything built on top compounds. Get them wrong and the cost of changing them grows over time.

This is the actual core of systems design as a discipline. Not the diagrams, not the language, not the methodology fights. The discipline is recognizing which decisions form the foundation and which are just tactics, before the difference is obvious in retrospect.

The hard part is that the irreversibility usually isn't only technical. It's also psychological. By the time the foundation looks wrong, the company has built so much on top of it that tearing it down feels worse than living with the cost. It's why operators stay inside org structures that don't fit anymore, even when the cost of the misfit shows up every month in board reports.

What I've noticed working with PE-backed operating companies is that almost no one makes the foundation-versus-tactics distinction explicitly. People talk about hires as cost decisions, capacity decisions, succession decisions, and culture decisions. Rarely as architecture. An open req shows up in the budget cycle as a line item with a fully loaded cost and a start date, not as a claim about what the company's functions will look like in three years.

Most decisions in a company are tactical. They're reversible. A pricing experiment can be reversed. A vendor can be swapped. Foundation decisions are the ones that aren't. They ratchet. If you could take this decision away tomorrow and the rest of the company would keep working, it was tactical. If removing it would force you to rebuild three other things to get back to where you are now, it was foundational, whether you treated it that way at the time or not.

The discipline is making the call upfront, with imperfect information, and pricing accordingly. Foundation decisions deserve more deliberation and downside-modeling; tactical decisions deserve to be made fast and adjusted often. Operators who flip the two obsess over reversible decisions and rush through irreversible ones.

The cleanest recent example of the cost of getting this wrong sits one platform shift back, in the cloud transition that some enterprise IT shops are still finishing.

What Pre-Cloud Companies Didn't Know They Were Buying

Companies that scaled before AWS came online in 2006 didn't know they were making a foundation decision when they bought servers. Servers looked tactical. They were operating infrastructure: pick a vendor, size the rack, stand it up, move on. The decision didn't feel architectural at the time because there wasn't yet a meaningful alternative to architect against.

The bill came due a decade later. By the time the cloud-native alternative existed, and customers, regulators, and competitors were demanding the speed it enabled, those companies had built operational layers, security layers, compliance frameworks, and entire IT departments on top of on-prem infrastructure. None of it could be peeled off cheaply. Almost all of it had to be rebuilt during the migration, and the cost of replacing the foundation became the cost of replacing the work too.

Accenture alone reported $24.5 billion in Public Cloud IT Transformation Services revenue in 2024. That's one firm in one year, over a decade after cloud became the standard. Accenture committed $3 billion in 2020 specifically to staff up for the growing migration wave, and the wave is still cresting. Deloitte, EY, KPMG, IBM, and the rest of the global integrators captured comparable streams.

The companies that started after 2010 mostly skipped the bill. Stripe doesn't have a cloud migration story. Notion doesn't have one. Neither does Figma or Airtable. They were never on-prem, so there was nothing to migrate. The savings showed up as cycles spent on product instead of infrastructure, and as competitive speed against incumbents still wrestling with their own past.

What the pre-cloud companies didn't know in 2006 was that they were making a foundational decision masked as a tactical one. The cost was invisible at the time and obvious in retrospect, and that shape is worth holding in mind right now, because operators might be about to make a similar decision with their org charts.

The Chart Is the Architecture

The architecture of a company isn't usually any individual hire. It's the existence and shape of functions. Finance, sales, marketing, operations, engineering. The departments themselves, with their charters and their boundaries with each other, are the architecture. When a CEO and an operating partner debate whether to add another analyst, the analyst is the hire; the existence of Finance as a department is the architecture the analyst is being added to.

Most of this architecture has been remarkably stable for a long time. The CFO and Finance look fundamentally similar to what they looked like in 1985, with more software and tighter dashboards but recognizably the same function. The CRO and Sales have moved from index cards to Salesforce, but Sales has been continuous as a named function for a century. Marketing's tools have changed completely, but Marketing as a function has not. The architecture has been stable long enough that most operators treat it as fixed.

It isn't fixed. It's just unusually stable. Technology has, on a small number of occasions, created entirely new functions or eliminated existing ones. The structural change of the chart, not the staffing inside it, is what matters for the operator trying to figure out where the foundation decisions are. Three examples: the typing pool, the IT department, and Customer Success.

Through most of the 20th century, every company of any size had a typing pool. A dedicated function that produced the letters, contracts, memos, and reports the rest of the company generated by hand or by dictation. The word processor didn't shrink the typing pool. It eliminated it. The function vanished and the work redistributed onto every desk in the company. No one in 1975 was debating whether the typing pool was still the right architecture. It was load-bearing infrastructure. By 1990 it didn't exist.

Through most of the 20th century, there was also no IT department. Computers, where they existed at all, were specialized operations equipment managed inside accounting or inside a data processing group reporting to finance. The IT department as a named function with its own VP, its own budget line, and its own seat at the C-suite emerged in the 1980s and 1990s as computing became central to every other function. Twenty years later, the cloud shift began partly unwinding the same function: cloud-native companies often don't have a traditional IT department at all; the work is distributed across engineering, security, and the function leads themselves.

Customer Success is a third recent case, smaller but worth noting: the function didn't exist in any meaningful form before 2010, and now it's standard in any B2B SaaS business. Subscription economics created a function that pre-subscription companies didn't need.

The Forward Deployed Engineer (FDE) is another function that's a matter of some debate: is it a brand new function mandated by the increasing need for highly customized software, or a gimmicky rebranding of the IT consultant which has been around for decades? That's a topic I'll explore in more depth another time.

This isn't an argument about net job creation or destruction. The typing pool's work redistributed and office employment kept growing for decades; the IT department was a deliberate net addition. The shape of the chart changed in both cases, and the shape change is what mattered. The same will be true of whatever the AI era does to functional architecture: some functions will grow, some will shrink, some will appear, some will merge. The operator's job isn't to forecast the net direction. It's to examine the chart from first principles and ask whether its shape still makes sense, instead of treating it as given.

Organizational Architecture Examples

The current version of this move is happening in real time.

Jack Dorsey at Block and Brian Armstrong at Coinbase have both restructured their companies over the past year around the explicit premise that the triangle-shaped org chart, with humans organized into functions and information moving up and down a hierarchy, is the wrong architecture for a company running on AI as an organizing principle. Dorsey's version was not a distress move: Block cut headcount from over 10,000 to just under 6,000 while posting record gross profit, then published an essay with Sequoia's Roelof Botha arguing that AI can now do the coordination work middle management exists to do.

Brian Halligan, the HubSpot cofounder now at Sequoia Capital, has called this pattern "Dorsey mode" and argues that a new functional architecture is emerging in which AI sits at the center of the org rather than at the bottom of it. Whether they're right about the specific shape of that new architecture is a separate question. What they're definitely doing is treating the chart itself as a foundational decision worth getting right, rather than as a fixed inheritance from previous eras.

The hiring decisions PE-backed operators are making right now are happening inside the existing functional architecture. Finance gets another analyst. Sales gets another rep. Operations gets another coordinator. Each of these is sensible inside the assumption that Finance, Sales, and Operations will look in 2028 like they look today. That's the assumption worth examining.

What I've seen in PE-backed operating companies between $10M and $100M of revenue is that the assumption is rarely surfaced as an assumption. It's baked into the budget template that carries this year's departments forward as next year's rows, into comp bands built around functional titles, into reporting lines that mirror the chart, and into a board pack that reports by function because it always has.

Each tactical hire reinforces the existing architecture and makes it harder to change later. Twenty of them inside a chart that's wrong become twenty positions baked into process, comp, and budget.

In three years, if AI tooling has absorbed the operational portion of some of those functions cleanly and competitors who built around a different functional architecture are running leaner with better unit economics, the original architecture becomes the on-prem server farm. It can't be peeled off in pieces. The reorganization will hurt more than the original hiring decisions saved.

Where the Analogy Breaks

The cloud analogy is useful but it doesn't transfer cleanly to functional architecture, and the place it breaks down is worth naming.

When a company chose cloud over on-prem in 2010, the alternative architecture already existed. AWS was running. AWS-native companies were operating. The cost structure was visible. The bet wasn't blind; it was informed by other companies' operating data.

Predicting which functions will collapse, which will emerge, and which will hold their shape is a real bet with real downside. There are experiments and there are guesses (Halligan, Dorsey, Armstrong), but the post-AI org chart isn't something you can copy from a public S-1 yet. If anything, most of those companies are likely to be laggards.

Specialization, the reason functions exist as separate things in the first place, also doesn't go away because the tooling changes. Finance, sales, marketing, and operations require different skills, cadences, metrics, and management styles. Collapsing functions based on a guess about tooling is one of the classic reorganization mistakes; the work doesn't get easier because the boxes on the chart get moved.

Halligan, who is otherwise quite confident about what the new architecture looks like, has already run this experiment once. Four years into building HubSpot he eliminated org charts and titles, the company rejected the change, and he brought the structure back within nine months. That history applies directly to the businesses private equity buys. The chart at $10M to $100M of revenue is small enough to actually change and big enough that change is genuinely painful, which is the worst possible combination if the decision is being made implicitly.

So the point isn't prediction. In 2026, most predictions about the AI-era functional architecture will be wrong. The point is that the assumption of stability is itself a bet. The operator who recognizes it as a bet has the option to size it accordingly: hire conservatively into the parts of the chart most likely to change, hire confidently into the parts most likely to persist, and watch for the structural shifts as they emerge. The operator who treats today's functional architecture as the permanent floor has chosen a bet without recognizing they chose it.

Four Questions for Your Chart

No operator can see the post-AI functional architecture from here, and anyone confident enough to tell you exactly what their org chart should look like in 2028 is mostly telling you about their own confidence. The operating principle when uncertainty is this high is preserving optionality, a theme I'll consistently revisit: hire in ways that can be unwound, build process that doesn't depend on the current chart, and pay a small efficiency premium now to keep the option of being nimble later. In the meantime, there are a few questions worth running on your current chart and your open reqs.

1. Which of the named functions on your org chart were created by a previous technology shift, and which existed long before any technology made them visible?
2. If you were starting the company today, with the tooling that exists in 2026, would you still organize work into the same set of functions? Which would you keep? Which would you collapse? Which would you create that don't exist now?
3. Inside each function, how much of the work is process that AI tooling will absorb cleanly in the next 24 months, and how much is the judgment that defines what the function does?
4. If you had to migrate the company to a 2028-native functional architecture tomorrow, what would the bill look like?

The pre-cloud companies didn't get the bill in 2006. They got it in 2016, and they paid it to Accenture. Your org chart is a foundational decision whether or not you treat it as one.