The Working Specification
From the Moon landing to NVIDIA: Absorbing Ambiguity to Drive Breakthroughs.
When President Kennedy set the goal of putting Americans on the moon, he settled many conflicting debates about America’s role in space and how to compete with the Russians. He defined a clear challenge — land a man on the moon before the end of the decade.
At the Jet Propulsion Laboratory, engineers were struggling to design the Surveyor probe—a robotic scout that would test-land on the lunar surface so future manned landers could follow. But the scientific community was divided over what the moon’s surface was really like. Some believed it was covered in deep, powdery dust; others thought it was a chaotic jumble of boulders or jagged, scorched spikes. The paradox was that engineers couldn’t design a probe to measure the surface until they knew what kind of surface they were landing on.
In 1964, I worked at JPL for Phyllis Buwalda, the director of Future Mission Studies. The scientific ambiguity about the moon’s surface annoyed her. Her memorandum on the lunar surface described it as hard and grainy, with moderate slopes, scattered small stones, and occasional boulders. In effect, she specified that the moon would resemble the Southwestern desert.
This was not a statement of truth. No one knew the truth. Her memorandum was a working specification. When I questioned her—pointing out that we had no real knowledge of the lunar surface—she replied simply: “The engineers can’t work without a specification. If it turns out to be much more difficult than this, we won’t be spending much time on the moon anyway.”
Phyllis’s working specification was a deliberate resolution of ambiguity into an actionable description. It was the bridge from “we don’t know” to “we are building.” Her specification passed on to the engineers a simpler problem—not one that was easy, but one that was solvable. With that assumption in place, design work could begin.
It took time and effort, but two years later, JPL’s Surveyor 1 landed in the Moon’s Ocean of Storms. It revealed a surface closely resembling Phyllis’ specification.
Some leaders and managers have found a different way to get “unstuck.” Instead of trying to understand every detail of these complex challenges, they make two key decisions that help them move forward.
Step 1. Identify a critical challenge. The leader identifies a critical difficulty that is currently blocking progress. This is often a creative choice rather than a deduction. This choice moves the conversation from a general desire to “be better” to a specific labeling of what is standing in the way. Analysis can inform this judgment, but in the end, it is an act of courage. In a jungle of tangled issues, opportunities, and challenges, a leader says, “This is the issue we must address to move forward.” Don’t let anyone fool you—-there is no surefire way to make such choices and always be right. But, deferring until things are clear is almost always wrong. The hoped-for clarity is revealed by the the successes of your competitors.
Step 2. Create a working specification.
Defining the critical challenge still leaves enormous ambiguity about what actually to do. The second step is to create a working specification—a simplified representation of reality that is good enough to organize action. This is a deliberate choice to specify a pattern of work that the organization is well equipped to handle. It is not a claim of absolute truth, but a functional reality that provides the direction necessary for productive effort.
A great Working Specification is never an idealized blueprint; it is an exercise in resource constraint. It requires a cold-eyed audit of what your organization is actually optimized to do. The architecture of a good specification relies on three parameters:
Tractability Over Ambition: The specification must translate an important challenge or opportunity into an everyday task that utilizes existing organizational literacy. It does not ask the rank-and-file to invent a completely new capability or shift their skills overnight. Instead, it forces the problem back into a framework that the team already knows how to execute, stabilize, and scale. It intentionally trades a fraction of grand ambition for immediate, coordinated tractability.
Hard Boundaries vs. Broad Metrics: Rather than issuing a vague performance target or a high-level metric—which leaves the team debating how to achieve it—a good Working Specification introduces a hard, binary constraint. This narrowing of the field of play forces the organization’s technical or operational capability to focus purely on execution and engineering, rather than on philosophical interpretation.
The Ambiguity-Absorption Index: A specification must absorb the exact type of uncertainty that frontline execution units are least equipped to handle. The leader stands at the boundary, takes the hit of the unmapped environment, and passes downward a simplified, bounded problem matched to specific competence of the team.
Unfortunately, too many leaders do not do this. Why doesn’t this kind of powerful simplification happen more often?
I have seen this hesitancy to sharply define the key job to be done all too frequently in my own consulting practice. Leaders who should be creating a working specification instead rely on the rhetoric of ambition and the indirect tools of goal-setting and performance reviews. In doing so they are unconsciousness following the precepts of a particular management doctrine.
Over the past fifty years, two ideas have come together to shape what is now the dominant, yet limited, approach to management. The first is Peter Drucker’s concept of “management by objectives,” which involves guiding actions through negotiated performance targets instead of strict instructions. The second is “transformational leadership,” the belief that leaders should inspire and energize people through a compelling vision, rather than by dictating tasks. Together, these ideas have shifted the role of top management to one of setting direction and motivating, leaving the actual work to emerge organically and often unpredictably.
Most entrepreneurs are resistant to this drug. They usually have an intimate familiarity with the work-processes of their companies.
While Phyllis Buwalda was resolving the physics of a landing, the same logic applies to resolving the evolution of a technology or market. OpenAI and the race for artificial intelligence provide just such an example.
In 2015, deep learning was accelerating rapidly. The founders of OpenAI wanted to bet on deep learning and also work on preventing AI from becoming an existential risk. The creation of that company was a classic Step 1.
Research on deep learning continued until Google published the 2017 paper introducing the Transformer architecture. At first, most people thought the Transformer was just a clever way to translate languages. But at OpenAI, researcher Alec Radford had a different idea. He started tinkering with the Transformer, stripping it down to a simple, almost playful challenge: could a computer learn to guess the next word in a sentence, all by itself? When the first results rolled in, Ilya Sutskever, OpenAI’s Chief Scientist and one of the company’s founders, realized they might be onto something big.
Sutskever’s Step 2 was to cut through the noise. Instead of wasting time in endless debates about the mysteries of human thought, he told his team to focus on something they could build and measure. He pulled the lab away from scattered theory and pointed everyone in a single direction: forget everything else and see how far the Transformer and next-word prediction could take them—especially if they threw massive computing power and data at the problem.
Many experts thought this was a dead end. In 2018, most believed that relying on something as simple as next-word prediction was a neat party trick—not sufficient to build real intelligence. Critics insisted that true AI had to be built on complex logic and sprawling knowledge databases.
But Sutskever didn’t get bogged down in these arguments. He was comfortable with not having all the answers. Instead, he took a leap of faith—what if intelligence could emerge from a system trained to guess the next word, over and over, on a truly grand scale?
Suddenly, the impossible seemed practical. OpenAI’s team was no longer trying to recreate the human mind but to make steady progress on a doable task. By swapping out philosophical soul-searching for a clear, measurable task, OpenAI gave thousands of researchers something concrete to work toward—and, almost by accident, discovered new ways for machines to reason.
[To get a deeper sense of this fascinating story, watch Ilya Sutskever’s “The Exciting, Perilous Journey Toward AGI” on YouTube]
Sutskever was enforcing a Working Specification at OpenAI. At NVIDIA, CEO Huang did so twice.
Jensen Huang has applied the two-step leadership move twice at the same company, fifteen years apart. Each time, the situation was different. The logic was identical.
The first occasion came in 1996, after NVIDIA’s first two products had failed. The company had bet on proprietary graphics architecture and a multimedia convergence strategy — and lost. Thirty-five competitors were vying for the PC graphics market. Intel had just entered the market. A startup called 3Dfx was dominating with its Voodoo chip.
Huang’s Step 1 was to identify what the real challenge was and what it was not. NVIDIA was not a multimedia company. It was not a console gaming company. It was a 3D graphics chip company for the PC, and it had to win that specific battle or cease to exist. In a jungle of conflicting possibilities, he named the one that mattered.
His Step 2 was a working specification precise enough to organize action across a small, stressed organization. NVIDIA would abandon its proprietary “surfaces” approach and embrace the DirectX standard triangles geometry. It would design its chips directly for Microsoft’s DirectX API rather than hedging its bets. In a chip industry geared to Intel’s 18-month release cycle, it would organize its engineers into three overlapping development teams to sustain a six-month release cycle. And it would design its own software drivers through simulation and emulation, rather than delegating that work to board manufacturers.
These specifications were concrete enough that engineers knew exactly what problem they were working on. The result was the RIVA 128, released in 1997, which saved the company. NVIDIA went from near failure to market leadership in four years.
The second occasion came in 2012-2013, when Huang faced a different kind of crisis. NVIDIA had spent seven years and enormous resources building CUDA, a programming platform that allowed scientists and researchers to use its graphics chips as general-purpose parallel computers. The investment had not paid off. CUDA downloads were declining. Profits were flat. An activist investor, Starboard Value, had taken a position in the company and was questioning whether Huang’s strategy made sense. Some board members were wavering. Fidelity, NVIDIA’s largest outside shareholder, told Huang directly that his case for CUDA was not persuasive.
His Step 1 was the decision to defend CUDA anyway — to declare, under sustained institutional pressure, that this unpopular bet on scientific computing was the right problem to be working on. Huang flew to Boston and New York to make his case to shareholders. He did not win them over but did retain the support of the board. In a jungle of competing arguments, Huang defined the way forward.
Soon after, a researcher named Bryan Catanzaro showed Huang that he could train an AI neural network hundreds of times faster on CUDA than on conventional processors. Huang spent a weekend immersed in the subject and emerged convinced that the entire company had to reorganize around this opportunity.
Step 2 began when he wrote O.I.A.L.O. on his whiteboard: Once In A Lifetime Opportunity. He sent an email telling his organization that NVIDIA was no longer a graphics company. He gave Catanzaro the authority to access any of the 8,000 NVIDIA employees to build cuDNN — a software library that would make CUDA the foundation of AI development. This project was to supersede everything else.
Neither of Huang’s Step 2 moves was a prediction about the future. In 1997, he did not know whether DirectX would win. In 2013, he did not know that neural networks would become a dominant paradigm of computing. What he imposed in each case was a workable representation of the situation — one concrete enough to organize action, durable enough to survive the uncertainty that remained.
The outcome of the second bet is now familiar. NVIDIA’s chips became the critical infrastructure of the AI era, and the company reached a valuation exceeding $3 trillion. But as with the moon landing, the result flowed from the specification, not from foresight about what the future would bring.
When dealing with coordination issues within their organization, leaders often resort to new cross-departmental structures, teams, and committees. However, a clear working specification on how work will be done can often sidestep the tangled web that such remedies create. A particularly clear example comes from Amazon under Jeff Bezos.
In the fourth quarter of 2002, Amazon surprised investors by reporting its first net profit since going public five years earlier. Given such signs of market success, most CEOs would not look for internal challenges.
But Bezos did. His Step 1 action was to recognize an internal challenge. Over time, Amazon’s internal systems had grown separately, becoming more isolated from one another. The applications became more complex and harder to couple. Coordination was harder.
In Step 2, he imposed a working specification. All teams would expose their functionality through well-defined APIs. Systems would communicate with one another only through these interfaces. There would be no “informal” workarounds. Most importantly, every API would be designed so that it could, potentially, be exposed to outside developers.
This was not a detailed blueprint of the final architecture. It was a simplifying rule that defined what was doable. Instead of managing an increasingly complex web of systems, teams now had a clear marching order: build services that could stand alone and communicate through standardized interfaces.
With this working specification in place, coordination improved and development accelerated. Over time, this architecture enabled Amazon to offer these services externally, becoming the foundation of Amazon Web Services.
Bezos could have followed mainline management practices and issued Amazon-wide performance goals, or “North Star” metrics. He could have organized cross-unit teams to cross silos or hosted “lunch and learn” huddles. Instead, he imposed a simple working specification that harnessed existing skills to jobs they could accomplish.
Two Examples from IKEA and Domino’s Pizza
In the 1950s, Ingvar Kamprad chose to scale his furniture brand without incurring the prohibitive costs of shipping and breakage. The “standard” move would have been to set efficiency goals for the shipping department. Instead, Kamprad imposed a Working Specification: Every product must fit in a flat box.
This specification restructured the entire company. It resolved ambiguity in global transport by making the customer the final assembly team. Designers and suppliers no longer tried to make the “best chair”; they focused on making a good chair that could be collapsed into a flat pack.
In the 1970s, the pizza industry was coming into its own with a focus on taste and quality. Tom Monaghan of Domino’s decided that the real challenge, at least the challenge he wanted to address, was customers’ frustration with the uncertainty of waiting times for pizza delivery.
His Step 2 was a striking Working Specification: 30 minutes or it’s free. This wasn’t just a sales pitch; it was a specification that forced every store manager to stop debating “perfection” and start working toward a single metric. It narrowed the field of play so drastically that it defined exactly how the kitchen should be laid out and how the delivery radius should be drawn.
Like Kamprad’s insight into how to deal with the challenge of global shipping, Elon Musk had insights into how to make rockets reusable and avoid the bureaucratic tangle of being a prime contractor.
When Musk began working on the problem of space launch costs, there was deep uncertainty about how to reduce them. The aerospace industry had long accepted that rockets were expendable. The physics of reentry were harsh. The Space Shuttle was supposed to be reusable, but it still had to be refurbished after each use. Thousands of silica tiles had to be inspected individually. Its RS-25 engines were often completely rebuilt.
Musk had an insight. Fuel was less expensive than rockets. Maybe, like in the old science-fiction movies, a rocket could carry enough fuel to turn around and descend tail-first, firing its engines to slow itself down. This approach would trade fuel for simplicity, avoiding the need for fragile thermal protection systems. His Step 1 was to create SpaceX to build such a rocket.
Musk’s Step 2 was a series of focused policies. SpaceX rockets would be completely redesigned, built in a low-cost, spare manner. They would not be adapted from intercontinental ballistic missiles. SpaceX would not be one of thousands of contractors. Its vehicles would not try to satisfy the Air Force by flying around the globe. Musk saw the challenge as engineering, not high science. The first step in the quest would be an intense, single-minded focus on reducing costs.
To reduce costs, Musk focused on simplicity in engineering and manufacturing and on limiting the number of subcontractors. The Falcon 9 used an Ethernet data bus rather than a custom design. The in-house machine shop produced special shapes for much less than an aerospace contractor would charge. The focused approach made it easier to attract good engineers. Working at big contractors was basically boring because most of the job was running subcontracts and dealing with the government. The engineers at SpaceX were stressed but not bored.
This working specification enabled progress. In 2015, Falcon 9 became the first rocket to reach orbit and land vertically. The cost savings were remarkable: by 2018, Falcon 9’s cost per pound to low-Earth orbit was twenty-three times lower than the space shuttle’s. Later, Falcon Heavy halved the Falcon 9’s cost per pound.
Musk did not resolve the uncertainty about reusability in advance. He imposed a workable representation of the problem—one that allowed focused effort and learning.
Learning to see the pattern
Once you understand the idea behind a Working Specification, it becomes visible. It’s the mark of a leader who won’t let their organization wander aimlessly, hoping to “do better,” but instead clearly defines what needs to get done.
See it in Ron Johnson’s design for the Apple Store, where he rejected the industry’s warehouse model. He specified that the store was not a place to store inventory, but a stage for solutions. By defining the store as a theater, he gave the staff a simplified reality where their job was to perform a service, not to move boxes.
Or look at Arthur Levitt at the SEC. Instead of leaving “investor protection” vague, he required that legal documents be written in plain English. He didn’t wait for endless debates about transparency—he just said, use the active voice and short sentences. That gave everyone a clear example to follow.
See it in Paul Polman at Unilever, who resolved the ambiguity of long-term strategy by simply abolishing quarterly earnings reports. He re-specified the firm’s timeline, removing the mechanism that forced short-term thinking.
Michael Joseph at Safaricom brought banking to millions by deciding that a simple text message could count as currency. At Toyota, Taiichi Ohno didn’t just tell people to aim for “fewer defects.” He made it simple: if there’s a problem, stop the assembly line immediately. Both leaders turned fuzzy goals into clear, actionable steps.
In each case, the leader functioned as a complexity filter. They didn’t just set a direction; they defined the “physics” of the work. They took a world of infinite variables and reduced it to an actionable constraint. They didn’t wait for the fog to clear—they defined a Working Specification and started walking.
The Work of Leadership
Just as people in 1964 didn’t fully understand what the Moon’s surface was really like, leaders today rarely have all the answers about the challenges they face. Still, leadership means having the courage to identify and define the most important challenge for their team or organization. Are customers changing their habits? Is innovation slowing down? Does new technology represent a risk or an opening? Are obstacles coming from competitors, internal politics, or simply from sticking to old ways?
In complex situations, uncertainty is always part of the picture. Leaders have to manage the stress of not knowing everything and give their teams a clear, workable path forward. This comes down to two things: identifying a critical challenge and outlining a practical plan to tackle it.
These plans aren’t perfect. They aren’t the final word, and they’ll change as people learn more and new information comes in. But without a working plan, organizations waste energy and get stuck—chasing lots of metrics or getting lost in endless what-ifs and analysis. Real progress starts when there’s a clear problem to solve. Good leaders help their teams move from confusion to action.
When a leader lays out a concrete plan, it’s not just about motivating the team—it’s about making it possible, actually, to get things done. By turning big, vague questions into clear, doable tasks, leaders give their organizations what they need most: a problem they can solve.
Whether it’s shifting from a messy software project to a simpler version, deciding that all furniture should be flat-packed, or setting one clear goal for a new technology, the job is always the same. A leader must absorb the buzzing confusion of reality and, in its place, define a clear task the organization is equipped to carry out.