The Ratio That Exposes Everything
When Veeva Systems went public in 2013, it had roughly 1,000 employees and was generating more than $130 million in annual revenue. When Salesforce reached similar revenue, it had nearly four times the headcount. The difference was not that Veeva’s engineers were supernaturally productive. It was that Veeva had built a focused product for one industry (life sciences), sold it to buyers with high willingness to pay, and avoided the sprawling feature work that large sales pipelines tend to generate.
This pattern repeats across software with unusual consistency. The companies posting the strongest operating margins are rarely the ones with the largest engineering organizations. They tend to be the ones that constrained hiring while they still could, before growth pressure and internal politics made adding headcount feel like the only available response to problems.
Understanding why requires looking at what software companies actually spend engineering effort on, and how quickly that composition shifts as a company grows.
What Engineers Actually Build After Year Three
In the early life of a software company, engineers build the core product. This is the period when headcount and output have a fairly linear relationship. Add an engineer, get more product. The connection is direct enough that it feels like a permanent law.
It is not. By year three or four of meaningful growth, the composition of engineering work shifts significantly. A growing share of effort goes to integrations that enterprise customers require before signing. Another portion goes to compliance features — audit logs, role-based access controls, data residency options — that generate no revenue directly but block deals without them. A third category is technical debt accumulated during the fast-growth phase, which compounds interest in the form of slower feature development and more frequent incidents.
None of these categories scale with revenue. A single enterprise customer might demand a Salesforce integration, a SOC 2 audit trail, and a custom data export format, while paying the same price as a customer who needed none of those things. The engineering cost is customer-specific. The pricing usually is not.
The companies that maintain high margins are the ones that find ways to minimize this category of work, either by staying in a vertical where customer requirements are homogeneous, by building platforms flexible enough that customers self-serve their own customizations, or by simply saying no more often than their competitors do.
Why Headcount Compounds Against You
Software has famously low marginal costs for serving an additional user. But that math applies to the infrastructure layer, not to the engineering organization. Engineers are not a marginal cost. They are a fixed cost that grows, because every engineer hired creates downstream demand for more engineers.
This is the mechanism that most analyses of software margins skip over. When a company hires 50 engineers, it also creates eventual demand for engineering managers to coordinate them, platform engineers to maintain the internal tools they use, security engineers to manage the expanded attack surface, and data engineers to handle the instrumentation they generate. None of these roles appear on the initial hiring plan. They appear 18 months later, when the absence of them becomes painful.
The result is that engineering organizations do not scale linearly with headcount. They scale superlinearly, because coordination costs grow faster than the team itself. Fred Brooks identified this dynamic in software project management decades ago: adding people to a late software project makes it later, because communication paths grow with the square of team size. The same logic applies to organizational efficiency at scale.
Companies that stay small by design avoid accumulating this overhead. Those that grow headcount aggressively during good revenue periods find that the overhead persists even when they try to cut back.
The Vertical SaaS Advantage
The clearest examples of high-margin, low-headcount software tend to cluster in what analysts call vertical SaaS: software built for a specific industry rather than horizontal tools that anyone might use. Toast for restaurants, Procore for construction, Veeva for life sciences, Guidewire for insurance.
The margin advantage of vertical software is not accidental. When your entire customer base operates in one industry, their technical requirements converge. The insurance company and the other insurance company want essentially the same compliance features, the same data structures, the same integrations. Each feature built serves the entire customer base rather than a single account. The ratio of revenue per engineer improves because the denominator (unique engineering work) stays controlled while the numerator (customers paying for it) grows.
Horizontal software companies face the opposite dynamic. Serving customers across industries means that each customer segment introduces requirements that do not generalize. The engineering organization expands to serve this diversity, and the margin advantage of software economics erodes toward something closer to professional services.
This is not a knock on horizontal software. Some of the most valuable companies in technology are horizontal. But the margin profiles tend to be weaker, and the engineering organizations tend to be proportionally larger, for reasons that are structural rather than managerial.
When Sales Velocity Becomes an Engineering Tax
Rapid revenue growth is almost universally celebrated inside software companies. It is also, in a specific and underappreciated way, a tax on engineering capacity.
The mechanism works like this: when a company is growing quickly, the sales team is closing deals faster than the product team can support them. Each new customer arrives with an onboarding process, often with customization requests, sometimes with integration requirements. The post-sales burden falls on engineering. The company hires to address the backlog, which lowers margins, which is tolerated because revenue growth is strong. Then growth slows, the engineering costs do not, and the margin problem becomes visible.
The companies with the best long-run margins either sell products that require minimal post-sales engineering (typically because the product is genuinely self-serve), or they price the onboarding and customization work into the contract rather than absorbing it as a cost of sales. Both approaches require discipline that is easier to describe than to maintain when the sales team is bringing in contracts.
The Misread Signal of Engineer Count as Quality Proxy
The tech industry developed a habit, particularly in the 2010s, of reading headcount as a signal of ambition and quality. The companies with the most engineers were taken most seriously. This created pressure for software companies to hire aggressively as a form of credibility-building, independent of whether the work existed to justify the hiring.
This was always a confusion of cause and effect. Large engineering organizations at successful companies were the product of growth, not its cause. A company that grew to a thousand engineers by building products that millions of people used was not successful because of the engineers. The engineers were there because the products worked, and working products required support at scale.
The misread signal produced a generation of software companies that hired engineering talent before they had the revenue to justify it, on the theory that the talent would generate the revenue. Sometimes it did. More often, it produced high burn rates, moderate products, and eventual down-rounds or acqui-hires.
The companies that are worth studying are the ones that did the opposite: built products that worked, let revenue arrive, and hired engineering capacity only as the absence of it became a genuine constraint rather than a theoretical one. This is a harder approach to execute because it requires resisting a category of pressure (investor expectations, competitive anxiety, talent availability) that is very real. But the margin outcomes are measurably better.
What This Means
The relationship between software profit margins and engineering headcount is inverse more often than it is proportional. This is not because great engineers are less valuable at large organizations. It is because the nature of engineering work changes as organizations grow, accumulating coordination costs, customer-specific requirements, and internal infrastructure overhead that add expense without adding customer value.
Vertical software companies have a structural advantage here because their customers’ requirements converge. Horizontal companies can compensate through genuine self-serve design, disciplined pricing of customization work, and organizational restraint around hiring. None of these are technically complicated. All of them are organizationally difficult.
The practical implication for anyone evaluating software businesses is that revenue per employee is a more useful signal than it first appears. It captures, imperfectly but honestly, how well a company has avoided the traps that turn software economics into services economics. A company generating $500,000 in revenue per employee is usually doing something right that one generating $150,000 is not, even if the growth rates look similar.
Headcount is a cost before it is anything else. The companies that treat it that way, from the beginning, tend to build the margins that hold up when growth eventually moderates.
