Lessons from ✈️ design in maximizing EBITDA lift from enterprise tech

Deadweight loss, value leakage and adoption loss are the killers

I think I know how the investment bankers who started using VisiCalc in the early 1980s must have felt. Imagine you had learned to construct cash-flow analysis on graph paper, reconstructing them by hand every time you needed to change an assumption -- and then one day you could model 20 different scenarios. Not in minutes -- the Apple II had an MOS technology 8-bit 6502 microprocessor that ran at 1MHz -- but probably in less than an hour.

I could not have written this issue without Cursor (or another similar tool). I’ve pondered enterprise technology economics for decades. Now I can engage interactively with a software program (a LLM is a piece of software!) to convert those musings into a series of equations -- and then quantify and graph scenarios based on them. Even the ability to instruct “codify this logic and save it to an .md file” provides a big step up compared to copying and pasting from chat windows. Not magic, but empowering nonetheless.

The main argument: Increasing EBITDA lift from technology

---

The takeaway

• What you need to know: You can model the relationship between technology investment, organizational friction, implied hurdle rates and EBITDA lift -- engineering deadweight loss is the killer!

• What you need to do: Find ways to reduce engineering deadweight loss, value leakage, adoption loss and the run tax

• What you need to decide: What your aspiration to increase EBITDA lift is and what type of economic transparency you need to justify required investments

---

Questions are interesting. If anyone responds to your questions by accusing you of admiring the problem, you can tell him or her that I said asking questions helps understand a problem. And understanding a problem is kinda, sorta important in solving it. Curiosity is a superpower.

Why did the US Air Force perform so well in the Korean War?

Colonel John Boyd asked an interesting question about air combat in the Korean War: why did the US Air Force post a 10:1 kill ratio, given that the MiG-15 Fagot had a higher ceiling and better climb rate than the F-86 Sabre? In seeking to answer this question, Boyd studied combat reports, interviewed pilots and analyzed aircraft specifications. He concluded that American planes’ bubble canopies and hydraulic controls allowed American pilots to see and react to their North Korean, Soviet and Chinese adversaries more quickly. Faster reactions won dogfights. [1]

Stealing computer time from the Air Force, Boyd developed energy-maneuverability (E-M) theory.

E-M theory describes aircraft performance in a number: Specific Excess Power (Ps), or the rate at which an aircraft can climb at a given speed and altitude. Positive Ps means power to spare: you can climb, accelerate, or sustain a hard turn. [2]

An F-15 Eagle flying at 20,000 feet and Mach 0.9 might have a Ps of +400 feet per second. It can climb 400 feet every second while holding its speed, or sustain a tight turn without losing altitude. A MiG-23 at the same point might have Ps of only +150. The F-15 pilot can pull into a climb the MiG can’t follow, or turn hard until the MiG bleeds energy and falls behind.

E-M theory revolutionized aircraft design for decades, encouraging designs with “more wing” that prioritized turning performance over top speed. [3]

Why does the tech backlog exist?

I have been looking at enterprise technology investment portfolios since the era in which people tried to figure out whether they wanted to implement Kana, Cold Fusion and E.piphany. [4] One question has driven me up a wall for decades: why does the tech backlog exist?

I endured two years in West Philadelphia, before they opened Jon M. Huntsman Hall. I learned about the principles of capitalism in Vance Hall, a building that looked like it should have housed the Magnitogorsk Bureau of Tractor production. [5] My finance professors taught me that companies thrive by investing in NPV positive projects, and should keep investing until the return no longer exceeds the cost of capital.

So why do companies frequently have a long list of technology projects, with sponsors touting attractive business cases, that they decline to fund because of insufficient budgetary capacity? Why don’t they just expand the technology budget to fund all NPV-positive business cases? Because the inherent uncertainty of enterprise technology returns causes companies to use (implicitly or explicitly) high hurdle rates for technology investments, causing them to spurn attractive opportunities!

1. They don’t believe the business case

As I wrote in Why enterprise technology is so bloody difficult, enterprise tech business cases are a 0 to 1 problem, rather than a 1 to n problem like investing in a new retail branch, grocery store or distribution center. You are building something new that requires behavioral change to capture value.

