What I Misunderstood About Scale

By 2004, Nike's digital commerce platform was live. We had built it from nothing — the company's first consumer commerce application — and it worked. Orders came in. Revenue climbed. The natural next question was: how do we scale this?

I thought I knew the answer. Scale meant more servers, more SKUs, more markets, more features. Scale was a technology problem. You architect the system correctly, you add capacity, and the thing grows. I was a designer-turned-builder who had just shipped something real, and I confused building with scaling. They are not the same discipline.

The First Misconception: Scale Is Additive

My mental model was addition. More pages. More product categories. More payment methods. More locales. If the platform handled the US, then adding Europe was a matter of localization and logistics integration. If we could sell footwear, adding apparel was a matter of catalog expansion.

What I did not understand was that scale is multiplicative. Every new market multiplied the complexity of every existing system. Localization was not translation — it was legal, tax, fulfillment, customer service, returns policy, and cultural expectation, all at once. Adding apparel was not adding a category — it was renegotiating the relationship between merchandising, supply chain, photography, and the digital shelf.

I kept proposing solutions that were technically correct and organizationally naive.

The Second Misconception: The System Is the Platform

I thought the system I was scaling was the technology platform. The codebase. The infrastructure. The design system. These were the things I could see, measure, and control.

The actual system was Nike. The corporation. The org chart. The incentive structures. The regional general managers who saw digital as a threat to their wholesale relationships. The merchandising teams who controlled product imagery and were not staffed to produce assets at the velocity digital demanded. The finance team that had no model for attributing revenue to a channel that influenced purchases but did not always close them.

The platform could handle ten times the traffic. The organization could not handle the change that ten times the traffic implied. I was scaling the wrong system.

The Third Misconception: Alignment Is a Precondition

In the previous article, I wrote about alignment as a bottleneck. But there was a subtler error underneath that observation. I believed alignment was something you achieved before you scaled. Get everyone on the same page, then go.

At Nike, alignment was never a stable state. It was a negotiation that had to be re-won at every phase of growth. The people who agreed to the first version of the platform did not agree to what the platform implied at version three. Their agreement was to a contained experiment. My ambition was an enterprise transformation. Those are different commitments, and I did not have the organizational awareness to see that the yes I received at the beginning was not the yes I needed at the end.

This is the thing nobody tells you about building inside a large organization: permission is not transferable across scale. The approval to build a small thing does not automatically extend to the large thing the small thing becomes.

What Scale Actually Required

Looking back from 2026, having now scaled teams to 600 people, operations across four countries, and a P&L to $220 million, I can name what I did not understand at Nike:

Scale requires giving things away. At Nike, I wanted to control the experience end-to-end. That instinct — the designer's instinct — is exactly wrong at scale. Scale requires you to define standards and then trust other people to execute within them. You cannot personally ensure quality across every surface. You build the system that ensures quality, and then you let the system work. This was the hardest lesson. It took me another decade to actually learn it.

Scale requires saying no more than saying yes. Every feature we added was a surface we had to maintain, support, and evolve. I was additive when I should have been subtractive. The most scalable version of anything is the one with the fewest moving parts that still delivers the outcome. I did not have the discipline to subtract. I wanted to build everything.

Scale changes who you need to convince. At version one, I needed my engineering team and my direct manager. At version three, I needed the VP of North America Retail, the CFO's planning team, and the head of global merchandising. The stakeholder map did not grow linearly — it grew exponentially with the scope of what we were building. And I did not invest in those relationships early enough because I did not see them as part of the work. I saw them as obstacles to the work.

That last point is the one that cost me the most time. I treated organizational complexity as friction when it was actually the terrain. You do not complain about gravity. You design for it.

The Lesson That Carried Forward

Years later, when I was building a 500-person capability center at Conn's or negotiating manufacturing partnerships in Vietnam, I recognized the pattern immediately. The technology was never the constraint. The organizational capacity to absorb change — that was always the constraint.

The Sanskrit concept of krama — right sequence, right order — applies here. The Bhagavad Gita speaks of yogah karmasu kaushalam: excellence in action is yoga. But the word kaushalam does not mean speed or ambition. It means skill — which includes the skill of knowing what comes next, what the system can absorb, and when to pause.

At Nike, I had ambition without krama. I wanted to jump from step three to step ten because I could see step ten clearly. What I could not see was that steps four through nine were organizational, not technical. They required patience, relationship-building, and repeated re-alignment — work that did not feel like building but was, in fact, the most important building I could have done.

I did not learn this lesson at Nike. I learned it much later, at significant cost. But Nike is where the lesson was first offered to me, and I was too young and too eager to receive it.

Next: The Moment I Stopped Thinking Like a Designer — the final entry in Season 1.

Satya Sivunigunta is a technology executive, founder, and investor based in Phoenix, AZ. This article is part of an ongoing operating journal — retrospective reflections written in 2026 on operating roles from 2000 onward. Read more at satya.me.