If you’ve spent five minutes in a C-suite meeting, you know the drill. Sales is scrutinized. Marketing spend gets interrogated. Then the group reaches the R&D line item, the multi-million-dollar software engineering budget, and everyone just… blinks.

Engineering is the ultimate “black box” in financial accounting. We produce an intangible asset that traditional balance sheets struggle to value. So we use weak heuristics to allocate our most expensive resource: engineering talent.

During the ZIRP era, nobody cared. We threw seven engineering teams at problems that needed one and built a maintenance death spiral. But the party is over. Margins are being compressed, AI is turning software into a commodity with actual COGS again, and “cutting the R&D fat” is the new favorite pastime of private equity.

Before ZIRP, there was at least an attempt at scientific management: heavy project management, estimating frameworks, and cost-accounting machinery (IBM Rational, anyone?). It still failed to make software organizations legible; it mostly added bureaucracy.

As of 2026, our industry still lacks a standard control system.

The DuPont Alchemists

To understand how to fix this, look back to 1912. DuPont developed what became the DuPont Equation.

Before this, Return on Equity (ROE) was a single output metric: useful, but not diagnostic. DuPont decomposed ROE into factors that cancel algebraically but reveal what is actually driving performance.

By looking at Profit Margin (Efficiency), Asset Turnover (Productivity), and Financial Leverage (Equity Multiplier), a manager could see exactly where the engine was knocking. If ROE was down, was it because they were bad at selling, bad at using their factories, or just under-leveraged?

More importantly, it helped you determine the most basic truth of business: Are you actually doing better than just selling everything off, liquidating the furniture, and sticking the money in a boring S&P 500 index fund? If your ROE is lower than the market average, you’re just playing a very expensive game of “make-believe business.”

While you could use ROE out of the box, it misses key dynamics of software economics. Its diagnostic utility for a software division is limited.

Software is a Factory, Not a Lab (Sorry)

Before I show you the math for software, we need to clear the air.

Most people—including many engineers—think software’s value is found in some abstract concept of “innovation.” They think we are in a laboratory, mixing chemicals and hoping for a breakthrough. That’s nonsense.

Software is a produced good. It’s a weird, magical good with near-zero marginal cost of reproduction, but it’s a produced good nonetheless. Once you build the system, serving the 10,000th customer should cost almost nothing compared to the first. The unit economics are hard to beat. This is my read of Marc Andreessen’s seminal Why Software is Eating the World.

The catch: you only realize those margins if your engineering is actually good.

High-quality engineering is not about “clever” code; it is about systems that are cost-effective to operate, adaptable to new demands, and easy to expand without a rewrite every 18 months. If the architecture is brittle, you lose the software advantage and end up hiring people to compensate for what the code should do. Your “software company” will have the margins of a manual car wash because you’re hiring armies of SREs just to keep the lights on.

We are not chasing “innovation” for its own sake. We are chasing margin expansion and preservation. The goal of an R&D division is to widen the gap between revenue and the cost to the machine. Even more paramount, we must be widening the gap between revenue and the cost of expanding the machine. Software cannot afford to be static.

Software is not a permanent asset; it is a depreciating asset. In fact, it’s one of the fastest-rotting assets on the planet. The moment you ship code, the world starts conspiring against it.

• Competitors launch similar or better features (e.g. Apple’s “late-mover” advantage).
• Customer tastes change without warning or cause (e.g. viral trend cycles and generational dynamics).
• New players can move more freely without the burden of accumulated feature complexity and tech debt, granting them both velocity and margin incumbents will struggle to replicate.
• Platform paradigms evolve and force rebuilds (e.g. from desktop apps to web apps).
• Technological breakthroughs raise user expectations for what software must do (e.g. you can’t become a billionaire just shipping a “database with a CRUD UI” as was the case in the early 00’s).

If you stop moving, your software doesn’t just “stay the same”—it becomes a liability. To stay relevant, you have to continually add features and capabilities just to maintain parity with the market. This is the “Red Queen’s Race” from Alice in Wonderland:

“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.”
― Lewis Carroll

The Equation: Return on R&D