Enterprise business case rigor has improved over the years -- they often now include multi-year run costs, instead of just the initial investment. But predicting, for example, how better sales pipeline transparency will improve close rates is tough. So is estimating the time and cost to implement a major new system with acceptable performance, scalability, resiliency and security. And that’s without getting into any analysis of complexity cost or option value -- to what extent does any given extension of the environment make future investments more expensive (by creating more nodes any new system must integrate with) or more capable (by creating reusable platforms).

If CFOs worry about optimism in enterprise tech business cases, they will demand a margin of safety and only fund IT budgets to support business cases with very high ROIs and short payback periods.

2. Companies face funding constraints

When my finance professors said companies pursue positive-NPV projects, they made a critical assumption -- that liquid capital markets would provide funding to companies with attractive investment opportunities. Putting aside exceptional periods (cough, fall 2008, cough) [6]

This assumption appears valid. In 2024, S&P 500 companies returned 80 percent of earnings to shareholders. This is not new -- large companies have engaged in similar behavior since the turn of the millennium At the same time debt markets remain open. Goldman Sachs projects American companies will issue USD 1.5 trillion in corporate grade debt; investment grade issues will require only a 79 bps spread compared to Treasuries. Capital markets aren’t preventing companies from investing in technology or any other type of project management teams believe in.

3. Enterprise technology organizations face operational constraints

Even in the face of attractive investment opportunities, companies may face operational constraints. Back in the old days, you might forswear buying additional computing capacity if it meant you would outgrow your data center. The capital required to build a new facility might swamp the benefits of a few exciting projects. Cloud platforms may have diminished this constraint, but not ones related to software engineering and support. Especially prior to the last few years, I’ve heard many CIOs and CTOs lament that they couldn’t find high quality software engineering talent even when they had the headcount approval. And even when they could hire people, most enterprise environments have had a brutal learning curve, with new engineers needing a year to become productive.

The evidence on talent as a constraint is mixed. Layoffs in the tech sector have created an overhang in tech talent, and you frequently see engineers with “#opentowork” tags on LinkedIn, but it still takes months to fill open tech roles even after the end of the zero interest rates regime.

4. Management teams use high costs of capital

A project is only NPV positive if the return clears the cost of capital, so high cost of capital? Fewer positive-NPV projects. But what cost of capital should management use in making technology investment decisions? Apparently a high one!

According to an article in the Journal of Financial Economics, companies report an average hurdle rate of 15 percent, against a weighted average cost of capital (WACC) of 8 percent. Why the delta?

Skepticism about business cases is obviously a factor here. You can imagine a savvy CFO declining to litigate sloppy assumptions in every business case line-by-line and instead requiring a high hurdle rate to counter-balance optimistic projections.

Agency effects may also matter. From a shareholder’s perspective there is no beta in a risky technology project. All the risk is incidental, and none correlated with the market as a whole. All investors care about is the expected value of a project. They can diversify away the risk of a failed CRM program. Who can’t diversify away the risk of a failed technology project? Executives. A few underperforming programs will damage their careers, even if they come out in the wash for investors. As some of my colleagues wrote years ago, too high a discount rate can make good projects seem unattractive.

I couldn’t find any evidence that companies apply a higher discount rate to technology projects than other projects. In my decades of observing and debating technology investments across dozens of companies, payback period has been a much more common metric than hurdle rate. But requiring a 2 year payback period (not uncommon) implies a very high hurdle rate indeed.

Reduce friction to maximize EBITDA lift

What should a company spend on enterprise technology? Enough so that marginal EBITDA lift (net of incremental run costs) matches the hurdle rate for capital. More importantly how do you maximize the EBITDA lift from technology?

Modeling the relationship between business-driven investment, organizational friction, marginal ROI and run efficiency provides guidance on how to get the most impact from enterprise technology

• Hurdle rate assumptions have low leverage because they enable investments in low-but-positive ROI projects

• Nothing has more impact than reducing software engineering deadweight loss by installing an AI-enabled operating model that spans skills, practices and tooling

• Reducing value leakage via better product management and adoption loss by improving organizational change management is also important

