Transformation Case Library

GENESIS CASE LIBRARY WEBSITE
GENESIS CASE LIBRARY WEBSITE
Genesis Pro Transformation Case Library
This case library provides a set of
real‑world transformation stories
 that mirror the Project Wildfire model. Each example shows how a small, empowered team overcame the inertia of a large, regulated organisation to deliver outsized results in weeks or months rather than years. The intent is to inspire Genesis Pro users and to provide concrete patterns – such as protected
tiger teams
, time‑boxed sprints, user‑centric design and outcome‑based contracts – that can be applied within Sierra Nevada Corporation and other large enterprises. Each case summarises the setting, the trigger for change, the intervention design, execution mechanics, outcomes and key lessons. Citations point to credible external sources for factual statements. The internal case library and Executive Synthesis documents have been distilled into prose; readers are encouraged to consult those documents for deeper background.
How to use this library
The cases are organised alphabetically. For each story, you’ll find:
Setting & constraints
 – the organisational context, including size, regulatory environment and cultural impediments.
Trigger
 – the crisis or strategic opportunity that forced leaders to try a different approach.
Intervention design
 – how leaders structured the “tiger team” or skunkworks.
Execution mechanics
 – rituals, iteration cadence, user engagement and how blockers were removed.
Outcomes & impact
 – quantifiable results, lasting capability and any drawbacks.
Lessons & relevance
 – patterns that translate to Project Wildfire and cautions to avoid.
While each case reflects its own era and industry, common themes emerge: radical simplification of governance, empowered cross‑functional teams, rapid feedback loops with end‑users, and a relentless focus on outcomes over process. These are the hallmarks of the Wildfire playbook.
General Electric “FastWorks” Lean Startup Initiative (2013‑2016)
Setting & constraints
General Electric was a 100‑year‑old industrial conglomerate that prided itself on rigorous Six Sigma quality and multiyear product cycles. By 2012, the company faced slower growth and disruption from nimble competitors. Development cycles for engines, turbines and appliances often took five to seven years, and engineers were discouraged from experimenting for fear of harming reliability or regulatory certification. This heavyweight, risk‑averse culture stifled innovation and left GE vulnerable to new entrants.
Trigger
In 2012 – 2013 GE executives, including CEO Jeff Immelt and marketing VP Viv Goldstein, visited Silicon Valley and learned about the Lean Startup movement. A pilot refrigerator project using Lean principles delivered a new high‑end fridge in roughly half the time and cost of a normal program, with sales twice the usual rate. This success – coupled with growing competitive pressure and expensive failures in the traditional pipeline – convinced leadership to launch the
FastWorks
 program across GE.
Intervention design
FastWorks was not a single product but a
framework for rapid, customer‑validated innovation
. GE partnered with
Lean Startup
 author
Eric Ries
, who coached executives and teams on building minimum viable products (MVPs), testing assumptions and iterating quickly. Cross‑functional teams were formed and granted permission to bypass some of GE’s heavy tollgates. Funding was released in small tranches contingent on learning milestones rather than full five‑year budgets. Employees received intensive training and Lean coaches were embedded in each business unit. This hybrid staffing model paired GE veterans with external startup experts to accelerate cultural change.
Execution mechanics
FastWorks teams adopted
build‑measure‑learn
 cycles. Hardware teams could not iterate every two weeks like software, but they radically increased the frequency of customer touchpoints. For the refrigerator pilot, GE built functional prototypes and invited potential buyers to evaluate features, discarding those that didn’t resonate. Teams were measured on learning and validated assumptions rather than final product specs. Middle managers were told to tolerate failure; Immelt publicly encouraged experimentation, saying that
“going too slow is riskier than going too fast”
. To scale the practice, GE trained over a thousand executives on Lean principles and created internal “FastWorks coaches” to mentor new teams.
Outcomes & impact
FastWorks projects delivered striking results. A new gas turbine was brought to market
two years earlier
 than competitors, with
development costs cut by 60 %
 and customer‑validation costs reduced by
80 %
, according to an internal case study. Other projects avoided hundreds of millions of dollars in sunk costs by testing assumptions early and cancelling unneeded features. GE’s internal surveys showed that teams felt more empowered and customer‑focused. However, the program’s momentum waned after leadership changes in 2017, highlighting the need for sustained executive sponsorship and integration into core processes.
Lessons & relevance
Top‑down sponsorship with bottom‑up autonomy
 – GE’s CEO publicly endorsed experimentation and shielded pilot teams. Wildfire will likewise need senior leaders who tolerate risk and reward learning.
Hybrid expertise
 – pairing domain experts with external Lean coaches accelerated cultural change. Wildfire’s model of internal “cadets” coached by AI specialists mirrors this.
