MusewoodsJournal

The Bottleneck Moves
Journal form
Fieldnote

Observed by Surendra Reddy

Fieldnote

The Bottleneck Moves

What becomes scarce when building software is no longer the hard part?

I have been watching Vishal Sikka's journey for a long time. Our paths crossed intellectually years ago when he supported some of my research at Xerox PARC around the Big Data Foundry, work that eventually contributed to the thinking behind the Sensemaker and now Governed Data Foundry. We have taken different routes through enterprise technology, but I have often recognized a familiar instinct in how he approaches change: do not merely apply a new technology to an existing operating model; ask whether the new technology has invalidated some of the assumptions on which that model was built.

That is partly why I built the recent case around his journey through SAP and HANA, Infosys, Vianai, and now Hang Ten Systems. I was not trying to write a retrospective on whether Vishal succeeded or failed at each stop. I wanted to place the chapters beside one another and see what moved between them—what he seemed to preserve, what changed, what disappeared, and which problems became visible only after another problem had been solved.

What I noticed is making me think differently about our own Subzero→451° machinery.

OBSERVED

HANA, Infosys, Vianai, and Hang Ten look like four very different episodes. One is a database and computing platform inside SAP. One is an attempt to transform the economics and culture of a huge services company. One is an enterprise AI platform company. The newest is an AI-native enterprise services company using an internal platform to let very small teams deliver software that historically required much larger ones.

But when I stop looking at the companies and follow the question underneath them, the journey looks more continuous.

The recurring inquiry seems to be something like this: when the economics of computation change, which parts of the enterprise operating model should change with them?

That question is much more durable than any one product.

This feels important for venture formation because we tend to preserve companies and lose questions. We remember products, rounds, valuations, acquisitions, customers, and exits, while much of the intellectual residue gets scattered across decks, people, code, and memory. Yet the residue may be the most valuable part of the journey.

Perhaps the company is not always the durable object. Sometimes the question is.

SOMETHING ELSE I NOTICED

The role of the platform changes across Vishal's journey.

HANA became a major platform inside an organization that already possessed customers, distribution, and institutional power. At Infosys, Mana and later Nia sat inside a services organization whose economic machinery had been built around people and projects. Vianai moved the platform much closer to the center of the commercial proposition, but distribution remained a challenge. Hang Ten has made an interesting inversion: Hobie, its internal AI framework, is not what the customer is being asked to buy.

The customer buys the outcome.

The machinery stays underneath.

That immediately makes me uncomfortable in a useful way because we face the same temptation at 451. When we build something difficult—ADAM, the Governed Data Foundry, Clearstory, or another piece of machinery—the technical depth itself begins pulling us toward productization. We start asking how to explain the platform before asking whether the customer ever needed to understand the platform in the first place.

I do not yet know how broadly this principle travels. Some platforms clearly must become products because the platform itself is the source of customer value, distribution, or lock-in. But Hang Ten gives me a useful counterexample to our natural builder's instinct that everything technically important must eventually become something independently sold.

This one deserves to stay cold for a while.

THE TEMPERATURE OF THE JOURNEY

The other reason this case keeps pulling me back is that it can be read through Subzero→451°.

Subzero exists because an idea is remarkably easy to over-form. We observe something, name it, assign a category, imagine the product, identify a buyer, calculate a market, compare it with existing companies, and begin explaining it to other people. Every step increases legibility, but every step also narrows the possibility.

At −4, the job is different. We preserve what caught our attention without requiring it to become a company. We expose it to other observations, contradictions, technical reality, customer reality, and our own attempts to disprove the first interpretation. As evidence accumulates, the temperature can rise; 451° is not where an idea begins but a threshold that conviction must earn.

Looking at Vishal's journey this way produces a question I had not considered when I started building the case. What if an entrepreneurial career is partly a process of carrying unresolved ideas through repeated heating and cooling cycles?

Vianai does not have to be interpreted simply as a venture that did or did not achieve a breakout. Perhaps some of what was being learned there cooled, shed assumptions, and reappeared inside Hang Ten in a different configuration: platform inside rather than platform outside, outcome before abstraction, direct enterprise work rather than asking the market first to understand a broad platform thesis.

I cannot know from the outside that this is how Vishal himself interprets the sequence. But as an instrument for our own venture creation, the question is useful.

This gives me a more useful interpretation of 451 Labs. It should not exist primarily to accelerate ideas. Acceleration assumes that we already know the direction. The harder problem is deciding when an idea has earned enough conviction that insufficient commitment becomes a greater risk than premature commitment.

That is a much more demanding threshold.

THEN THE BOTTLENECK MOVED

The observation in the Hang Ten case that interests me most may actually sit downstream from Hang Ten itself.

Traditional enterprise technology services have been organized around the cost of building and changing software. Projects required engineers; larger projects generally required larger teams. Offshoring reduced the unit cost of human labor, but it did not fundamentally break the relationship between work and headcount.

Hang Ten is testing whether AI-native engineering can break that relationship more substantially. Its model uses small pods for work that historically required far larger teams, with Hobie providing reusable internal machinery. The case also contains an important boundary: customers or independent third parties still conduct the final quality checks and certification.

That boundary caught my attention.

Building accelerates.

Assurance does not necessarily accelerate with it.

The bottleneck moves.