• Cutting run costs (as opposed to improving unit cost efficiency) doesn’t expand EBITDA lift unless you face a hard budget cap

The Jevons paradox matters more than agency constraints.

• Reducing deadweight loss pushes the green furthest to the right, increasing EBITDA lift to USD 176MM and pulling USD 219MM in business driven investment into enterprise technology, which increases the overall budget to USD 1,059MM

• Reducing the hurdle rate to 8 percent increases the enterprise tech budget to USD 1,074 -- but only increases EBITDA lift to USD 115MM

E-M theory for enterprise tech

Everybody knows that tech spend includes run costs, mandatory investments, tech-for-tech investments and business driven investments. Two new thoughts to keep in mind:

• You face a pipeline of business-technology investment opportunities that you can sequence in terms of attractiveness, with the highest ROI opportunity first; each subsequent opportunity has a little bit lower ROI than the previous one

• The ROI you get is a theoretical limit degraded for engineering deadweight loss, value leakage (from sub-optimal requirements) and incomplete adoption (from insufficient organizational change management

• You can calculate your ROI curve (net of incremental run costs) to determine where it crosses your hurdle rate

Here are the equations:

And the definition of each variable

• Run_Costs: application maintenance, application hosting, network and cybersecurity, (driven by the aggregate stock of “legacy” and “non-legacy” story points) and end user (driven by the number of seats).

• Mandatory_Inv: non-discretionary investments like upgrading end-of-life software and fulfilling compliance requirements; driven by stock of “legacy” and “non-legacy” story points

• T4T_Investment: discretionary investments in improving software engineers, remediating technical debt and automating run activities that reduce Deadwgt_Loss and Run_Costs per story point and per seat

• Optimal_gross_business_investment: Funds invested in discretionary, value-creating business-enabling projects in a given year

• Ideal_Initial_ROI: The annual return your best project would deliver with ideal requirements, no engineering deadweight loss, and complete adoption — the theoretical maximum.

• Value_Leak: Fraction of value lost to poor requirements and product management — building the wrong functionality

• Deadwgt_Loss: Fraction of engineering effort that doesn’t produce working code — rework, defects, administrative overhead.

• Adopt_Loss: Fraction of delivered value not captured because users don’t use the software or use it poorly.

• Initial_ROI: The observed annual return on the best project, after accounting for frictions. If Ideal_Initial_ROI is 6.0 (600%) but frictions consume 67%, then Initial_ROI is 2.0 (200%).

• Run_Tax: The fraction of each dollar of gross business investment by which technology run costs will increase in subsequent years (e.g., 0.15 = 15%)

• Hurdle_Rate: The required rate of return that investments must exceed to create economic value (e.g., 0.15 = 15%)

• Half_Life: The investment level at which ROI drops to half of your best project. Reflects the depth of your opportunity set — how many genuinely good projects exist before quality drops off. Small companies might have a half-life of $20M; large companies might have $80M or more.

The table and graph above start with the following assumptions. Your mileage will vary.

As I noted two weeks ago, all models are wrong; some are useful, so I used some simplifying assumptions:

• This model treats each investment atomically -- each creates value on its own; one investment does not depend on another

• It assumes costs are variable (less unrealistic in the cloud era than it would have been previously)

• It does not have a complexity tax. Each new system implies run costs, but a larger and more complicated environment does not make implementing the next unit of functionality more expensive

• It assumes that cybersecurity costs (including in Run_Costs) compensate for any new investments to keep the company at its risk tolerance

• It assumes that the company is at the right service level in terms of system stability, end user environment, network stability, etc.

• It assumes that the organization has captured all productivity improvements it can without additional investment

What do you do about it -- T4T investment to reduce friction and flatten the ROI curve

The arithmetic is clear: CIOs and CTOs must find ways to reduce engineering deadweight loss, value leakage, adoption loss and the run tax.

How? Adopting AI-enabled software engineering. Improving product management. Improving organizational change management. Re-factoring legacy code.

They also may be able to change (and flatten) the shape of their ROI curve. Expanding the set of attractive opportunities by creating semantic layers and building scalable platforms.

All of these things require investment. Two weeks ago I argued that investing in the enterprise technology machine can have disproportionate impact on EBITDA lift. In the next couple of weeks, I’ll try to bring all this together to demonstrate how you can make tech-to-tech investments to maximize enterprise technology value.

The Wire Section

The Tragedy of the Agentic Commons, Rohit Krishnan and Amex Imas
Technology changes markets. High-yield debt and leveraged buyouts never would have happened at the scale they did without the electronic spreadsheet. The market for air travel would look very different with yield management systems. Grid computing contributed to deeper markets for exotic derivatives. [7] How will agents transform the balance of power between guys and sellers. I don’t know, but some people are starting to ask the question.

Claude Code Can Be Your Second Brain, Noah Brier, AI&I
Yes, I admit when I heard about Brier’s Obsidian setup, I immediately thought “I’m not worthy. I’m not worthy!” Lots of important points here:

• AI is a better reader than a writer (I would say it’s an excellent reader and a horrific writer!)

• More context in markdown makes for a better thought partner

• I need to start using voice mode when I’m driving

• And he reminded me of the OSS’s Simple Sabotage Field Manual -- I need to write a piece that getting rid of the people who act like they’re using will transform tech productivity!

Securing agentic AI: A playbook, Rich Isenberg and Charlie Lewis, McKinsey & Company
Some of might have hoped for a Hartford Whalers versus Buffalo Bills debate when Rich and Charlie got on a podcast together. Instead: the new fragilities of agentic AI, the role of human supervision, agent identities and the eternal importance of basic cyber hygiene. Disappointing? Perhaps, but important nonetheless!

Footnotes

[1] Coram, Robert, John Boyd: The Fighter Pilot Who Changed the Art of War. Yes, Boyd is a polarizing figure. Yes, many accuse Coram of hagiography. But if you think seriously about strategy, you have read this book.

[2] When an aircraft turns, it banks — tilting the wings so lift pulls it around the corner. But banking means some of that lift is now pulling sideways instead of holding you up. The tighter the turn, the more lift you need just to stay level.

If you don’t have enough power (low Ps):

• Maintain the turn → lose altitude (you’re trading height for the turn)

• Maintain altitude → widen the turn (you can’t pull as hard)

High Ps means you can do both — turn hard AND stay level. In a dogfight, that’s decisive: your opponent either loosens their turn (you get on their tail) or sinks below you (you end up with altitude advantage). Either way, you win.

[3] Only in recent years have designers begun to look beyond E-M theory, seeking to employ stealth, sensors, and beyond-visual-range missiles to win air battles without dogfighting. Not without controversy -- we’ll leave this debate to those who understand the physics and tactics much better than I do.

[4] Kana made email response management software — helping companies handle floods of customer emails at scale. Stock soared during the dot-com boom, crashed after, and the company limped through mergers until Verint acquired what was left in 2014.

ColdFusion was a rapid web development platform from Allaire — wildly popular in the late 90s for building dynamic websites quickly. Allaire merged with Macromedia (2001), which Adobe acquired (2005). Maybe I shouldn’t include ColdFusion in this list. You can still buy an enterprise license for USD 2,390 per year. https://adobe.com/products/coldfusion-family.html Kudos to Adobe! Rumors about whether each license includes a complimentary Gilmore Girls DVD boxed set. (For our younger readers, before Netflix...Oh never mind.)

E.piphany sold customer analytics and marketing automation — the buzzwords of 1999. Stock went from $30 at IPO to over $300, then cratered to under $3 post-crash. SSA Global acquired it in 2005

[5] Stephen Kotkin is a national treasure. His book “Magnetic Mountain: Stalinism as a Civilization” applies Michel Foucault’s theories to the massive industrial center the Soviets built in the 1930s in illustrating how Stalinism worked as a social system, not just a political regime. Yes, the Soviets hired consultants to help them design Magnitogorsk.

[6] If you’re at a cocktail party and a former sociology or comparative lit major suggests that the price discovery and liquidity capital markets provide don’t have social value, you can remind that person quite how scary the world looked in 2008 when they stopped doing that for a little bit.

[7] Allen Weinberg and I wrote a paper on this in 2004 as well, but it appears lost in the mists of the internet.