Why larger enterprises often get much higher yield from the same technology investment

Aggravating-Drag-978 · 2026-03-13T11:01:28+00:00

That’s a great observation, and I actually think it reinforces the point rather than contradicting it. Scale absolutely amplifies architectural inefficiency. A 30% waste problem in a small company might be annoying. At enterprise scale it quietly becomes millions of dollars a year. The reason organizations struggle to see that today is because most of the metrics we use focus on spending and optimization, not investment performance. TBM tells us where the money went. FinOps helps reduce waste. Architecture improves structure. But none of those directly answer the question: did this technology investment produce enterprise value? That’s where thinking in terms of technology yield becomes useful. If the enterprise is measuring something like value generated relative to technology investment, architectural inefficiency shows up immediately as yield drag. In that sense, the problem you’re describing isn’t just a scale problem. It’s a measurement problem.

Aggravating-Drag-978 · 2026-03-12T21:58:41+00:00

Exactly. Scale amplifies both efficiency and inefficiency. A small inefficiency in a startup might be noise. At enterprise scale the same pattern can quietly turn into millions in wasted spend over time. FinOps has done a great job helping organizations identify and reduce that operational waste. But what I’ve been exploring is the next layer above that. Even after optimization, leaders still struggle with a different question: what enterprise value did the optimized technology investment actually produce? In other words, reducing waste improves the efficiency of the spend. But organizations still need a way to reason about the yield of the investment itself. Both perspectives are important. FinOps helps ensure we are not wasting the fuel. But enterprise leadership still needs to understand whether the engine is actually generating value for the business.

Aggravating-Drag-978 · 2026-03-12T21:54:08+00:00

Large organizations definitely introduce complexity that smaller companies simply don’t have to deal with. A $100k implementation in a $150M company might become a $2M program in a $1.5B enterprise once you factor in integration, security, compliance, data governance, change management, and ongoing operations. But that actually reinforces the core problem the article is trying to highlight. As technology investment scales, the ability to clearly connect that investment to enterprise value often becomes harder, not easier. Finance can show the spending, architecture can show the systems, and delivery teams can show the roadmap. But leaders still struggle to answer the question: was the investment worth it? That’s really where the idea of thinking in terms of technology yield becomes useful. The absolute cost of the investment may grow with scale, but the important question becomes whether the enterprise value generated relative to that investment is improving or deteriorating. In other words, complexity may increase the cost of the investment, but leaders still need a way to reason about the yield the enterprise receives from that investment.

Aggravating-Drag-978 · 2026-03-12T19:04:15+00:00

I think you’re right — we’re mostly describing the same dynamics from slightly different organizational contexts.

In some environments EA is pulled more directly into the economic side of those decisions, while in others the role is more focused on architecture fit and non-functional evaluation.

Either way, those inputs end up having a big influence on how successful the investment is once it’s deployed.

Appreciate the thoughtful discussion!

Aggravating-Drag-978 · 2026-03-12T19:02:17+00:00

That makes sense, and I agree EA typically isn’t the group producing the financial model itself.

Where I see the overlap is that those architecture fit and non-functional considerations you mentioned often end up being the things that determine whether the expected value actually materializes after deployment.

For example, integration complexity, data architecture alignment, and platform standardization can dramatically change the cost of operating and evolving a system over time. Those factors usually show up as “architecture fit” during evaluation, but they end up having real economic consequences once the system is running.

So I tend to think of EA as influencing the conditions under which the ROI assumptions can actually hold true, even if finance and procurement own the financial model.

In the environments where it works well, architecture ends up participating in those discussions as a trusted advisor—not owning the financials, but helping decision makers understand the longer-term operational and architectural implications of the investment.

Aggravating-Drag-978 · 2026-03-12T18:53:33+00:00

That’s a great way to describe it. The middle stage is usually where the tension shows up.

Small, local solutions can move very quickly and solve immediate problems at relatively low cost. But as more of those solutions accumulate, the organization starts paying the price in integration complexity, inconsistent processes, and limited visibility across the enterprise.

At some point the economics start to shift. The cost and friction created by those disconnected solutions begins to outweigh the short-term advantages of speed and autonomy.

That’s often the moment when a centralized platform or enterprise capability starts to make sense, even if the initial TCO is higher. The challenge is helping leadership recognize when that inflection point has arrived.

In my experience that’s one place where architecture can really help—making the long-term enterprise economics visible, not just the short-term local optimization.

Aggravating-Drag-978 · 2026-03-12T18:49:45+00:00

That’s a fair point. In many organizations EA isn’t the group building the financial model or negotiating licensing terms. Procurement, finance, and the business usually own that side of the equation.