Outcome‑based funding
 – small tranches tied to learning milestones kept teams focused and allowed pivoting without large sunk costs.
Durability risk
 – FastWorks lost momentum when leadership priorities shifted. Wildfire should embed its practices into governance and talent pipelines to outlast individual champions.
HealthCare.gov “Tech Surge” & U.S. Digital Service (2013‑2015)
Setting & constraints
HealthCare.gov was a multi‑agency IT program governed by federal procurement rules and built by multiple contractors. At launch in October 2013 the website crashed; users could not create accounts and enrollment numbers were embarrassingly low. The environment was characterised by rigid contracts, extensive documentation and waterfall processes, which hindered rapid fixes.
Trigger
The public failure of the Affordable Care Act’s enrollment portal created a political crisis. With millions of Americans unable to obtain health insurance, the White House declared a “tech surge.” Senior officials such as U.S. Chief Technology Officer Todd Park sought outside help, and engineers from Google, Red Hat and other companies volunteered to rescue the site.
Intervention design
A
small, empowered tiger team
 of 8–10 engineers and product experts co‑located in a war room in Maryland. Led by Jeff Zients and Mikey Dickerson (a site reliability engineer from Google), the team bypassed the normal chain of command and was authorised to make changes directly. Twice‑daily stand‑ups focused on the most critical issues, and new monitoring tools were installed to diagnose bottlenecks. The team prioritised stabilising the core user journey and deferred less essential features.
Execution mechanics
The surge team ran in continuous sprints: they made production deployments daily and sometimes multiple times a day to fix bugs and performance issues. To remove blockers, they had a direct line to senior White House officials who could overrule contract officers or agency heads. Stand‑up meetings at 10 am and 6.30 pm ensured problems were surfaced quickly and progress was monitored. Within weeks the success rate of user logins climbed from single digits to over 90 %, and by late December the site could handle over 50,000 concurrent users, allowing
130,000 individuals to enroll by December 23
.
Outcomes & impact
The tech surge rescued HealthCare.gov, salvaging the Affordable Care Act. More importantly, it spurred the creation of the
U.S. Digital Service (USDS)
, a permanent organisation that recruits top technologists into government. USDS has since tackled dozens of projects across agencies, promoting agile procurement and user‑centric design. The crisis also produced the
Digital Services Playbook
 and
TechFAR Handbook
, which provide guidance on iterative development and outcome‑based contracts.
Lessons & relevance
Crisis as catalyst
 – major mission failure opened the door for unconventional approaches. Wildfire may similarly leverage urgent business needs to bypass red tape.
Small team, big impact
 – a handful of experts with authority outperformed hundreds of contractors. Protecting focus and giving real decision rights are essential.
Leadership air cover
 – direct backing from the White House allowed rapid escalation and rule‑bending. For Wildfire, executive sponsorship must be explicit and visible.
Institutionalise the win
 – codifying practices in playbooks and creating a permanent digital service prevented knowledge from evaporating when the crisis ended. Wildfire should plan for capability transfer and ongoing governance after each sprint.
IBM “Project Chess” – Personal Computer Skunkworks (1980‑1981)
Setting & constraints
By 1980, IBM was synonymous with mainframes and bureaucracy. Product development required thick “Blue Book” specifications, layers of review and proprietary components. In the face of a nascent personal computer market dominated by Apple and others, IBM’s standard processes would take too long to deliver a competitive product. The company risked missing a strategic shift.
Trigger
CEO Frank Cary and vice president Bill Lowe realised that if IBM did not ship a PC within a year it would cede the market to competitors. They challenged a small group in Florida to build a prototype quickly using off‑the‑shelf parts. The exploding consumer PC market and internal warnings from employees who were buying Apple II computers created the impetus for change.
Intervention design
Lowe formed
“Project Chess,”
 a skunkworks of about a dozen engineers and managers (dubbed the “Dirty Dozen”) based in Boca Raton. The team was insulated from IBM’s normal divisions and reported directly to corporate leadership. They were authorised to break rules: they used an Intel 8088 processor and licensed Microsoft’s operating system rather than insisting on IBM‑designed components. The architecture was intentionally
open
 so third‑party peripherals could be used. This autonomy and willingness to partner externally were unprecedented for IBM.
Execution mechanics
The skunkworks worked with a startup mentality. They built a functional prototype in roughly
eight months
, testing parts from multiple suppliers and writing just enough proprietary firmware (the BIOS) to glue them together. Decision cycles were short; Don Estridge, the project leader, could approve changes without waiting for headquarters. Once the design was finalised, the team published technical specifications so that third parties could build compatible hardware and software.
Outcomes & impact
On
August 12 1981
 IBM announced the
