Why the Hardest Systems Win by Becoming Hard to Plan

Aviral Vaid

Hatched by Aviral Vaid

Jul 14, 2026

10 min read

86%

0

The Strange Advantage of Complexity

What do semiconductor geopolitics and project management have in common? More than it first appears, and the common thread is uncomfortable: the systems that matter most are often the ones you cannot control with a single plan.

That sounds like a weakness. In practice, it is a source of power. The semiconductor world has spent decades turning into a layered ecosystem of design tools, fabrication, materials, optics, metrology, chemicals, and tacit know how, spread across countries and companies. Meanwhile, teams inside firms keep discovering the same lesson in a different form: the more ambitious the work, the less useful it is to pretend that a perfect upfront plan will carry you through.

Both stories point to the same deeper tension. Modern success depends on coordinating large systems that are too complex to fully design in advance, yet too important to leave to improvisation. That is true whether you are building chips or building software, whether you are managing a supply chain or managing a portfolio of projects.

The challenge is not choosing between rigidity and chaos. The real challenge is learning how to create structured adaptability. The best systems do not eliminate uncertainty. They distribute it, absorb it, and convert it into learning.


The Real Bottleneck Is Not Money, It Is Learning

A familiar reflex in strategy is to assume that if a problem is important enough, money can solve it. But some problems are not capital problems first. They are capability problems.

A chip fab is expensive, yes. But building one is not like buying a machine from a catalog and switching it on. It requires a deep stack of competencies: process knowledge, equipment integration, materials science, precision optics, yield improvement, supplier coordination, and iterative tuning. Even if a government or firm has the budget, it cannot purchase the missing experience instantly. It has to move down a learning curve.

That is why a complex industrial ecosystem is so hard to copy. It is not just a set of assets. It is a web of dependencies, each one containing decades of embedded learning. A single lithography tool depends on upstream suppliers, specialized components, and a network of technical standards that only make sense when the whole stack exists. You are not re-creating one company. You are re-creating a civilization of complementary expertise.

This is where a useful mental model emerges: in high-complexity systems, capital buys attempts, not mastery. Money can fund experiments, subsidize failures, and accelerate iteration. It cannot bypass the fact that some knowledge only appears after repeated contact with reality.

The same is true inside organizations. A team can spend months planning a product roadmap, but certain risks, bottlenecks, and user behaviors will only become legible once the work is in motion. More planning can improve direction, but it cannot eliminate the unknowns that only implementation reveals.

In complex systems, the main asset is not certainty. It is the ability to learn faster than your environment changes.

That is why fixed plans are seductive but incomplete. They create the feeling of control without always creating control itself.


Why Integration Beats Optimization Until It Doesn’t

One of the most interesting lessons from industrial history is the power of integration. When design and manufacturing sit under one roof, the manufacturing side can shape the design side. The product is built to fit the production system, not the other way around. That can be a major advantage because it reduces coordination friction and forces tight feedback between what is imagined and what is physically possible.

This matters because in complex domains, the boundary between idea and execution is never clean. A chip design is not just an abstract architecture. It is also a bet on what the fab can reliably produce. Likewise, a roadmap is not just a statement of intent. It is a sequence of commitments that must survive contact with delivery constraints, team capacity, and shifting market signals.

But integration comes with a hidden cost. When one layer becomes dominant, it can trap the others into its logic. Over time, the system becomes optimized for the current structure, not necessarily for future changes. Modular systems, by contrast, can innovate in separate layers. They are more flexible, but they require coordination across interfaces. They can also hide dependencies until a shock exposes them.

This creates a larger strategic pattern:

  1. Integration is powerful when the environment is stable enough to exploit it.
  2. Modularity is powerful when the environment is changing fast enough that no single design center should dictate everything.
  3. Both become fragile when treated as permanent ideals rather than situational tools.

That is the deeper connection between semiconductor supply chains and portfolio planning. In both cases, the question is not whether to centralize or decentralize, plan or adapt, integrate or modularize. The question is: where should the system be tightly coupled, and where should it stay loose enough to learn?

A software analogy makes this concrete. Imagine building a platform where every component is tightly woven together, like a monolith. This can be efficient early on because coordination is cheap and decisions propagate quickly. But once scale and complexity increase, the same tight coupling can make change painful. Modular architecture creates independence, but only if the interfaces are well designed. Otherwise, the modules become isolated silos.

The same logic applies to organizational design. Too much integration can freeze evolution. Too much modularity can create disconnected efforts with no strategic coherence. The art lies in choosing the right grain of coupling for each layer of the system.


Agile Is Not Anti Planning, It Is Anti Fantasy

This brings us to a misconception about agile thinking. Agile is often mistaken for a rejection of planning, as though the answer to uncertainty is to stop thinking ahead. That is not the real insight. The real insight is that some decisions should be made only after enough learning has occurred to make them meaningful.

Upstream thinking still matters. Defining the problem matters. Root cause analysis matters. A long term roadmap matters. But the roadmap should not pretend to know every answer. It should distinguish between the near term, where commitments can be real, and the long term, where direction matters more than precision.

This is a crucial distinction. In many organizations, roadmaps are treated as if they were fixed promises. Then the inevitable discoveries of implementation make the plan look like a failure, when in reality the plan was simply overconfident. The problem is not that teams lack discipline. The problem is that they often confuse forecasting with orchestration.