To measure the health of a software division, we look at the relationship between Free Cash Flow (FCF) and Operating Expenses (OpEx).

Like the DuPont model, the terms cancel out, leaving us with a clear picture of how much cash we are generating for every dollar of operating spend. It solves three specific problems:

1. The Allocation Crisis: it answers the question, “should the next million dollars go to Marketing or R&D?” If Return on R&D is falling, adding headcount without a plan is like pouring water into a bucket with a hole in the bottom.
2. The Fog of War: we can track a thousand engineering metrics (sprint velocity, story points, deployment frequency), but most are local signals. Remember The Goal? The Goal is to make money. This equation gives you the bottom line for the technical organization.
3. The VPE Stress Test: it makes R&D organizations comparable. You can evaluate whether engineering leadership is building a scalable engine or growing an inefficient cost center.

1. Operating Efficiency (The Overhead Trap)

This measures your Run the Engine (RTE) or Keeping the Lights On (KTLO) overhead. OpEx captures things like support, cloud bills, rent, and non-capitalized payroll. CapEx is the investment in the software asset itself. This ratio tells you how much operations overhead is being generated for each unit of software produced. If this number is high, your software is a thinly veiled shell around a bunch of humans–it requires a massive operational apparatus just to exist.

Examples:

• Out in the industry: legacy banks produce “new” features, but the sheer weight of “Asset Drag”—the human and server cost required to keep 40-year-old COBOL systems running on mainframes alive—means OpEx is massive relative to new software output.
• How this showed up in my own experience: I advise an early-stage startup, Swell. Its first incarnation was a teletherapy app for military members and their families. The product handled onboarding end-to-end—psychometric profiling, intake questionnaires, therapist matching, scheduling—and hosted the sessions themselves over video.
  
  Growth was respectable, but the operation was leaky and painfully manual. Users would no-show the first appointment and burn therapist capacity. Others dropped out mid-scheduling. If a therapist needed to reschedule, it triggered a torturous game of phone tag. And despite having “onboarding” in the app, the team still needed a human phone call to verify insurance, collect consent forms, and put a credit card on file for copays and no-shows. It got us to market faster, but it didn’t scale
  
  In practice, chasing funnel drop-offs, collecting billing details, untangling scheduling, and handling insurance snafus consumed 1.0–1.5 FTEs—in a company with only a couple of employees. That overhead ate scarce capital (fewer dollars for engineering) and drained the founder, who was also acting as de facto Chief Product Officer. Product development slowed, which meant the system never got the automation it needed to stop leaking in the first place. When Swell later pivoted upmarket to an “employee benefits” provider, the manual OpEx didn’t magically disappear—but the payoff per customer was much higher, so the same operational pain became temporarily tolerable.

2. Free Spend (The Innovation Ratio)

This captures how much of your R&D is discretionary. Software CapEx splits into Growth and Red Queen (maintenance/parity) spend. Some investments are pure revenue defense. Example: “Competitors added an AI assistant, so we need one to stay viable in RFPs.” That may not expand margins, but not doing it can accelerate depreciation and sales decline.

This also includes forced migrations (e.g., cloud deprecations or replacing a critical OSS dependency). For this equation, I treat these as CapEx not OpEx because if you freeze time the software could theoretically keep operating in perpetuity without that spend.

Ideally, most CapEx is Growth CapEx: dollars allocated to your differentiated product strategy that should drive outsized margins in the Product Investment Yield term.

Examples:

• Out in the industry: early rideshare wars between Uber and Lyft. When Uber made it easier to find your driver at a busy airport by introducing a “chat with driver” feature, then Lyft had to respond in kind–otherwise users would over time choose the lower friction experience leading to churn. This isn’t a growth feature–there is no moat or differentiation–it’s pure defense.
• How this showed up in my own experience: At Verve (now part of Rockwell), we built a kind of SIEM for industrial control systems—what the industry lumps together as “Operational Technology” (OT). The product had surprisingly strong product-market fit despite being almost offensively simple. At its core, it automatically inventoried industrial assets and produced reports: what devices you had, their patch status, and known vulnerabilities. For many industrial operators, this was a brand-new capability—and in the wake of Stuxnet, CISOs were suddenly demanding answers. Before long, regulations like NERC CIP weren’t just encouraging this kind of visibility; they were effectively mandating it.
  
  But even with pull from the market, we kept getting dragged into bad comparisons. We’d walk into RFPs and find ourselves benchmarked against generic SIEMs and IT patch-management tools, then lose on superficial reasoning (“How is this different from Splunk?”) or checkbox feature gaps (“Dragos has anomaly detection—why don’t you?”). The anomaly-detection demand was the most maddening. It sounds incredible in a slide deck, but anyone who has built one knows the dirty secret: there is no universal “find all the weird stuff” equation. These systems are typically noisy, they generate endless inactionable alerts, and they can become net-negative operationally—especially in environments where every false positive costs real time and real risk. They’re also expensive to build, tune, and maintain.
  
  Eventually we caved and shipped basic dashboards—not because they were strategically important, but because Sales needed a box to check. These things barely worked and weren’t meant to actually get used (much like the food in Swedish bars) but they had to be there or our sales would have flatlined.

3. Product Investment Yield (The Product-Market Fit Test)

For every dollar of growth spend, how much sales revenue did you generate? If this ratio is low, you are likely building the wrong things, mispricing them, or failing to sell them effectively. “Clever” engineering that does not solve a customer problem does not compound value. Everything you build must enhance the value proposition of your product either by capturing new users (increasing TAM) or by increasing revenues extracted from the existing users (increasing LTV and willingness to pay).

Examples:

• Out in the industry: specialized ERPs like Epic Systems in healthcare. They spend heavily on R&D to keep up with regulations and cover more of the healthcare lifecycle. Deep lock-in and regulatory capture have created strong pricing power which means each unit of Growth CapEx can return outsized revenue.
• How this showed up in my own experience: at Microsoft, I helped build Shielded Virtual Machines in Hyper-V: a capability that let a VM run on a host without the owner of the server—or any of the software on it—being able to see inside. The goal was to make the host untrusted by design. We leaned on then-new platform primitives like TPMs, cryptographic attestation, and a rigorously verified from-scratch microkernel (the “SMART kernel”) so a shielded VM would only boot on hardware that could prove it hadn’t been compromised and was running genuine, unmodified Microsoft firmware and code end-to-end.
  
  This was peak “rise of cloud” (circa 2015), when plenty of enterprises still insisted they could never move their most sensitive workloads off-prem. Even today you see variations of the same trust problem—companies refusing to run on infrastructure owned by a direct competitor (e.g. retailers refuse to use AWS). Microsoft’s thesis was straightforward: if we could make the host provably trustworthy (or at least provably measurable), we could pull security-conscious customers into Azure and also equip third-party hosting partners to do the same.
  
  It was a truly stunning effort: years of engineering, collaborations with hardware manufacturers, new industry protocols and standards, and a huge go-to-market motion with OEMs, hosting providers, tech reporters, and MSPs like Acenture…it was probably the most innovative thing I ever worked on. And yet, it totally failed from a market perspective. We didn’t sell more Windows Server licenses because of it, at least not relative to the huge CapEx cost. Today, when you Google for this feature, all that comes up is some crusty old TechNet documentation (that I helped write lolsob). I’m not sure any normal human ever used this thing.

4. Growth Efficiency (The Reinvestment Buffer)

This measures how much discretionary cash the business retains after operating and reinvestment demands. The efficiency with which sales convert into free cash depends on OpEx overhead and Red Queen CapEx. High-quality engineering should lift this ratio over time as marginal delivery cost per customer drops. Importantly, just improving sales income does not improve this ratio (the sales income is also part of the FCF calculation). The only way this ratio goes up is when leverage/margin go up.

Examples:

• Out in the industry: Atlassian (Jira/Confluence). Atlassian is a great illustration of the Reinvestment Buffer because they built a business where scale doesn’t require a proportional increase in humans. Their product-led, low-touch distribution and standardized cloud delivery mean a new customer is mostly incremental compute—not incremental headcount. When that machine is engineered well, revenue turns into discretionary cash at a high rate. Atlassian’s reported free cash flow margin (FCF/Sales) has reached the kind of territory—37% in FY24 Q4—that lets them fund R&D, acquisitions, and platform rebuilds without “turning off innovation” or begging capital markets for oxygen.
• How this showed up in my own experience: When I worked on Google Workspace, we shipped a brand-new video editor: Google Vids. This was the first new “editor app” we had launched since 2008—and it targeted the heaviest document type you can support: video. Now add the thing Workspace is famous for: real-time collaboration. And to make it even more ambitious, Vids was designed as an AI-first editor—helping users generate voiceovers, narrator avatars, and even transform boring decks into videos (still boring, just rendered at 30 FPS).
  
  On paper, this should have been a generationally expensive initiative. Worse, it wasn’t obvious there was easy TAM sitting on the table. Most remaining headroom was locked inside large enterprises that wanted to switch but couldn’t stomach retraining entire organizations. The bottleneck wasn’t “we lack a video editor.” In the naive model, the outcome is predictable: flat sales and a big dent in free cash flow.
  
  The reason it didn’t play out that way is that Workspace had a structural advantage: over many years we had invested in a robust editors platform—the shared substrate that makes it possible to run five or six different collaborative editors without reinventing the universe each time. That platform wasn’t narrowly optimized for docs and spreadsheets; it was built to accommodate very different workload shapes, from slides and vector drawings to richer media. Because that foundation already existed, building Vids was plausible—and more importantly, plausible without letting Growth CapEx explode. It still wasn’t “easy,” but the cost curve was governed by reuse rather than reinvention.
  
  That’s the punchline: platform investment is a growth-efficiency amplifier. It increases your reinvestment buffer by making large bets cheaper to place. Instead of spending like a startup every time you ship a new product surface, you get to compound prior CapEx into new revenue opportunities—in our case, higher LTV through premium capabilities, and potentially more seats as video becomes a default medium for business communication (Loom, anyone?).

Putting the Equation to Work:

When you run these numbers, the “shape” of the equation tells you exactly what kind of mess you’re in:

1. The Legacy Death Spiral: high Red Queen CapEx, low Operating Efficiency, and flat Sales. You are spending all your money just to keep a rotting asset alive.
2. The PMF Crisis: high Growth CapEx but low Product Investment Yield (ratio < 1.0). You are building things people do not buy. That is usually a product strategy or go-to-market problem, not a pure engineering problem (see Brian Balfour’s Four Fits Framework).
3. The Mechanical Turk: low Operating Efficiency (OpEx is huge relative to CapEx). Your software is buggy and unreliable. Every feature you add just makes things worse. You are hiring armies of SREs and support staff to do the work the code should be doing.
4. The Competitive Pressure Cooker: high Growth CapEx, but your Red Queen spend is climbing even faster. A hot market with many competitors is creating tons of pressure to expand; a venture capital proxy war is waging with you and your company on the frontlines. Zero to One talks about this (“competition is bad”) and Blitzscaling is a wonderful case study of the dynamics in such markets.

You can play with the variables in the following interactive sandbox to get a feel for how this works–

(or Open in a New Tab)

Edge Cases and Alternative Formulations

Grow First, Profit Later

This equation can be “punishing” for companies that aggressively reinvest for future growth (Amazon is the classic example). If you recycle nearly all FCF into Growth CapEx, Return on R&D can look weaker than a mature incumbent.

You have two options: “pro-forma” planned growth CapEx to estimate steady-state return, or take the reported hit. I prefer taking the hit. Until growth CapEx becomes sales, you do not know if the business is healthy. Some of that growth spend may actually be Red Queen work in disguise.

Complex Financials

There is a surprising amount of “opinion” encoded in figures like profit. That may be acceptable for board and analyst reporting, but it is weak for operating decisions in engineering.

Because software is intangible, capitalization and depreciation choices are often judgment calls. For a platform investment, you might value it using build hours, unlocked deal volume, or a fixed share of R&D salaries. Each method yields a very different number.