Personal Computer 5150
, introducing a new architecture that would dominate the industry. The product’s development took about one year – unheard‑of speed for IBM – and it captured significant market share. The open architecture allowed an ecosystem of “IBM PC compatible” clones, which fuelled the growth of Microsoft and the wider PC market. Internally, IBM created a new Entry Systems Division around the team, demonstrating that skunkworks could become enduring businesses. However, the open approach also meant IBM later lost control of the standard, illustrating the need to balance speed with strategic control.
Lessons & relevance
Separation and executive mandate
 – isolating the team and giving it direct access to leadership allowed radical deviation from corporate norms. Wildfire teams should likewise operate semi‑independently with clear executive backing.
Leverage external components
 – by adopting third‑party processors and software, IBM cut development time drastically. Wildfire should avoid reinventing commodity technologies; use proven open‑source tools and partners where appropriate.
Open vs. control trade‑off
 – an open architecture accelerates adoption but may cede long‑term control. Project teams must weigh speed against strategic IP considerations.
ING Bank Agile Transformation (2015‑present)
Setting & constraints
ING, a global bank with thousands of employees, operated like most financial institutions: siloed departments (IT, risk, marketing, product) and waterfall project management. Releases occurred only a few times per year and hand‑offs between functions caused delays. Regulatory oversight and risk management added layers of approval. This structure hindered ING’s ability to respond to fintech competitors and rising customer expectations for seamless digital services.
Trigger
By 2014, executives concluded that incremental improvements were insufficient. Visits to companies like Spotify and Google showed that small, autonomous squads could innovate faster. CEO Ralph Hamers and COO Bart Schlatmann decided to reorganise the bank’s headquarters in the Netherlands using the “Spotify model.” Competitive pressure from fintech, low interest rates and internal pilot successes provided the impetus.
Intervention design
In 2015 ING
dissolved traditional departments
 and reorganised
3,500 head‑office employees into roughly 350 nine‑person squads
, grouped into 13 tribes. Each squad contained a product owner, developers, UX designers, risk/compliance specialists and marketing experts – all co‑located. Middle management roles were eliminated; chapter leads focused on professional development rather than directing work. Quarterly business reviews replaced annual planning, and squads were empowered to release software every few weeks. Regulators and auditors were engaged early, and risk officers were embedded within squads to ensure compliance without slowing delivery.
Execution mechanics
Squads followed two‑week sprints with daily stand‑ups and bi‑weekly demos. Continuous integration pipelines enabled teams to push code to production every two to three weeks rather than five or six times per year. Decision rights resided with the product owner and the squad; alignment across squads came via tribe ceremonies and agile coaches. Employees underwent extensive training and many had to reapply for new roles. ING invested in DevOps tooling and collaboration software to support transparency. Regular retrospectives surfaced blockers, which were escalated to tribe leads or executive sponsors for quick resolution.
Outcomes & impact
The transformation improved
time‑to‑market, productivity and employee engagement
. External research notes that ING’s agile program reduced workforce by about 25 %, yet the bank saw a
60 % increase in primary customers between 2012 and 2018
, improved its Net Promoter Score from –21 to –7 within two years, and lowered its cost‑to‑income ratio from 65 % to 51 %. Release frequency increased from 5–6 per year to releases every two to three weeks. Employee surveys reported higher satisfaction due to increased autonomy and purpose. ING’s agile model has since been emulated by other banks, demonstrating durability.
Lessons & relevance
Whole‑system restructuring
 – ING didn’t pilot agile with one department; it reorganised the entire headquarters. Wildfire may not need a big bang, but the lesson is that silo‑spanning changes may be necessary for sustained agility.
Cross‑functional squads
 – embedding compliance, product, IT and marketing into one team eliminated hand‑offs and accelerated delivery. Wildfire teams should similarly integrate AI engineers, domain experts, security and product owners.
Risk integration
 – by embedding risk officers and dedicating risk squads, ING ensured compliance while maintaining speed. Wildfire’s sprints in a regulated defence environment must also include security and legal perspectives from day one.
Clear metrics and transparency
 – ING monitored customer satisfaction, release frequency and productivity to demonstrate the benefits of agility. Wildfire should measure outcomes and share them to build momentum.
