Run a Big Mission or Program

How to organize people, resources, and time around a goal too large to accomplish by ordinary means

This guide is for someone who wants to lead a large, high-stakes endeavor — a program with a fixed deadline, immature technology, and consequences that matter — and who is starting before they occupy that seat day-to-day. The four books behind it describe four of the largest deliberate programs of the twentieth century: Apollo (told through the astronauts and through Gene Kranz's Mission Control), Lockheed's Skunk Works, and the Manhattan Project. They agree on a surprising amount and they disagree on things that matter, and both are useful to you. The through-line is a sequence you can follow: a threat or opportunity generates urgency; urgency mobilizes a mandate and clear mission; a mandate lets you buy technological maturity and reliability; maturity produces mission success; and success, at the largest scale, produces breakthroughs that outlast the program. Around that spine sit the human machinery — who you pick, who decides, what rules you set in advance, and how you rehearse — that determines whether the spine holds under pressure. Where the books split (who really drives execution; whether deadline pressure helps or harms; what counts as the non-negotiable outcome), this guide maps the camps and tells you how to choose for your own situation rather than pretending the corpus speaks with one voice.

Grounded in 4 books, 6 constructs, 5 relationships.

The reader An ambitious, mission-driven person who wants to lead a high-performing team through an unprecedented, high-stakes challenge and accomplish something historic.

The external problem. You face a complex, time-critical goal with immature technology, incomplete information, no proven playbook, and — often — an institution that is slow, bureaucratic, and risk-averse.

The internal problem. You feel unqualified and overwhelmed, afraid of failing the people who depend on you, and cynical about whether real breakthroughs are even possible inside the system you work in.

The path

Locate the urgency — the threat or deadline that will make people commit — and name it plainly.
Convert that urgency into a singular, clear mission and a durable mandate of political will and resources.
Break the ultimate objective into a progressive series of intermediate steps that each reduce risk.
Build technological maturity and reliability into the hardware, and let the schedule pressure moderate, not override, that reliability.
Decide your governance: a single empowered decision-maker plus rules set in advance, and how much autonomy your team gets.
Staff a small, handpicked team, build trust, and rehearse nominal and emergency conditions until performance is coordinated.
Drive to mission success against your one non-negotiable constraint — and let the breakthroughs follow.

Success. You lead a team that can improvise solutions no manual anticipated, bring people through crises intact, meet the objective against schedule and budget, and accomplish something that inspires the next generation to reach farther.

At stake. The program drifts without a clear goal, loses its mandate when will fades, ships immature technology under deadline pressure and pays for it in lives or in failure, and leaves nothing durable behind.

The transformation. You move from a frustrated, constrained individual doubting your ability to overcome institutional inertia into a leader with a mental model and a playbook — someone who sees a landscape of solvable challenges and knows how to organize a mission around them.

The model

The outcome: Mission Success and Objective Achievement

Mission Clarity and Political/Resource Mandate (core) — A singular, clearly articulated, ambitious goal backed by sustained national/organizational political will and mobilization of substantial financial, industrial, and human resources.
Mission Success and Objective Achievement (core) — Extent to which the endeavor achieves its primary objectives and produces its target output (safe crew return, functional weapon, flight-tested article), including efficiency against schedule/budget.
Technological Maturity, Reliability, and Redundancy (supported) — Readiness and robustness of hardware/software, including redundant components and simple robust designs, along with the underlying scientific/technical knowledge base enabling the work.
Breakthrough Novelty and Broader Impact (supported) — Non-linear advances in capability and their downstream consequences: scientific discovery, paradigm shifts in the domain, and lasting well-being/consequence outcomes.
Schedule Pressure and Sense of Urgency (supported) — Pervasive urgency from fixed high-stakes deadlines or existential threat, shaping decision-making, resource allocation, and risk assessment.
Realistic Simulation and Training (supported) — Intensive, high-fidelity rehearsal of nominal and emergency conditions to expose weaknesses and build coordinated, correctly-timed team performance and individual competence.

How they connect:

Mission Clarity and Political/Resource Mandate → enables → Mission Success and Objective Achievement
Schedule Pressure and Sense of Urgency → enables → Mission Clarity and Political/Resource Mandate
Schedule Pressure and Sense of Urgency → moderates → Technological Maturity, Reliability, and Redundancy
Technological Maturity, Reliability, and Redundancy → produces → Mission Success and Objective Achievement
Mission Success and Objective Achievement → produces → Breakthrough Novelty and Broader Impact

What good looks like

Foundations. You can name your mission in one sentence, you can point to the urgency that justifies it and the mandate that funds it, and you have broken the goal into intermediate steps that each reduce risk.
Practitioner. You are managing the real tradeoff between schedule pressure and technological reliability, you have set decision authority and Go/NoGo rules before execution, and your team rehearses failure until it responds correctly.
Advanced. You deliver against a non-negotiable constraint under crisis conditions, you know which governance model fits your situation, and the program produces breakthroughs and capability that outlive it.

Schedule Pressure and Sense of Urgency

Foundations

Every big program in this corpus was pushed forward by a pervasive sense of urgency — a fixed high-stakes deadline or an existential threat that shaped decision-making, resource allocation, and risk assessment. In the Manhattan Project the urgency was psychological before it was institutional: emigré physicists like Szilard, Wigner, and Frisch were convinced the bomb was feasible and that Nazi Germany, with its advanced physics community, might build it first, and that conviction — 'Geopolitical Threat Perception' — became the engine that eventually moved a national government to act. Apollo's urgency was a fixed, public, high-stakes deadline. Skunk Works ran on 'be quick, be quiet, be on time.' Urgency is where the chain begins: it is the raw force that, converted properly, produces a mandate and a clear mission.

Why it matters. If you cannot name a real reason the mission must happen now, you will not raise the political will or the resources to do it, and the program will drift. The Manhattan Project shows the sequence in its rawest form — the scientists' acute conviction of a race against Germany preceded and produced the government's decision to commit unprecedented resources. Without that felt urgency, the mobilization does not start.

The myth: Urgency is just stress — a cost to be minimized so people can do careful work.
The reality: Urgency is the mobilizing force. In the Manhattan account, the scientists' sense of a race against Nazi Germany is what converted a scientific possibility into a national program. Deadline pressure is what makes people commit resources they would otherwise conserve.

The myth: More schedule pressure always produces faster, better work.
The reality: The Apollo Mission Control books treat intense schedule pressure as a genuine risk to reliability — pressure that, unchecked, pushes teams to fly immature hardware. Urgency drives commitment upstream but constrains safety downstream; the two effects coexist and you must manage both.

How to:

State the threat or the deadline in one concrete sentence — what is lost, and by when, if the mission does not happen. Vague urgency mobilizes no one.
Trace who already feels this urgency and who does not; the Manhattan mobilization started with a small network of convinced people who then persuaded the government.
Use the deadline as an organizing device for resource allocation and prioritization — 'be on time' as a discipline, not a slogan.
Keep a running distinction between urgency-as-motivator (upstream, mobilizing commitment) and urgency-as-hazard (downstream, tempting you to skip reliability work).

Watch out for:

Manufactured urgency that no one actually believes — it burns credibility and does not mobilize resources.
Letting the deadline become the sole decision rule; the space books warn that this is exactly how immature technology gets flown before it should be.
Assuming urgency will stay hot on its own; the Manhattan case shows it took sustained conviction and repeated persuasion to keep the pressure translating into political action.

Grounded in: Lib0245aa9f6c78ec83; Libf8b70da144d9a15e; Lib463480206cc4670a

Mission Clarity and Political/Resource Mandate

Foundations

A big program needs a singular, clearly articulated, ambitious goal backed by sustained political will and the mobilization of substantial financial, industrial, and human resources. The Apollo chronicle names this directly: monumental achievements require a clear, audacious goal and the national will to commit vast resources. The Manhattan Project supplies the mechanism — 'Political Will and Resource Mobilization,' the U.S. government's decision to commit unprecedented resources to a secret, large-scale project. Clarity and mandate are two halves of one thing: a goal so clear that everyone can orient to it, and a commitment so durable that the goal survives contact with cost, delay, and doubt. This is the construct that enables mission success — nothing downstream works without it.

Why it matters. Programs die when the goal is ambiguous or the commitment is shallow. If the mission cannot be stated as one audacious, unambiguous objective, teams optimize for different things and the effort fragments. If the mandate is not sustained, the money and industrial capacity evaporate the first time the timeline slips — and every big program's timeline slips.

The myth: The mandate is a one-time approval — get the budget signed and you're set.
The reality: The corpus describes sustained commitment, not a single signature. Apollo required national will held across years and multiple flights; the Manhattan Project required continuous mobilization of financial, industrial, and human resources. A mandate is something you maintain, not something you obtain.

The myth: A big mission needs a big, complex set of objectives to match its ambition.
The reality: The pattern is the opposite: a singular, clearly articulated goal. The audacity is in the height of the one goal, not in the number of goals. Complexity in the objective statement dilutes the will it is supposed to concentrate.

How to:

Write the mission as one sentence a new team member could repeat back accurately — safe crew return, a functional weapon, a flight-tested aircraft. If it takes a paragraph, it is not yet clear.
Identify who holds the mandate — the person or body whose sustained commitment funds and protects the program — and build a direct channel to them.
Connect the mission explicitly to the urgency from the prior step; the clearer the threat or deadline, the easier the will is to sustain.
Secure the three resource streams the corpus names — financial, industrial, and human — and treat any one of them going thin as an early warning that the mandate is weakening.

Watch out for:

A goal that is audacious but not clear — inspiring in a speech, useless for daily prioritization.
A mandate that depends on a single champion; when they leave or lose interest, the commitment collapses. The Manhattan case shows will as something mobilized broadly, not vested in one person.
Confusing enthusiasm with commitment; commitment is measured in sustained resources actually delivered, not in stated support.

Grounded in: Libf8b70da144d9a15e; Lib0245aa9f6c78ec83; Lib463480206cc4670a

Technological Maturity, Reliability, and Redundancy

Practitioner

Once you have a mandate, the work becomes making the hardware, software, and knowledge base robust enough to succeed. This construct covers the readiness of systems, the use of redundant components and simple robust designs, and the underlying scientific and technical knowledge that makes the work possible at all. The Manhattan Project rested on 'Advances in Nuclear Physics' — decades of cumulative discovery from radioactivity to the neutron — without which no amount of will would have produced a weapon. Apollo built maturity through 'Incremental Mission Design,' deconstructing the ultimate objective into a progressive series of less complex intermediate missions, each building on the last and systematically reducing risk. Schedule pressure moderates this construct: urgency tempts you to fly before the technology is ready, and the discipline is to let pressure inform the work without letting it override reliability. Mature, reliable technology is what actually produces mission success.

Why it matters. This is where lives and outcomes are won or lost. The space books are explicit that exploration is inherently risky and progress often comes at the cost of near-disasters — and that the countermeasure is redundancy, simple robust designs, and hands-on systems knowledge deep enough to diagnose problems and build workarounds in real time. Skip maturity to meet a date and you convert schedule pressure directly into failure.

The myth: You reach a big goal by attempting the full objective as directly as possible.
The reality: Apollo's Incremental Mission Design did the opposite — a progressive series of intermediate missions, each reducing risk and developing expertise before the ultimate attempt. Complex endeavors succeed through methodical, incremental steps that learn from both successes and failures.

The myth: Redundancy and simplicity are opposites — you either build robust backups or you keep things simple.
The reality: The corpus pairs them: redundant components AND simple robust designs both serve reliability. Kranz's rule to treat docked spacecraft as a single integrated system is a reliability discipline, not a complexity one; simplicity and redundancy are two tactics toward the same robustness.

The myth: Deep systems knowledge lives in the engineers who built the hardware; operators just run it.
The reality: Mission Control's 'Learn by Doing' holds that controllers must personally acquire accessible, hands-on understanding of the systems — that depth is what enables rapid diagnosis and workaround development when something breaks in flight.

How to:

Deconstruct the ultimate objective into a progressive series of intermediate missions, each of which reduces a specific risk and builds a specific capability the next one needs.
Design for robustness deliberately: add redundancy where a single failure is unsurvivable, and prefer simple designs where complexity buys little.
Assess the maturity of the underlying knowledge base honestly — the Manhattan Project could only proceed because decades of physics had established the foundation; know what your equivalent foundation is and whether it holds.
Require operators to build hands-on systems knowledge, not just procedural familiarity, so the team can diagnose and improvise under failure.
Set an explicit rule for when schedule pressure may and may not override a reliability concern — decide it in advance, not in the moment.

Watch out for:

Letting the deadline decide readiness; the space books treat schedule pressure as precisely the force that pushes immature technology into flight.
Skipping intermediate steps because the mandate feels urgent — this trades near-term speed for the risk of an unrecoverable failure.
Assuming the knowledge base is more mature than it is; the Manhattan case shows how much cumulative science had to exist first.
Treating a docked or coupled system as separate parts; failures propagate across integrated systems and must be reasoned about as a whole.

Grounded in: Libf8b70da144d9a15e; Lib463480206cc4670a; Lib0245aa9f6c78ec83

Realistic Simulation and Training

Practitioner

Mature technology is inert until the people operating it are rehearsed. This construct is intensive, high-fidelity rehearsal of both nominal and emergency conditions, designed to expose weaknesses and build coordinated, correctly-timed team performance. Apollo's 'Rigorous Simulation and Training' put flight crews and ground controllers through exhaustive repeated practice in simulators that replicated the mission environment and a wide array of malfunctions. Kranz's Mission Control built the same discipline into 'Realistic Simulation Training' — rehearsing failure until the team's timing was coordinated and its weaknesses were found on the ground rather than in flight. Simulation is where reliability is converted into performance and where the team learns, before the stakes are real, how it behaves under stress.

Why it matters. Improvised solutions no manual anticipated — the thing that saved Apollo 13 — do not come from talent alone; they come from teams that have rehearsed failure so thoroughly that novel problems fall within reach of trained judgment. If you have not simulated the emergency, you meet it for the first time when it can kill someone. The whole point of high-fidelity rehearsal is to move the discovery of weaknesses from the mission to the simulator.

The myth: Training is about proving the team is ready — rehearsing what should go right.
The reality: The corpus emphasizes rehearsing what goes wrong. Simulation deliberately injects malfunctions to expose weaknesses; its purpose is to find and fix failure modes, not to confirm competence.

The myth: Once the individuals are skilled, the team is ready.
The reality: Simulation builds coordinated, correctly-timed team performance — the collective ability to act together under pressure, which is different from a sum of skilled individuals. The timing and the shared response are what get rehearsed.

How to:

Build rehearsals at the highest fidelity you can afford — the closer the simulator is to the real environment, the more real the weaknesses it exposes.
Deliberately inject a wide array of malfunctions, not just the likely ones; the goal is to surface failure modes before they matter.
Rehearse the ground team and the operators together, so coordination and timing are trained as one system rather than in isolation.
Treat every simulated failure as data — fix the weakness it exposed, then re-run.
Practice Kranz's real-time disciplines inside the sim: buy time, preserve options, never make a situation worse by guessing, and when you don't know, say so and find out.

Watch out for:

Simulations that only rehearse nominal operations — they build false confidence and leave the team untested against the conditions that actually threaten the mission.
Treating training as a box to check rather than a source of findings; if a sim never surfaces a weakness, it was not hard enough.
Rehearsing individuals but not the handoffs and timing between them, where coordinated performance actually lives.

Grounded in: Libf8b70da144d9a15e; Lib463480206cc4670a

Mission Success and Objective Achievement

Advanced

Mission success is the produced outcome: achieving the primary objective and delivering the target output — safe crew return, a functional weapon, a flight-tested article — including efficiency against schedule and budget. It is produced by mature, reliable technology operated by rehearsed teams under a clear mandate. But the corpus is honest that 'success' means different things in different missions: for the space books the non-negotiable is crew survival; for the Manhattan Project it is weapon development and the paradigm shift that followed; for Skunk Works it is innovation velocity and execution efficiency measured against performance specs, schedule, and budget. These are pooled under one construct but they carry different non-negotiable constraints, and knowing which one is yours changes every prior decision.

Why it matters. If you have not named your single non-negotiable constraint, you cannot make the tradeoffs the earlier steps demand. A program optimized for schedule (Skunk Works) makes different reliability calls than one optimized for crew survival (Apollo). Getting this wrong means you meet the wrong definition of success — on time and on budget but with a crew lost, or safe but too late to matter.

The myth: Success is simply hitting the objective; the constraint is the same everywhere.
The reality: The corpus shows three different non-negotiables — crew survival, weapon development, innovation velocity — each of which reorders every tradeoff below it. You must pick yours explicitly, because the books that optimized for one would not have made the same calls as the books that optimized for another.

The myth: Meeting the objective and meeting the schedule/budget are separate scorecards.
The reality: Skunk Works' Results-Based Accountability folds them together — success is measured and rewarded on tangible outcomes including performance specs, schedule, and budget, with frequent reviews that forecast the final result rather than audit process compliance.

How to:

Name your one non-negotiable constraint before execution — the thing you will never trade away — and make sure the whole team knows it: crew survival, functional output, or velocity.
Define success as tangible outcomes and forecast them frequently; run transparent cost and progress reviews that predict the final result, in the Skunk Works manner.
Ensure every earlier decision — reliability tradeoffs, training emphasis, decision rules — is aligned to the constraint you named.
Measure efficiency against schedule and budget as part of success, not separate from it, but never above the non-negotiable constraint.

Watch out for:

Silent disagreement about what success means — different team members optimizing for crew safety, output, and speed without ever reconciling.
Letting schedule and budget efficiency creep above the non-negotiable constraint; for a crew-survival mission, on-time-and-over-a-life is failure.
Reviews that audit process instead of forecasting outcomes; Skunk Works warns that process compliance is not the same as tangible results.

Grounded in: Libf8b70da144d9a15e; Lib463480206cc4670a; Libf8e43aa7bb75e365; Lib0245aa9f6c78ec83

Breakthrough Novelty and Broader Impact

Advanced

The largest missions produce more than their stated output. This construct covers non-linear advances in capability and their downstream consequences — scientific discovery, paradigm shifts in the domain, and lasting well-being and consequence outcomes. Mission success produces these effects when the goal is big enough. The Manhattan Project is the corpus's starkest case: the achievement of the weapon produced a paradigm shift in warfare and sovereignty, and the book argues total war between superpowers became obsolete once the consequences were starkly obvious. It also insists knowledge has unintended and often uncomfortable consequences that cannot be filtered for benevolence — breakthrough impact is not always the impact you intended. Apollo's version is quieter and human: the unifying perspective of viewing Earth from a distance, and astronaut well-being as a lasting outcome.

Why it matters. If you lead a program that succeeds at real scale, its effects will outrun your intentions, and pretending otherwise is a failure of foresight. The Manhattan account is unambiguous that fundamental discovery is not found because it is useful but because it is possible, and that its consequences cannot be filtered for benevolence — as long as any state holds nuclear weapons, others will seek them. A leader who does not reckon with the downstream impact of a big mission is only half-doing the job.

The myth: Breakthroughs are the point of the mission — you set out to change the paradigm.
The reality: In the corpus, breakthrough is a downstream product of mission success, not the primary objective. Apollo's goal was a lunar mission; the unifying view of Earth was a consequence. Manhattan's goal was a weapon; the shift in warfare was what followed.

The myth: Because you built it for a good purpose, its consequences will be good.
The reality: The Manhattan account rejects this directly: knowledge has unintended and uncomfortable consequences that cannot be filtered for benevolence. Impact does not obey the intentions of the people who created the capability.

How to:

Distinguish your stated objective from the broader impact it may produce, and think through the downstream consequences before, not after, success arrives.
Accept that fundamental capability, once created, spreads — the Manhattan case argues that as long as any state holds a capability, others will seek it. Plan for a world in which your breakthrough is no longer yours alone.
Attend to the human and well-being consequences of the mission, as the Apollo chronicle does with astronaut well-being and the unifying Earth-from-distance perspective, not only the technical output.
Treat the paradigm shift as a responsibility of leadership, not a bonus — engage thoughtfully with the consequences your program sets in motion.

Watch out for:

Assuming the impact will match your intentions; the corpus is explicit that consequences cannot be filtered for benevolence.
Ignoring the human dimension of a technical success; the astronaut accounts show well-being and perspective as real, lasting outcomes.
Treating breakthrough as something you can command directly rather than a product that success generates when the mission is large enough.

Grounded in: Lib0245aa9f6c78ec83; Libf8b70da144d9a15e; Libf8e43aa7bb75e365

Live tensions in the field

Where the corpus genuinely disagrees — these are choices to make for your situation, not settled answers.

Who really drives execution — a single empowered decision-maker with rules set in advance, or an autonomous team with intrinsic ownership and minimal process?

Mission Control model: a single empowered flight director authorized to make any call for crew safety and mission success, backed by predefined Go/NoGo and mission rules that settle debate before flight, and a culture of discipline and accountability ('Tough and Competent'). · Skunk Works model: organizational autonomy, radically simplified processes, small handpicked co-located teams, and a program manager given nearly complete control — execution driven by ownership and low bureaucracy rather than by real-time central authority plus a rulebook.

This is a context-contingent split (contested across the corpus), and the deciding variable is the nature of your operations. If you run irreversible, time-critical operations where a wrong call is fatal and unrecoverable — anything resembling a live flight — lean to the Mission Control model: one empowered decision-maker and Go/NoGo rules written in advance are what make disciplined real-time decisions possible when there is no time to deliberate. If you run a development program where the enemy is bureaucracy, iteration speed, and institutional inertia — building the article rather than operating it — lean to the Skunk Works model: autonomy, simplified process, co-location, and a single accountable program manager. Most large programs contain both phases; the honest move is to apply the development model while building and the real-time-authority model while operating, and to be explicit about which regime you are in at any moment.

Is schedule pressure a productive driver or a hazard to reliability?

Urgency as engine: in the Manhattan account, the scientists' sense of urgency and threat perception is what mobilized political will and unprecedented resources — pressure is generative. · Urgency as constraint: the Apollo Mission Control books treat intense schedule pressure as a risk to reliability, a force that tempts teams to fly immature technology.

These are not actually contradictory once you place them in the causal chain — they describe pressure acting at two different points. Upstream, urgency mobilizes the mandate; this is where the Manhattan reading holds and where you should use urgency deliberately to build commitment. Downstream, that same pressure endangers technological maturity; this is where the Apollo reading holds and where you must fence off reliability decisions from the deadline. The practical rule: let urgency drive commitment and prioritization, and set an explicit boundary — decided before execution — where schedule pressure is not allowed to override a reliability or safety judgment. Treat both effects as real simultaneously rather than choosing one.

Which comes first — the mandate or the urgency?

Urgency first: the Manhattan account has the scientists' urgency and threat perception preceding and producing the government's political will. · Mandate as prior condition: the Apollo chronicle treats programmatic clarity and national commitment as the independent starting condition that enables everything else.

This is a directionality disagreement, and which one describes your situation depends on where you sit. If you are an insurgent trying to start a program that does not yet exist — the position most aspiring readers are in — the Manhattan sequence is your template: generate and communicate urgency first, and use it to build the mandate you don't yet have. If you have already been handed a clear goal and sustained resources, the Apollo framing fits: the mandate is your given, and your job is to execute against it. For someone building from where they are now, plan to earn the mandate through urgency, not to wait for a mandate to appear.

What is the non-negotiable outcome — crew survival, delivered output, or velocity and efficiency?

Crew survival above all (the space books): safe return is the constraint no schedule or budget may override. · Weapon development and paradigm shift (Manhattan): the functional output and its strategic consequence are the point. · Innovation velocity and execution efficiency (Skunk Works): tangible results against performance specs, schedule, and budget, measured through frequent forecasting reviews.

This is context-contingent by definition — the right non-negotiable is set by what your mission is, and the error is leaving it implicit. Name your single constraint before execution and align every prior decision to it. A crew-survival mission accepts schedule slips to protect life; a velocity mission accepts a narrower performance envelope to hit the date; a development mission may accept cost to secure the strategic output. All three are legitimate; what is not legitimate is a team that has never agreed which one governs, because then reliability tradeoffs, training emphasis, and decision rules pull in different directions. Decide it once, out loud, and let it order everything.

Sources

Lib0245aa9f6c78ec83
This book chronicles the convergence of scientific discovery, political will, and global conflict that led to the development of the atomic bomb, permanently altering the nature of warfare and international relations.
Lib463480206cc4670a
Gene Kranz, NASA's legendary flight director, recounts the human ingenuity, discipline, and teamwork behind Mission Control that carried America from its first faltering rocket launches through the Moon landings and the rescue of Apollo 13.
Libf8b70da144d9a15e
A definitive chronicle of the Apollo moon missions, told through the personal experiences and in-depth interviews with the 24 astronauts who voyaged to the Moon.
Libf8e43aa7bb75e365
The firsthand account by the head of Lockheed's legendary Skunk Works, revealing the management principles and engineering secrets behind the creation of America's most advanced Cold War aircraft, including the U-2, SR-71 Blackbird, and the F-117 Stealth Fighter.