Another similar phenomenon: it’s become shockingly common to count inbound revenue (aka receivables) as part of revenue. This is really common with large material transactions (datacenter hardware) and, especially, enterprise software where Net 90 invoices are increasingly common. The problem is: This. Isn’t. Actual. Money. Not yet at least. Nvidia has been using this trick on their financial reports which inflates revenue figures and pumps more air into the AI Bubble which surely won’t implode and kill us all in the process. No siree.

No word on if any of these receivables ever turned into dollars. Oh well, I’m sure everything is fine.

Bottom line, if your business features a lot of delayed payment cycles or complex financial engineering, factor all that crap out. Maybe instead of pure free cash flow, you use (Net Income + Amortization + Depreciation – Maintenance CapEx).

No Visibility into Dollars and Cents

Even in established companies, getting real dollar visibility is hard. Public companies may restrict these numbers as material non-public information, so engineering leaders receive proxy metrics or redacted reports.

At Google, I managed a budget of >$60MM annually using a proxy metric called “SWE-hours.” How much did it cost to host Google Drive this month? xxxx SWE-hours. I knew more about the precise cost of our team t-shirts than I did the actual infrastructure. I’ll spare you further sarcasm–all deeper ironies aside it mostly worked and provided a stable operating signal.

If you can’t get the dollars, use Time. A reasonably accurate accounting of “Engineer-Weeks” spent on Growth vs. Maintenance, combined with a standard “fully-loaded cost per engineer,” will get you 80% of the way there. If you have 100 engineers and 60 are on “Growth” projects, use that 60% ratio. It’s not perfect, and capitalization inconsistencies will haunt you, but an “inaccurate” number that you track consistently is infinitely better than the giant pile of nothing we have today.

Normalizing for Comparison

Comparing this metric over time or across companies only gets you so far. “The number is higher, therefore I’m doing better” is incomplete.

Software is about leverage over time. If investment decisions are sound and the product is well engineered, margins should improve as recurring work is automated away.

So the deeper metric is the first and second derivative of Return on R&D (rate and acceleration of improvement). If margin growth is flat year over year, you may be sustaining performance but haven’t really increased the efficacy of the engineering organization. Maintaining growth is good–don’t get me wrong, it might even be the appropriate strategy for your company depending on where it is in the product maturity curve–but then you have to seriously ask yourself what value you’re generating as an individual manager.

Finally, I’ll note the the math on some of these terms can become confusing if you take them without additional context. For example, Product Investment Yield can go to infinity as Growth CapEx goes to zero (which would typically be considered a bad thing, especially if it’s because you ran out of money, not because you found a product that prints money without investment). You could…

• Make sure to counterbalance this with compensating metrics like the raw Growth CapEx dollars. I’m not advocating that you ONLY look at these metrics anyways…it’s all part of a healthy balanced breakfast WBR.
• Use “% of R&D Spend allocated to Growth” which makes the term vary only with the proportional allocation rather than absolute dollars invested. I do this in the simulator above.

Putting This Into Practice

Most engineering conversations fail because they’re held in two incompatible languages. Engineering talks in systems; finance talks in cash.

Return on R&D is a translation layer. It takes the messy reality of platforms, reliability, tech debt, and forced migrations—and expresses it as a set of ratios that explain why the cash machine is (or isn’t) working. It doesn’t replace technical judgment; it makes technical judgment allocatable.

Here’s the key takeaway: you don’t win by maximizing any single term. You win by preventing the two classic failure modes:

• Spending into a Product Investment Yield void (building things nobody pays for).
• Spending Growth CapEx on top of a decaying asset (where Red Queen and OpEx eat everything you add).

If you’re a VPE, this becomes your operating cadence:

• Monthly: reconcile Growth vs Red Queen vs RTE.
• Quarterly: pick one term to improve and one term to defend.
• Annually: evaluate whether margin is compounding (the derivatives), not whether the roadmap was “delivered.”

And if you’re a CFO, it tells you when engineering spend is investment versus liquidation: when the equation’s structure says the machine will widen margins—or when it says you’re feeding a black hole.

The goal isn’t to measure engineers. The goal is to measure whether the software factory is becoming more leveraged—and to make that trend visible before it becomes irreversible.