Joint Special Operations Command “Team‑of‑Teams” (2004‑2008)
Setting & constraints
Joint Special Operations Command (JSOC) brought together elite units (Delta Force, Navy SEALs, Rangers) but operated with highly compartmented information and hierarchical decision‑making. Intelligence and operations were siloed, and security rules restricted information sharing. The organisation excelled at meticulously planned raids but struggled to adapt quickly to a networked insurgency in Iraq.
Trigger
As the insurgency intensified around 2004, JSOC’s carefully planned raids often failed because targets moved or adapted faster than the command’s decision cycle. General Stanley McChrystal observed that the old model could not keep pace with decentralised adversaries and realised that continuing to operate in silos would result in failure. He used mission failures and rising casualties as a burning platform to argue for change.
Intervention design
McChrystal adopted a
“Team of Teams”
 approach. Rather than forming a temporary task force, he restructured JSOC into a network of small, cross‑functional teams that shared information freely. Daily video teleconferences (90‑minute “operations and intelligence” briefs) connected thousands of operators, analysts and liaisons across agencies. Intelligence analysts were embedded with commando units and vice versa. Decision authority for missions was delegated to frontline teams, while leadership provided intent and removed blockers. Classification barriers were lowered to default to information sharing rather than need‑to‑know.
Execution mechanics
The new model operated on rapid
feedback loops
: seized phones and documents were analysed overnight and fed into the next day’s brief; targets were hit the same night based on fresh intel. JSOC went from conducting a handful of raids per month to
300 raids per month by August 2006
. Shared situational awareness via daily briefs ensured that even junior operators understood the strategic picture and could adapt in real time. Culture change required physically co‑locating units and embedding analysts with operators to build trust. Leaders maintained “eyes on, hands off,” monitoring overall effort without micromanaging decisions.
Outcomes & impact
The transformation dramatically increased JSOC’s operational tempo and effectiveness. Insurgent networks were disrupted, key leaders were captured or killed, and the decision cycle shrank from days to minutes. The model’s influence extended beyond the military: businesses and public agencies studied “Team of Teams” as a blueprint for agile adaptation. However, sustaining radical transparency required continuous leadership reinforcement; some secrecy crept back after McChrystal’s tenure.
Lessons & relevance
Shared consciousness + empowered execution
 – giving everyone context enabled frontline teams to act without waiting for headquarters. Wildfire teams should ensure cross‑functional situational awareness and push decisions down to the people with the most information.
Information sharing as default
 – replacing “need to know” with “need to share” created a common operating picture. In regulated environments, this requires careful classification but can dramatically improve speed.
Network over hierarchy
 – JSOC shows that even the most secretive institutions can operate as a network of small teams when the mission demands it. Wildfire should foster networks across SNC’s divisions rather than hierarchical chains.
Leadership vulnerability
 – McChrystal had to let go of control and trust his teams. Similarly, Project Wildfire’s sponsors must avoid micromanaging and instead focus on removing obstacles.
Kessel Run – U.S. Air Force Software Factory (2017‑present)
Setting & constraints
Before 2017 the Air Force’s Air Operations Center modernisation program had spent hundreds of millions of dollars over a decade without delivering usable software. Waterfall development, rigid procurement rules and heavy security accreditations meant that field operators were planning missions with whiteboards and spreadsheets. Software releases required years and rarely reflected user needs.
Trigger
In 2016, a visit by the Defense Innovation Board to the Qatar Air Operations Center exposed the antiquated tools. Meanwhile, an agile pilot funded with \$1 million produced a tanker planning app called
Jigsaw
 in just
four months
, saving significant fuel costs. When leaders saw that a small team could outperform a \$745 million program, they cancelled the legacy contract and launched
Kessel Run
 to scale the agile approach.
Intervention design
Kessel Run became an internal
software factory
: cross‑functional squads of Airmen developers, product managers, UX designers and security specialists working alongside warfighters. The team co‑located in a startup‑style space in Boston using commercial cloud environments. They adopted DevSecOps pipelines capable of promoting code from unclassified to classified networks automatically. Contracting used
Other Transaction Authority (OTA)
 agreements to engage commercial partners quickly and avoid Federal Acquisition Regulations that slow innovation. Selection emphasised high‑aptitude Airmen who were trained via coding boot camps.
Execution mechanics
Teams worked in
short sprints
 and delivered minimum viable applications within weeks. The
Jigsaw
 tanker planner was built in 124 days and saved roughly \$750,000–\$1 million per week in fuel. Once fully operational, Kessel Run averaged
one deployment every 3.3 hours
, even to classified networks. Continuous integration/testing pipelines automated security scans, enabling rapid releases without compromising compliance. Embedded warfighters provided daily feedback; if a new mission required a feature, coders implemented and deployed it within hours. Leadership protected the team from traditional program offices and championed the mantra that “going too slow is riskier than going too fast.”
Outcomes & impact
Kessel Run delivered working software to the field in months versus years. Apps such as
Jigsaw
,
Slapshot
 and