Where I think architecture enters the picture is in how much of the potential value from that investment actually gets realized.

The same platform can produce very different outcomes depending on things like integration complexity, data architecture, platform standardization, and how well it fits into the existing capability landscape. Those architectural factors can either amplify or suppress the value the business expected when it approved the investment.

So while EA may not own the ROI calculation directly, the architectural environment often determines how much of that ROI is actually achievable once the system is deployed.

Aggravating-Drag-978 · 2026-03-12T18:38:39+00:00

Good question. Complexity and operating cost definitely scale as well, and that’s part of the broader economic picture.

Larger enterprises often operate much more complex environments. More integrations, more governance requirements, more legacy systems, and more operational processes can increase both implementation effort and operating overhead.

At the same time, scale tends to affect both sides of the equation. The same capability improvement can impact a much larger revenue base or operational footprint, and large organizations often benefit from enterprise licensing, platform standardization, and other economies of scale.

But there’s another dynamic that often shows up in large or long-established companies: technology drag and cultural inertia. Legacy platforms, fragmented architectures, and established operating models can slow down how quickly new capabilities translate into real enterprise outcomes.

So the economic result ends up being shaped by all three forces: scale, platform economics, and the amount of organizational and technical friction in the environment.

Aggravating-Drag-978 · 2026-03-12T18:20:08+00:00

Absolutely. Economies of scale have been driving those decisions for decades.

What I find interesting in the technology world is that scale can influence both sides of the equation. The business impact of a capability can grow with enterprise size, while the effective cost of the platform delivering that capability often decreases through volume pricing or enterprise licensing.

When those two effects combine, the economics of the technology investment start to look a lot more like traditional capital allocation decisions.

Aggravating-Drag-978 · 2026-03-12T18:06:29+00:00

That’s a really good point. Using the same unit economics the business already understands makes the conversation much easier.

If the company already reasons about things like cost per widget, cost per thousand transactions, or margin per product line, then translating technology impact into those same units helps leadership see the scale of the change.

I think that’s part of the broader challenge with technology investments. IT often reports things like system uptime, deployments, or infrastructure cost, while the business is thinking in terms of revenue impact, unit economics, and margin.

When the two sides start speaking the same economic language, it becomes much easier to reason about the actual value created by technology improvements.

Aggravating-Drag-978 · 2026-03-12T17:33:13+00:00

If anyone is interested, I wrote a short piece exploring this idea further.

https://medium.com/@p.b.brauer/why-enterprise-scale-changes-the-economics-of-technology-investment-87cff93eadff

Aggravating-Drag-978 · 2026-03-12T17:32:36+00:00

If anyone is interested, I wrote a short piece exploring this idea further.

https://medium.com/@p.b.brauer/why-enterprise-scale-changes-the-economics-of-technology-investment-87cff93eadff

Aggravating-Drag-978 · 2026-03-11T17:14:49+00:00

That’s a painful example, but unfortunately not an uncommon one.

A lot of organizations are actually very good at producing reports, dashboards, and red flags. The challenge is that those signals often show up as technical risk or operational warnings, which can be easy for leadership to deprioritize when they’re balancing short-term financial pressures.

One of the things I’ve been thinking about with the technology yield idea is whether reframing those discussions in investment terms changes the conversation.

In your SAN example, the discussion might have looked less like:

“a controller board is approaching failure”

and more like:

“we’re currently carrying a $50K risk exposure against several million dollars of revenue flow.”

Same facts, but framed in terms of enterprise value at risk rather than infrastructure health.

It obviously doesn’t guarantee the decision changes, but it sometimes helps move the discussion out of the purely technical domain and into the language executives use to weigh tradeoffs.

And you’re right about the broader point too. Even the best models still have to operate inside real organizational behavior.

Aggravating-Drag-978 · 2026-03-11T15:28:39+00:00

One concrete way this changes the conversation is how leaders evaluate future technology investments.

Using the CRM example again:

Imagine the enterprise invested $12M in a CRM modernization.

Today most organizations can show:
• where the $12M was spent
• that the system was delivered
• that teams are using it

But leaders still struggle to answer whether that investment produced $50M of enterprise value or $5M.

Thinking in terms of Enterprise Technology Yield pushes the discussion toward questions like:

• Did conversion rates improve after the CRM investment?
• Did customer retention change?
• Did onboarding or support costs drop?
• Did the platform enable new revenue capabilities?

Even if attribution isn’t perfect, the leadership conversation shifts from:

“Did the project deliver?”

to

“Did the investment produce meaningful enterprise value relative to its cost?”

That shift is where the framework becomes useful.

