The Next Layer of Cloud

A few weeks ago, I was on a call with a partner seller in a European territory reviewing the results of a campaign we'd run across two ISVs and multiple regions.

We'd sent him 30 leads. Three were actionable. Not three that converted. Three that could actually be worked.

Most of the others didn't have sales coverage at both ISVs. Some were SMB accounts, while the joint sales motion we'd built assumed enterprise coverage. There wasn't a clear path for what to do with them.

Could we figure one out? Probably.

We could create a new SMB sales motion. We could try to bring in another partner with the right coverage. Maybe there was another path through the broader ecosystem.

Except we didn't necessarily have permission to share the lead data with another company.

So first we'd have to figure out the PII issue. Then potentially a co-marketing agreement. Then lead ownership. Then routing. Then seller coverage. Then incentives. Then who actually calls the customer.

All solvable problems. It just takes time. Months, potentially.

Realistically, nothing is going to happen with most of those leads. The obvious lesson here is pretty boring: build a better target account list next time. And we will.

Thirty leads entered one multi-company GTM motion. Only three were immediately actionable after encountering constraints in sales coverage, customer fit, data permissions, and lead routing. Demand existed; the operating path did not. Illustration by Megan Arnold, created with AI assistance using ChatGPT.

But the campaign took somewhere between six and eight months to launch. During that time, two of the three companies crossed fiscal years.

If you've worked in a large technology company, you know what that can mean. Territories change. Account assignments change. Priorities change. Sales models change. People move.

A target account list isn't a fixed representation of the market. It's a snapshot of multiple organizations at a particular moment in time. By the time we launched the campaign, the ecosystem it had been designed for had already changed underneath it.

A campaign can remain fixed while the ecosystem around it changes. Over an eight-month campaign cycle, companies may cross fiscal years, change territories or sales coverage, release new product features, or delay product availability—altering the operating environment before launch. Illustration by Megan Arnold, created with AI assistance using ChatGPT.

I used to think these were partnership problems

I've spent a lot of my career working in cloud partnerships, first from the ISV side and now from inside a hyperscaler. For years, the prescription for making partnerships work has been some combination of the same things:

Alignment. Executive sponsorship. Relationships. Communication. Influence. Clear accountability. All good things. I'm just increasingly convinced they're insufficient. Because eventually you run into a problem that no amount of "alignment" actually solves.

• The customer gave one company their information. Can that company legally give it to another company?

• One company calls an account one thing. Another calls it something else. Are they actually the same account?

• Company A has a seller assigned to the customer. Company B doesn't. Can they still co-sell?

• Three companies agree on the customer outcome but have three different sales incentives for getting there. Who moves first?

You can put very collaborative people in a room and still have all of these problems. Because these aren't really relationship problems. They're infrastructure problems. And, importantly, the idea of orchestration isn't new.

In 2006, management scholars Charles Dhanaraj and Arvind Parkhe used the term to think about how hub firms coordinate networks of autonomous companies when they don't have hierarchical authority over everyone else. Their work was about innovation networks, not cloud GTM. But the fundamental organizational problem is strikingly familiar: how do you coordinate a network of companies when nobody can simply tell everyone else what to do?

More recent platform research treats ecosystem orchestration as a major part of how platforms create and capture value. A systematic review by Joost Rietveld and Melissa Schilling looked across 333 academic papers on platform competition published between 1985 and 2019 and identified ecosystem orchestration as one of the major themes in the literature.

So I'm not proposing a new theory of ecosystems here.

I'm interested in something much more specific:

What happens when all of this has to go to market?

Because I think we're still remarkably good at building ecosystems and remarkably bad at operating across them.

Cloud doesn't really feel like an ecosystem

"Ecosystem" makes me think of a forest. Lots of independent organisms distributed across a landscape, all interacting in complicated ways. That's not really how enterprise cloud feels to me. It feels more like a handful of enormous objects with gravitational fields.

In Q2 2026, three companies accounted for about 63% of worldwide cloud infrastructure services revenue. Synergy Research Group estimates that the market reached $143.4 billion that quarter, with AWS at 28%, Microsoft at 20% and Google at 15%. In public IaaS and PaaS specifically, the concentration was even higher.