Kraken
 are now used daily across U.S. Central Command. During the 2021 Afghanistan evacuation, Kessel Run’s software enabled planners to adjust flight schedules on the fly; when an app crashed under unprecedented load, the team shipped a fix within hours. The program grew to
2,000 personnel
 within three years and saved the Air Force millions of dollars. Its success inspired similar initiatives across the U.S. military (e.g., Navy’s
Black Pearl
), and policy reforms now prioritise agile software acquisition.
Lessons & relevance
Embedding users and developers
 – warfighters sat next to coders, ensuring that software solved real problems. Wildfire should co‑locate AI engineers with engineers or analysts in the business units.
Secure experimentation
 – Kessel Run built pipelines that allowed experimentation on unclassified networks but promoted code to classified networks automatically. Wildfire will need a similar sandbox that mirrors security requirements.
Outcomes justify the model
 – the program’s early success provided undeniable evidence to cancel legacy contracts and invest in agility. Wildfire should aim for measurable wins early to build momentum.
Leadership messaging
 – Air Force leaders explicitly stated that going slow was riskier than going fast, reframing compliance arguments. Executive messaging will be critical to change mindsets inside SNC.
Lockheed Martin “Skunk Works” (1943–Cold War)
Setting & constraints
During World War II and the Cold War, Lockheed Aircraft Corporation operated under strict War Department oversight. Normal aircraft programs involved multiple departments, thick documentation and slow procurement processes. Cutting‑edge projects like jet fighters and spy planes needed secrecy, but the existing matrix organisation created delays and risk aversion. Kelly Johnson, an engineer known for challenging bureaucracy, believed the standard system could not deliver a jet in time.
Trigger
In June 1943, the U.S. Army Air Forces gave Lockheed
180 days
 to design and build a prototype jet fighter to match Germany’s advances. Johnson persuaded Lockheed’s president to support a crash program outside normal channels. Similar urgency recurred during the Cold War with projects like the U‑2 and SR‑71 spy planes.
Intervention design
Johnson created a
tiger team
 of 23 hand‑picked engineers and 30 mechanics working in a rented circus tent – the original “Skunk Works”. The team reported directly to Lockheed’s division president and had its own purchasing unit to bypass corporate procurement. Only a handful of Army officers acted as liaisons, making decisions by phone within hours rather than through committees. Johnson articulated
14 rules
 that codified the skunkworks ethos.
Execution mechanics
The team worked six days a week and solved problems face‑to‑face. Just nine days after kickoff they presented a mock‑up to the Army, accelerating approvals. When novel issues arose, the small group brainstormed and implemented fixes without waiting for formal reviews. They delivered the XP‑80 prototype
in 143 days
, beating the already aggressive deadline. This rapid iterative approach became a hallmark of Skunk Works projects.
Outcomes & impact
The XP‑80 (later P‑80
Shooting Star
) became the first U.S. jet fighter; over 6,000 units were eventually produced. Skunk Works went on to produce revolutionary aircraft like the U‑2, SR‑71 and F‑117 stealth fighter on similarly accelerated timelines. The division became a permanent part of Lockheed, institutionalising a rapid‑innovation capability. The term “skunk works” entered the business lexicon as shorthand for a protected innovation team.
Lessons & relevance
Extreme focus and autonomy
 – small, hand‑picked teams working off‑site with direct executive access can achieve breakthroughs. Wildfire should protect its teams from corporate bureaucracy and give them authority to make decisions quickly.
Simplified governance
 – one customer liaison empowered to make decisions dramatically cut delays. Wildfire should minimise decision points and ensure a single empowered product owner.
Culture of trust
 – Johnson’s rules emphasised personal responsibility and direct communication. Wildfire teams should adopt similar norms: own the outcome, cut documentation to essentials and speak up.
Durability through institutionalisation
 – Skunk Works became an enduring division because its methods were codified. Wildfire should aim to create a standing capability within SNC, not just one‑off projects.
NUMMI (New United Motor Manufacturing, Inc.) – Toyota/GM Joint Venture (1984‑1990s)
Setting & constraints
General Motors’ Fremont plant in California was considered its worst factory in the early 1980s. Absenteeism exceeded
20 %
, quality was poor and labour relations were adversarial. GM wanted to learn Toyota’s production system but doubted that American workers could adopt its practices. Toyota sought a manufacturing foothold in the U.S. The plant had a troubled workforce and a rigid, top‑down management culture.
Trigger
To reopen the idled plant and rebuild trust with the United Auto Workers, GM partnered with Toyota to form
NUMMI
 in 1984. The joint venture aimed to produce compact cars using Toyota’s lean production system. The crisis was GM’s declining market share and reputation for poor quality; Toyota’s trigger was the need to produce cars in the U.S. to avoid trade restrictions.