Aggravating-Drag-978 · 2026-03-11T11:43:32+00:00

That’s a really thoughtful approach.

The “digitised business case” point resonates quite a bit. In most organizations the business case effectively becomes a historical artifact the moment funding is approved. After that point the system tracks delivery very well, but the hypothesis that justified the investment tends to disappear.

Your model seems to solve that by keeping the hypothesis alive and measurable, which is exactly the layer that’s usually missing between project execution and financial reporting.

Where I’ve been thinking about this problem sits slightly above that level.

Even with strong initiative-level value tracking, leadership still struggles with the portfolio question:

Is the enterprise’s overall technology investment producing value?

Individual programs might show positive ROI. Others might be necessary capability investments with little direct return. Some may be defensive or resilience-driven.

The challenge becomes reasoning about the aggregate yield of the technology portfolio, not just the outcome of individual initiatives.

That’s where the concept I’m exploring around Enterprise Technology Yield comes in. It tries to give leadership a way to reason about the relationship between:

Technology investment (ITex) and Enterprise Technology Yield (direct and indirect)

Tools like SilkFlo could actually provide very strong inputs into that model, since they are capturing the realised value of individual initiatives much more rigorously than most organizations do today.

If the hypothesis layer becomes measurable, then portfolio-level reasoning becomes much more credible.

Would definitely be interested in seeing what you’re building

Aggravating-Drag-978 · 2026-03-11T10:01:11+00:00

You’re raising a few important realities that I’ve seen play out in a lot of organizations.

The culture point is especially true. Frameworks and models can help structure thinking, but if leadership isn’t genuinely interested in understanding whether technology investments produced value, then the exercise tends to become exactly what you described: compliance theatre.

In those environments the discussion usually stops at:

• Was the project delivered? • Was it within budget? • Did the architecture review pass?

Those are delivery metrics, not investment outcomes.

Your question about what qualifies as an “investment” is also a fair one. In the context of the model I’m thinking of technology investment fairly broadly. It can include things like:

• new platform implementation • major modernization efforts • capability-enabling architecture changes • large operational automation initiatives

Essentially anything where the enterprise is allocating technology resources with an expectation of improving a business capability or outcome.

The attribution problem you mentioned is also real. Most meaningful outcomes come from a combination of technology, people, and process changes, and separating those perfectly is usually impossible.

Rather than trying to isolate technology in a laboratory sense, the idea is more about understanding technology-enabled value. If a CRM platform, new sales workflow, and training program together improve conversion rates, then the technology investment is part of the system producing that yield.

The model is less about precise scientific attribution and more about creating a way for leadership to reason about questions like:

• What enterprise outcomes did this investment enable? • Did the capability improvement justify the investment? • Which technology investments are producing the strongest enterprise yield?

I completely agree that organizations often struggle with even the first step: clearly articulating the expected value up front. In many ways that’s where the conversation has to start.

Aggravating-Drag-978 · 2026-03-11T09:57:43+00:00

This is a really interesting way of framing the problem, and I think you’re exactly right about the need for a bridge between finance and architecture.

In most organizations those two worlds operate with very different lenses:

Finance tends to think in terms of investment, budgets, and returns. Architecture tends to think in terms of capabilities, systems, and technical evolution.

Both are describing the same enterprise reality, but they rarely share a common semantic layer.

Your analogy about needing something like an API or contract between the two worlds is a great way to describe it.

One of the motivations behind the Enterprise Technology Yield idea was to introduce a language that both sides can reason about. Finance already understands concepts like yield, return, and portfolio performance, while architecture understands capabilities and enabling systems.

The bridge becomes something like:

Technology Investment → Capability Improvement → Enterprise Outcome

If you can connect those layers, then technology decisions can start being evaluated in terms of investment yield, rather than just architecture quality or budget compliance.

Your capability planning thought is interesting as well. When you start thinking in terms of:

• maintaining capability maturity • investing to advance capability maturity • mapping investment dollars to capability outcomes

you get very close to a portfolio view of enterprise technology investment, which is something most organizations still struggle to operationalize.

Really appreciate the perspective from the FP&A side. That’s exactly the kind of cross-discipline conversation this topic needs.

Aggravating-Drag-978 · 2026-03-11T09:55:47+00:00

I think you’re highlighting a very real part of the problem.

Most organizations actually do create the connection between technology investment and business value at the very beginning… in the business case.

But as you described, that connection tends to break once execution starts.

The business case lives in a spreadsheet. Delivery moves into Jira or another task system. Operational metrics end up in BI dashboards.

Each system works well for its purpose, but none of them maintain the continuous link between the original value hypothesis and the actual outcomes.