Those aren't three companies sitting alongside thousands of other companies on a flat playing field. They're centers of gravity.

Around them are ISVs, GSIs, distributors, resellers, developers, data companies, services companies and customers. Many of those companies orbit multiple hyperscalers simultaneously.

And if you've ever worked inside an ISV, the gravity is not subtle.

• ISVs want access.

• They want attachment.

• They want favor.

• They want visibility within the hyperscaler and its broader ecosystem.

They want hyperscaler sellers to know who they are. They want to show up in account conversations. They want to become the obvious answer for a particular customer problem. They want marketplace transactions. They want executive attention. They want to be included.

They want just a little more of that enormous engine pointed in their direction.

A tiny change in how much of that engine flows toward an ISV can be enormously valuable to the ISV.

Which is why I think managing cloud partnerships with a direct GTM playbook misses a lot of the point.

The leverage isn't always where the revenue lands

The questions in a direct business are pretty obvious.

• How much pipeline did we generate?

• How much revenue did this campaign produce?

• How many opportunities did this event create?

We need those questions, but they can also make us stare directly at the transaction while missing the system around it.

Imagine an ISV gets hundreds more hyperscaler sellers to understand exactly where its product fits, or it becomes part of a repeatable customer architecture, or buying through the marketplace becomes dramatically easier, or it gets attached to another ISV whose product makes its own product substantially more useful, or one important field organization starts treating it as the default solution to a particular customer problem rather than something a seller has to go discover.

Where does the value of that intervention show up? Eventually, hopefully, in revenue.

But the leverage may have happened several steps—and several organizations—away from the place the revenue was finally recorded.

That's why I keep coming back to a different question:

Where are the points of leverage in the system that change how value flows through it?

And that's also what made me start thinking about the original promise of cloud differently.

Cloud already abstracted one enormous layer of complexity

The basic cloud proposition feels so normal now that it's easy to forget what changed. The canonical NIST definition of cloud computing describes on-demand access to shared computing resources that can be rapidly provisioned and released with minimal management effort or provider interaction.

Cloud did not eliminate infrastructure complexity (obviously): what it did was change how much of that complexity every customer had to manage directly. More of the underlying infrastructure became something you could consume. And then we built an astonishing amount of stuff on top of it: applications, APIs, data platforms, services, marketplaces, integrations, entire categories of software.

Which created more possible combinations of those things, and then more. And more.

The kaleidoscope keeps turning

This is where the cloud ecosystem stops looking like a solar system to me and starts looking like a kaleidoscope.

Same pieces.

Turn it.

• A hyperscaler launches a new capability.

• An ISV integrates with it.

• Another ISV solves the problem next to it.

• A marketplace incentive changes.

• A regulation changes.

• A customer standardizes on a different architecture.

• Turn it again.

Same companies. Different configuration. Different opportunity.

And now AI is in the middle of all of this.

I don't actually want to make the lazy argument that "AI means there will be more software companies." Maybe there will be. Maybe AI ultimately causes enormous consolidation. I don't think we know yet.

What seems much safer to say is that AI is accelerating change across an already enormous cloud market. Synergy estimates cloud infrastructure services grew 43% year over year in Q2 2026, with GenAI-specific cloud services growing substantially faster.

The kaleidoscope is turning quickly. Meanwhile, it can take me six to eight months to get a complicated GTM motion into market.

That mismatch bothers me.

Bottlenecks don't politely stay where they were

This is where the research changed how I was thinking about the problem:

Harvard strategy scholar Carliss Baldwin has spent decades studying the architecture of complex technical systems. Her work on bottlenecks looks at how firms can create value by solving important technical constraints—and capture value by controlling strategically important ones.

She is not writing about partner marketing (unfortunately for her, of course). But the idea made me wonder whether we're looking at a version of the same phenomenon one layer above the technology. Cloud solved—or at least dramatically reduced—an enormous set of infrastructure constraints. That made it possible to create far more on top of the infrastructure.

Now the value of all those capabilities increasingly depends on assembly.

And assembly isn't only technical - it’s commercial, it’s organizational, it’s contractual, it’s human.