Intervention design
Toyota rehired the same Fremont workers but sent many to its Takaoka plant in Japan to learn Toyota Production System (TPS) methods. NUMMI adopted
andon systems
, daily problem‑solving meetings and a culture of respect for workers. Supervisors were retrained to support frontline teams instead of policing them. Workers were empowered to stop the assembly line to fix defects. Toyota managers and trainers stayed on site for months to mentor GM personnel, facilitating deep capability transfer.
Execution mechanics
The plant operated using
just‑in‑time
 production with minimal inventory. Problems were surfaced immediately via andon cords, and teams held daily “kaizen” sessions to eliminate root causes. Cross‑functional teams included line workers, maintenance and engineering, who were encouraged to suggest improvements. Management responded quickly to issues rather than hiding them. The emphasis on continuous improvement and respect for people created psychological safety for experimentation.
Outcomes & impact
Within a year of reopening, NUMMI transformed from GM’s worst plant to its best. Absenteeism dropped from
over 20 % to 2 %
, and the same workforce matched Toyota’s quality levels. NUMMI’s success proved that lean manufacturing was transferable to American factories and influenced GM and the broader U.S. auto industry. The venture lasted until 2010 and paved the way for the adoption of TPS principles across manufacturing. Tesla later purchased the Fremont facility, which continues to produce vehicles.
Lessons & relevance
Culture can change
 – NUMMI showed that with respect, training and empowerment, even a “problem” workforce can embrace lean practices. Wildfire should not assume cultural resistance is insurmountable; invest in training and create an environment of trust.
Pairing experts with locals
 – Toyota embedded its lean masters alongside GM employees, mirroring Wildfire’s external coaches working with internal “cadets.” Mentorship over months, not weeks, was key to lasting adoption.
Problem visibility and rapid resolution
 – andon systems and daily kaizen made issues visible and resolved them quickly. Wildfire should encourage teams to surface blockers immediately and provide mechanisms for rapid escalation and resolution.
Respect for people
 – treating frontline workers as problem‑solvers rather than cogs increased engagement and quality. Wildfire teams should ensure that domain experts and engineers are equal partners in designing solutions.
Operations Research “Blackett’s Circus” (1942‑1945)
Setting & constraints
During World War II, Allied militaries were hierarchical and relied on intuition and tradition. Information was stove‑piped and line officers often resisted outside advice. U‑boat attacks threatened Britain’s survival, yet tactics like depth‑charge settings and convoy sizes were based on guesswork.
Trigger
The escalating U‑boat threat and bomber losses in 1941‑1942 forced leaders to seek new approaches. Patrick Blackett, a physicist, formed a small
operations research (OR) unit
 to apply statistical analysis to military operations. The success of early OR experiments, such as optimising anti‑aircraft gunnery, convinced senior commanders to embrace the idea.
Intervention design
Blackett assembled
interdisciplinary teams
 of mathematicians, physicists and military officers (dubbed “Blackett’s Circus”). These analysts were embedded with operational units, rode along on missions and had direct access to commanders. They were authorised to question doctrine, conduct experiments and recommend changes. Governance was minimal; teams reported directly to theatre commanders, bypassing layers of staff. The British government provided top cover so line officers would take the analysts seriously.
Execution mechanics
OR teams operated in rapid cycles aligned to operational needs. In anti‑submarine warfare, they collected data from depth‑charge attacks and quickly found that charges were exploding at depths where no submarines were present; they recommended shallower settings and concentrating charges. They also analysed convoy sizes and discovered that losses were essentially independent of convoy size, leading them to advocate larger convoys to reduce escort requirements. Recommendations were delivered as simple memos or briefings and implemented within weeks. Analysts built credibility by going into the field and demonstrating quick wins.
Outcomes & impact
The OR interventions significantly reduced shipping losses and bomber casualties. Adjusting depth‑charge settings and escort tactics increased U‑boat kill rates, while larger convoys improved overall survivability. After the war, operations research became a recognised discipline; militaries and corporations established permanent OR units to apply data analysis to complex problems. The OR approach also influenced industries such as manufacturing and logistics.
Lessons & relevance
Inject analytical expertise
 – small teams of scientists paired with domain experts can reveal hidden patterns and optimise operations. Wildfire should include data scientists and AI specialists alongside engineers to uncover insights.
Top‑cover to question doctrine
 – OR teams succeeded because senior commanders protected them from organisational pushback. Wildfire leaders must provide similar authority for teams to challenge existing processes.
Rapid experimentation
 – OR teams tested ideas quickly in the field and iterated based on real data. Wildfire should prioritise pilot experiments and measure impact rather than debating theory.