I want to make this an explicit Subzero practice.

Whenever we encounter an important technological compression, we should walk downstream. Do not ask only whether the breakthrough is real. Assume for a moment that it succeeds completely and inspect the new world it creates.

What becomes scarce because something else became abundant?

THE ASSURANCE SEEDCORN

Following that question leads quickly toward assurance, but this is exactly where I do not want us to jump immediately into venture formation.

“AI assurance company” is already an answer.

The colder question is: what becomes scarce when machine-built systems become abundant?

Perhaps certification becomes scarce. Perhaps the real scarcity is trustworthy evidence. Perhaps specification becomes more important than implementation. Perhaps the bottleneck is institutional authority—someone must still have the standing to decide that a system is safe enough, correct enough, compliant enough, or governed enough to enter consequential operation.

Those are different problems.

This is where the thread connects back to my own journey from the Big Data Foundry toward the Governed Data Foundry. As the technical substrate changed, the problem moved from assembling and processing large information environments toward provenance, semantics, authority, governance, and the conditions under which increasingly intelligent systems could be trusted.

Agentic systems push that trajectory further. We are no longer governing only data and models. We increasingly have to govern actions, delegated authority, decisions, evidence, exceptions, and consequences.

The Hang Ten case is making me wonder whether assurance for this world can remain primarily a downstream activity.

HUNCH

My hunch is that assurance eventually has to move closer to creation.

Our inherited sequence is straightforward: build the system, test it, gather documentation, send it through review, remediate what fails, and eventually authorize it. That sequence works tolerably when building itself moves at human speed.

It becomes less obvious when machines can create and modify consequential systems continuously.

Perhaps the more interesting architecture is not faster certification but evidence by construction. Requirements, model actions, generated artifacts, data lineage, delegated authority, tests, exceptions, policy checks, and approvals could accumulate as part of the operating history of the system. An independent authority would still make the judgment, but it would not need to reconstruct the entire past in order to do so.

The builder should not certify itself.

But the builder may need to make independent certification dramatically easier.

This is where RPM Decisioning belongs in the venture-creation platform for me. Subzero protects the possibility from premature formation, but preservation alone cannot tell us when to act. The decisioning discipline forces us to distinguish an interesting thesis from an authorized next move, to read operating reality before intervention, challenge the thesis, and make an explicit decision rather than allowing enthusiasm or momentum to decide for us. That separation is central to the RPM operating grammar.

Subzero and RPM therefore solve different problems. One protects an immature possibility from premature certainty. The other protects consequential action from an insufficiently challenged thesis.

451° comes later.

A DIFFERENT WAY TO REMEMBER VENTURES

There is another Seedcorn here that may have nothing to do with assurance.

What if our venture-creation platform remembered ventures differently?

Most portfolios remember the company: what was invested, what was built, how revenue developed, who owned what, whether more capital was raised, and what happened at exit. When a venture stops, much of the deeper inquiry disappears with it.

I want ours to remember the unresolved questions.

This may be where Musewoods fits more deeply into the 451 venture-creation machinery than I had initially imagined. Musewoods is not merely where finished thinking gets published. It can preserve the observations, contradictions, partial insights, abandoned directions, connections, and questions that companies themselves are poorly designed to remember.

The Journal records what we notice. Seedcorns can preserve what is not yet ready to become a thesis. Subzero keeps selected possibilities from being forced prematurely into form. The 451 crucible exposes emerging conviction to operating reality. RPM Decisioning helps determine what consequential step, if any, the evidence now warrants.

Seen together, this begins to look less like a venture pipeline and more like a learning ecology.

SEEDCORNS

I can already see several things on the forest floor from building this case.

Constraint migration. Whenever a technology removes a major bottleneck, deliberately search downstream for the next uncompressed activity.

Platform invisibility. Some strategically important technology may produce more value as internal machinery than as the object being sold.

Evidence by construction. Machine-speed creation may require assurance evidence to originate during creation rather than being reconstructed afterward.

Venture memory. Questions, falsified assumptions, and useful capabilities should survive the company that first exposed them.

And perhaps the most interesting one: the durable unit of venture creation may sometimes be the question rather than the startup.

I do not want to turn any of these into venture theses yet. Their value right now is that they make me look differently at things already around us. If one of them keeps returning, begins connecting with independent observations, survives contradiction, and acquires evidence from operating reality, we can let its temperature rise.

That is enough for now.

WHAT I WANT TO KEEP WATCHING

I will keep watching Hang Ten, but not simply to see whether it becomes a large company or whether it disrupts the traditional IT-services firms. I want to watch what its success makes difficult next. If software construction becomes dramatically faster, the interesting signal may appear in the queue that forms somewhere else.

I also want to keep watching Vishal's journey at the level of the questions rather than only the companies. There is something instructive in seeing an entrepreneurial inquiry carried across different institutional settings, technologies, business models, and capital structures. It reminds me that what appears to be a new venture can sometimes be the latest expression of a question that has been evolving for years.

That may be the practical lesson for our own venture-creation platform. We should become better not only at forming companies, but at preserving questions, regulating the temperature of conviction, challenging decisions before consequence hardens, and harvesting what each experiment leaves behind. If we do that well, the next venture may not arrive as a brilliant new idea at all; it may appear quietly as a Seedcorn that an earlier journey taught us how to see.