We've become extraordinarily good at making technical components interoperable while routinely stitching the companies behind those components together with spreadsheets, meetings, contracts, Teams messages, email chains and a handful of humans who happen to know whom to call.

And then we act surprised when it takes eight months.

What if the constraint is moving?

This is where the research ends and my argument starts: I don't know that ecosystem orchestration is "the next bottleneck in cloud." I don't think anybody has established that. But I keep coming back to the possibility.

Cloud made computing infrastructure dramatically easier to consume. That helped create enormous ecosystems of independent technologies and companies capable of producing combinations of value no single company could create alone. But every additional dependency creates another question of assembly, another boundary, another interface. Another place where the technology can work perfectly and the companies behind it still can't figure out what happens next.

Which makes me wonder whether a meaningful constraint is moving upward.

From:

How do I get access to the computing capability I need?

to:

How do I make this ecosystem of capabilities actually work together for me?

Cloud abstracted much of the complexity of provisioning infrastructure. As cloud ecosystems expand, the next constraint may be moving upward—from infrastructure toward the orchestration of software, partners, and the ecosystem itself. Illustration by Megan Arnold, created with AI assistance using ChatGPT.

If that's right, ecosystem orchestration isn't just a more sophisticated way to manage partners. It starts to look like an abstraction problem.

Cloud abstracted infrastructure complexity so every customer didn't have to solve the same infrastructure problems independently.

• Could someone do something similar for ecosystem complexity?

• Could account identity become easier to reconcile across companies?

• Could seller coverage be mapped automatically?

• Could commercial permissions travel with the motion?

• Could different CRM stages be translated instead of standardized?

Could the seams between companies become actual interfaces instead of places where work disappears?

And if someone can make the ecosystem dramatically easier to assemble, buy, sell and operate, there's another question hiding behind that one:

Who gets to own that layer?

The hyperscalers are obvious candidates. They already sit at the intersection of infrastructure, marketplaces, billing, technical standards, sellers, customers and enormous partner networks. But they're not the only candidates. GSIs, distributors and other intermediaries occupy different positions in the network. Some have an advantage the hyperscalers inherently don't: they can operate across multiple gravitational systems.

The thing I can't get out of my head isn't really cloud architecture: it's those 27 leads. There was demand, there were products capable of solving customer problems, there were companies that wanted to work together. Nobody screwed up, no one refused to collaborate (well, some did, such is the nature of the beast), nobody did a bad job. Every individual problem was solvable.

It just takes time.

And by the time you've built the operating model required to capture the opportunity, the ecosystem may have moved again.

Cloud became enormously valuable by reducing the time and effort required to access computing infrastructure.

I wonder if we're watching the same problem emerge one layer higher.

The next challenge may be making the ecosystem cloud created as operable as the infrastructure underneath it.

Cloud created an abstraction layer for infrastructure complexity. Ecosystem complexity—relationships among companies, systems, data, incentives, permissions, and operating models—still lacks an equivalent abstraction layer. Illustration by Megan Arnold, created with AI assistance using ChatGPT.

Sources & further reading

Dhanaraj, C. & Parkhe, A. (2006).Orchestrating Innovation Networks. Academy of Management Review, 31(3), 659–669.
https://journals.aom.org/doi/10.5465/amr.2006.21318923

Rietveld, J. & Schilling, M. A. (2021).Platform Competition: A Systematic and Interdisciplinary Review of the Literature. Journal of Management, 47(6), 1528–1563.
https://journals.sagepub.com/doi/full/10.1177/0149206320969791?

Baldwin, C. Y.Design Rules, Volume 2: How Technology Shapes Organizations. MIT Press.
https://direct.mit.edu/books/oa-monograph/5887/Design-Rules-Volume-2How-Technology-Shapes?

National Institute of Standards and Technology. (2011).The NIST Definition of Cloud Computing (SP 800-145).
https://www.nist.gov/publications/nist-definition-cloud-computing?

Synergy Research Group. (2026).Q2 Cloud Market Passes $143 Billion; Highest Growth Rate in Eight Years.
https://www.srgresearch.com/articles/q2-cloud-market-passes-143-billion-highest-growth-rate-in-eight-years?