Credibility through immersion
 – analysts earned trust by joining missions and speaking the operators’ language. AI engineers in Wildfire should embed with users to understand their needs and build rapport.
Palantir Forward‑Deployed Engineer Model (2010s)
Setting & constraints
Government agencies and large industrial firms often purchase software through multi‑year contracts that deliver slowly and rarely meet user needs. Data is spread across legacy systems and security rules restrict access. Operators have critical problems but limited technical expertise and distrust of vendors. Palantir’s clients, such as the U.S. Army and major banks, faced urgent requirements to integrate disparate data and generate actionable insights.
Trigger
Acute mission failures pushed organisations to try a different model. In Afghanistan around 2010, units needed better tools to identify improvised explosive device networks; the Army’s existing system (DCGS) was ineffective. Commanders started purchasing Palantir software under discretionary funding because it worked off‑the‑shelf and came with embedded engineers. Similarly, banks confronting fraud incidents sought rapid solutions. The urgency of warfare or financial risk triggered adoption of Palantir’s forward‑deployed approach.
Intervention design
Palantir provided a
product plus people
 model. It deployed small teams of
forward‑deployed engineers (FDEs)
 to work on‑site with users. These engineers had full‑stack skills and were empowered to configure the Palantir platform, ingest data and build custom workflows. Contracts were often outcome‑based: pilot projects delivered working solutions in 8–12 weeks, with the expectation of scaling if they proved value. FDEs reported to a senior sponsor rather than local IT, allowing them to cut through bureaucracy. Access to data and systems was negotiated up front to enable rapid integration.
Execution mechanics
Embedded FDEs worked side‑by‑side with analysts, soldiers or investigators. They began by integrating existing databases into Palantir’s platform, often within days. They then iteratively built analytic tools: for instance, network graphs to identify insurgent leaders or anomaly detectors for financial fraud. Users provided continuous feedback; engineers iterated weekly, adjusting workflows and visualisations. Outcomes were measured in mission terms (e.g., reduced IED attacks, faster investigations). Once the capability proved useful, contracts expanded and additional FDEs deployed.
Outcomes & impact
Clients reported rapid improvements. In Afghanistan, Palantir’s tools helped uncover bomb‑making networks, leading to fewer attacks. The program known as Project Maven delivered an AI video‑analysis capability in less than six months using embedded vendor teams. In industrial settings, Palantir’s platform improved equipment reliability and saved hundreds of millions of dollars in downtime. The forward‑deployed model influenced the creation of internal digital service units in government and industry, proving that close collaboration between domain experts and technologists accelerates value delivery.
Lessons & relevance
Embed technologists with users
 – FDEs did not build software in isolation; they lived with the problem and earned users’ trust. Wildfire’s AI engineers should be embedded within business units, not in a central ivory tower.
Outcome‑aligned contracts
 – pilot projects delivered a minimum viable capability quickly and were extended only if they demonstrated value. Wildfire should favour milestone‑based contracts with vendors to align incentives.
Product + people
 – technology alone is insufficient; the expertise to configure and apply it in context matters. Wildfire should ensure teams include both tool builders and domain experts.
Risk of dependency
 – some clients became reliant on Palantir. Wildfire must build internal capability to avoid vendor lock‑in.
UK Government Digital Service (2011–2015)
Setting & constraints
Before 2011, UK government digital services were fragmented: each department ran its own website through large outsourcing contracts, resulting in poor user experience and high costs. Digital talent was largely external, procurement cycles were lengthy and there were thousands of disconnected sites.
Trigger
In 2010, a review by Martha Lane Fox recommended a radical overhaul of government digital services. The new coalition government wanted efficiency savings and better citizen experiences. Minister Francis Maude and digital director Mike Bracken championed the creation of a
Government Digital Service (GDS)
 to consolidate websites and redesign transactions before the 2015 election.
Intervention design
GDS was set up as a
startup‑like unit
 within the Cabinet Office, staffed by about 30 people initially and later several hundred. It had authority to build a single GOV.UK website and enforce digital standards across government. GDS attracted talent from industry and created a culture distinct from the traditional civil service: open offices, MacBooks and agile methods. Political backing allowed GDS to mandate that no new website launch without its approval. They wrote
service design principles
 and a
Service Manual
 that all new digital services had to follow.
Execution mechanics
GDS delivered a
beta of GOV.UK in ten months
 and migrated hundreds of departmental sites onto it. Teams worked in two‑week sprints, launched public betas to solicit feedback and iterated quickly. GDS targeted 25 “exemplar” services and redesigned them one by one, demonstrating what good looked like. They built a
Performance Platform
 that displayed real‑time service metrics to drive accountability. To spread skills, GDS ran a