Forecasting says: here is what I think will happen. Orchestration says: here is how we will create the capacity to respond as conditions change.

That is why a more mature planning system does not replace agile methods with bureaucracy. It adds a layer of strategic visibility above them. Think of it as a stack:

  • Problem definition: What are we really trying to solve?
  • Strategic intent: Why does this matter to the business or mission?
  • Near term execution: What can we commit to with confidence?
  • Long term direction: What themes and outcomes should guide future choices?
  • Feedback loops: What metrics will tell us whether we are learning or drifting?

In that framework, Gantt charts are not the enemy. They are simply one way to represent dependencies and timing. Jira is not the whole truth. It is one operational view. OKRs are not a substitute for judgment. They are a way to connect action to outcomes.

The deeper lesson is that good planning is layered planning. Some layers should be concrete, others deliberately fuzzy. Some should be optimized for delivery, others for learning.

The goal is not to predict the future perfectly. The goal is to build a system that improves its own guesses.


The Hidden Economics of Learning Curves

The phrase “move down the learning curve” sounds technical, but it is really a theory of how power accumulates. The first unit of a thing is always expensive. The tenth is cheaper. The hundredth is better. The thousandth reveals patterns no spreadsheet could have predicted.

That is why disruption is so hard to stop once it begins. Incumbents are usually rewarded for efficiency, not self sabotage. Their incentives point toward using existing advantages, improving margins, and reducing risk. But the thing that creates a new system often looks wasteful at first. It spends money on experimentation, failure, and partial builds. It accepts low yields in exchange for future competence.

This is true in manufacturing and in software. It is true in startups and in large enterprises. New capabilities rarely appear fully formed. They are assembled through repeated cycles of trial, integration, and correction.

A useful way to think about this is the difference between asset accumulation and capability accumulation.

  • Asset accumulation is visible. It shows up in headcount, equipment, budgets, and tooling.
  • Capability accumulation is slower. It shows up in cycle time, judgment, reliability, error reduction, and the ability to respond under stress.

Organizations often overestimate the first and underestimate the second. Yet when shocks hit, capability matters more than raw size. A smaller team with a tighter learning loop can outperform a larger one that is trapped inside an elaborate but brittle plan.

This is why the most important investment is often not the most expensive one. It is the one that shortens the feedback loop between action and truth.


A Practical Framework: Design the System for Reversibility

If there is one practical principle that connects these domains, it is this: build reversibility into the places where uncertainty is highest.

In semiconductor strategy, reversibility means recognizing which layers can be changed locally and which are locked into global dependencies. You do not want to discover, too late, that your strategy assumes access to technologies, materials, or suppliers that you do not control. In project management, reversibility means preserving the ability to adjust scope, sequence, and method without collapsing the entire program.

Here is a simple test you can use on any initiative:

  1. What assumptions are irreversible? If wrong, what does it cost to correct them?

  2. Where is learning still cheap? What can be prototyped, tested, or simulated before large commitments?

  3. What must be standardized, and what must remain adaptable? Not every part of the system should obey the same level of control.

  4. Where is coordination the bottleneck? Sometimes the issue is not lack of effort. It is misaligned interfaces.

  5. What metrics show whether we are learning, not just moving? Output alone is not enough. Look for reduced uncertainty, faster resolution, and higher quality decisions over time.

This framework works because it respects the central fact of complex systems: you cannot eliminate uncertainty, but you can decide where it lives.

A team with a strong upstream problem definition, a short feedback loop, a visible roadmap, and a clear line of sight to strategic outcomes is much harder to derail than a team that either improvises everything or plans everything.


Key Takeaways

  • Treat planning as a learning system, not a prediction machine. The point is to reduce uncertainty, not to pretend it does not exist.
  • Separate irreversible commitments from reversible ones. Put more rigor around the former, more experimentation around the latter.
  • Use layered planning. Keep strategic direction, short term execution, and operational tracking distinct, but connected.
  • Measure capability, not only output. Track how quickly your team learns, adapts, and improves under real conditions.
  • Design for the right kind of coupling. Some parts of a system need tight integration, while others need modular flexibility.

The Best Systems Do Not Hide Complexity, They Harness It

The tempting fantasy in both business and technology is that the best system is the one that removes complexity. But the world rarely cooperates. The deepest competitive advantages often come from managing complexity better than others do.

That is why chips, supply chains, and project portfolios are more alike than they seem. Each is a battle over coordination under uncertainty. Each rewards organizations that can align layers of work without freezing them. Each punishes those who mistake plans for reality.

The most resilient systems are not the ones with the cleanest charts or the loudest confidence. They are the ones built to learn under pressure. They know that some truths only emerge in the factory, in the sprint, in the prototype, in the yield curve, in the retrospective, in the messy space where abstraction meets constraint.

So the right question is not, “How do we make complexity go away?”

It is this: How do we create systems that become wiser every time complexity pushes back?

Sources

← Back to Library

Hatch New Ideas with Glasp AI 🐣

Glasp AI allows you to hatch new ideas based on your curated content. Let's curate and create with Glasp AI :)

Start Hatching 🐣