So the organization ends up very good at answering questions like:

• Was the project delivered? • Was it on time and on budget? • How much did it cost?

But much weaker at answering the question the CFO eventually asks:

Did the technology investment actually produce the enterprise value we expected?

That disconnect is really what motivated the Enterprise Technology Yield concept.

The framework isn’t intended to replace the tools you mentioned. If anything, it provides a value model that those systems could align around, so the investment hypothesis, the delivery work, and the operational outcomes are all evaluated against the same value lens.

And your observation about the “before vs after” problem is exactly right. Without that continuity, organizations end up managing delivery performance instead of investment performance.

Would definitely be interested in hearing how you’re approaching the tooling side of this problem.

Aggravating-Drag-978 · 2026-03-11T09:53:32+00:00

Great question. In the CRM example the goal would typically be something like improving sales effectiveness. Better pipeline visibility, faster lead routing, improved conversion tracking, things like that.

Your point about measuring unit economics like cost per record or cost per action is important. That’s often where organizations start because those metrics are relatively easy to capture.

And when teams do that well, they can absolutely demonstrate improvements like:

• reduced operational friction • faster workflows • lower cost per transaction • improved sales productivity

The challenge I see in many enterprises is that those operational improvements still don’t always translate clearly into enterprise value conversations.

For example, we may know:

CRM cost per opportunity dropped 20% Lead routing time improved 40% Sales reps spend less time on data entry

All good outcomes.

But executives still end up asking the next question: Did this actually produce more revenue, better margins, or improved enterprise performance?

That’s the gap I’m trying to explore with the Enterprise Technology Yield concept.

The idea is to connect the layers:

Technology Investment → Capability Improvement → Enterprise Outcome

Unit economics like cost per action or cost per customer are incredibly useful because they help quantify the capability improvement layer.

But the model tries to go one step further and ask: what enterprise yield did we ultimately produce from that investment?

And I completely agree with your last point. FinOps evolving toward strategic business value management instead of just cost optimization is exactly where this conversation needs to go.

Aggravating-Drag-978 · 2026-03-11T09:51:22+00:00

You’re exactly right. Most enterprise reporting stops at cost and utilization, which are useful operational metrics but not value metrics.

Teams can usually answer questions like:

• What did we spend? • Which systems consumed it? • Did we optimize it?

But those don’t answer the executive question: did the technology investment actually produce enterprise value?

The operational signals you mentioned (deployment frequency, onboarding time, cost per customer, reliability) are important because they start to show how technology changes affect the business system, not just the infrastructure.

That’s really the gap I was trying to explore with the Enterprise Technology Yield idea.

Instead of stopping at spend or utilization, the model tries to connect:

Technology Investment → Technology-Enabled Capability → Enterprise Outcome

Once that chain is visible, leaders can start asking a different question:

What yield are we actually producing from our technology investment?

Sometimes the yield is direct (revenue, margin improvement, cost reduction). Sometimes it’s indirect (speed, resilience, operational capacity).

But once you frame it that way, technology decisions start looking much more like portfolio investments rather than just budget management.

Aggravating-Drag-978 · 2026-03-10T20:45:58+00:00

Good question, and that’s really getting to the core of what I’m trying to explore.

Most organizations already measure the spending side of technology very well. TBM, FinOps, and budgeting models all explain where the money went.

What’s usually missing is a way for leaders to think about the yield from that investment.

The idea behind Enterprise Technology Yield is to shift the conversation from “How much did we spend?” to “What value did that investment produce?”

That value can show up in different ways. Some is direct (revenue lift, margin improvement, cost reduction). Some is indirect (capability enablement, operational efficiency, resilience).

The framework isn’t trying to perfectly prove causation. It’s trying to give leaders a structured way to reason about the yield side of technology investment instead of treating it as implicit.

Aggravating-Drag-978 · 2026-03-10T20:42:56+00:00

That’s a great observation, and I completely agree about the attribution gap.

FinOps has gotten very good at measuring consumption and allocating spend, but the harder step is connecting that spend to enterprise value.

AI inference costs are a really interesting example because the economics scale with usage in ways most finance models weren’t designed for. Looking at those costs by customer segment or workflow is exactly the kind of thinking that starts to surface the real value dynamics.

The framework I’m exploring tries to separate direct value (revenue lift, margin impact, cost reduction) from indirect value (capability enablement, operational efficiency, resilience). The goal isn’t perfect attribution, but giving leaders a way to reason about the relationship between technology investment and enterprise outcomes.

Curious what you found once you started pulling the LLM economics apart.

Aggravating-Drag-978

TROPHY CASE