Digital Academy
 training program and embedded staff in departments to seed new digital units.
Outcomes & impact
GOV.UK won the
Design of the Year
 award in 2013 and dramatically simplified access to government services. The consolidation of websites and adoption of common platforms delivered an estimated
£1.7 billion in annual savings
 for taxpayers. User satisfaction improved; for example, the new voter registration service built in six weeks handled millions of registrations and was credited with increased youth turnout. GDS’s model inspired digital units worldwide (including the U.S. Digital Service). Its momentum slowed after 2015, but core platforms like GOV.UK, Notify and Pay remain in active use.
Lessons & relevance
Central authority with standards
 – GDS could mandate compliance through spending controls, ensuring adoption. Wildfire should secure authority to set standards and approve technology choices to avoid fragmentation.
User‑first design
 – starting with user needs rather than policy requirements led to simpler services. Wildfire should centre AI solutions on end‑user problems rather than abstract capabilities.
Talent and culture
 – by importing digital talent and creating a startup culture, GDS changed how government worked. Wildfire must attract top AI talent and provide an environment where they can thrive.
Quick wins build legitimacy
 – delivering GOV.UK quickly and winning awards gave GDS credibility to push deeper reforms. Wildfire should target visible, high‑impact wins early in each sprint.
WWII “Operations Research” (1942‑1945) – see
Operations Research “Blackett’s Circus”
 above
The original case library lists a separate entry for operations research, which has been integrated into the “Blackett’s Circus” case above.
Summary of cross‑case patterns
Across these diverse cases – from fighter jets and healthcare websites to banking and special operations – common principles emerge:
Executive sponsorship and air cover:
 every successful transformation had a senior leader willing to bypass bureaucracy and protect the team. Kelly Johnson reported directly to Lockheed’s president; the HealthCare.gov tech surge had White House backing; GE’s Immelt championed FastWorks; Air Force generals shielded Kessel Run; ING’s board reorganised the bank; JSOC’s McChrystal tore down silos. Without such cover, tiger teams get bogged down.
Small, cross‑functional, protected teams:
 whether the Dirty Dozen, an eight‑person tech surge or a 350‑squad reorg, teams were sized for speed and given a single mission. They combined diverse skills – engineering, operations, risk, UX, data science – and were relieved of other duties.
Time‑boxed sprints and iterative delivery:
 all cases delivered a working prototype or first release in weeks or months. Skunk Works built a jet in 143 days; Kessel Run delivered Jigsaw in 124 days; IBM’s PC was developed in a year; GDS launched GOV.UK beta in 10 months. Rapid feedback from users guided subsequent iterations.
User‑centric, secure experimentation:
 teams embedded with users and accessed real data. Kessel Run developers sat with warfighters, Palantir engineers sat with analysts, OR scientists flew on bomber missions, and GDS conducted extensive user research. Security and compliance were addressed early rather than bolted on later.
Hybrid expertise and capability transfer:
 successful initiatives paired internal domain experts with external specialists (Lean coaches, Silicon Valley engineers, Toyota lean masters). They invested in training and documentation to ensure that knowledge spread beyond the initial team.
Outcome‑oriented contracts and metrics:
 rather than paying for time and materials, many projects tied success to measurable impact. Clear metrics aligned stakeholders and justified continued investment.
Durability through institutionalisation:
 the most enduring transformations created permanent structures (Skunk Works division, U.S. Digital Service, GDS standards, Kessel Run program). They codified their methods in playbooks, trained new cohorts and built communities of practice. Conversely, initiatives that relied solely on individual champions risked fading when leaders departed.
These patterns form the backbone of the
Wildfire playbook
. By protecting small, empowered teams; iterating quickly with users; measuring outcomes; and embedding new capabilities into the organisation, Sierra Nevada Corporation can achieve rapid, durable transformation.
[1] GE embraces spirit of entrepreneurship
 How GE Implemented FastWorks to Act More Like a Startup - NOBL
  HealthCare.Gov’s Death-Defying 2013 Launch: Implications for Government-Led Payment Reform - 4sight Health
   IBM Personal Computer – Retro Viator
 ING’s agile transformation | McKinsey & Company
  ING Transformation – Adaptors or Innovators? – ODLENS
 McChrystal: Focus on Empowering Frontline Decision-Makers
  Software Wins Modern Wars: What the Air Force Learned from Doing the Kessel Run - Modern War Institute
 The Skunk Works® Legacy | Lockheed Martin
  The Rules Of Successful Skunk Works Projects - Fast Company
  How NUMMI Changed Its Culture - Lean Enterprise Institute
  BLACKETT'S WAR - NSL Archive
 The Palantirization of everything | Andreessen Horowitz