The Black Hole of Engineering Spend
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).
