The Skunk Works Imperative: Why the Best Innovation Still Happens Outside the Building

Every large organisation eventually produces the same innovation killer. It doesn't arrive as a policy or a memo. It arrives as a meeting. Then another meeting to prepare for the meeting. Then a review process for the output of the meeting. And somewhere in that accumulated weight of coordination, the thing that was supposed to be built quietly stops being possible.

The frustrating part is that the people inside these organisations know this. They've watched promising initiatives die under committee review. They've seen urgent problems routed through approval chains until the urgency evaporated. They know the machine is too slow. And yet the machine persists — because the same organisational immune system that kills innovation also provides the stability, the compliance, the procurement infrastructure, and the risk management that a large enterprise genuinely needs to function.

The question isn't whether large organisations should be more like startups. That's a category error. The question is whether they can deliberately manufacture the conditions that make fast, excellent work possible — and protect those conditions from the organisation's natural tendency to absorb and normalise them.

The answer is yes. It's been demonstrated. And it started with a circus tent next to a plastics factory in 1943.

Kelly Johnson's Uncomfortable Lesson

In June 1943, the US Army's Air Tactical Service Command met with Lockheed to express its urgent need for a jet fighter to counter a growing German jet threat. One month later, Kelly Johnson and his hand-picked team delivered the XP-80 proposal. They designed and built it in only 143 days — seven fewer than required. Lockheed Martin

What made this possible wasn't technology or budget. It was organisational design. Johnson challenged the bureaucratic system that stifled innovation and hindered progress. His philosophy is spelled out in his 14 Rules and Practices. Lockheed Martin The core of those rules, distilled: reduce the bureaucracy to almost zero, keep the team ruthlessly small, and only take on work where there is enough mutual trust to operate with a minimum of process. Goodscienceproject

Rule three is characteristically blunt: the number of people having any connection with the project must be restricted in an almost vicious manner. Wikipedia Not reduced. Not rationalised. Restricted in an almost vicious manner. Johnson understood that every additional person with a connection to a project — however senior, however well-intentioned — added a coordination cost and a veto opportunity. The team's size wasn't just an efficiency question. It was a governance question.

What's striking about the Skunk Works story is how rarely it has been replicated — despite being entirely public. Kelly Johnson himself noted, with some incredulity, that the principles had been provided many times, and very seldom had the formula been followed. The key management principles that helped Skunk Works thrive are simply non-starters in most bureaucracies. Goodscienceproject

The reason is obvious once you see it. The Skunk Works model requires the parent organisation to voluntarily give up oversight, reporting, and control over a meaningful piece of work. That is precisely what most large organisations cannot bring themselves to do — not because the leaders are foolish, but because the incentive system rewards accountability and visibility, not the deliberate creation of protected blind spots.

Palantir's Modern Translation

Sixty years later, Palantir built something structurally similar in the commercial world — and for largely the same reasons.

Palantir is neither a traditional SaaS company nor a services-led platform business. Its growth, economics, and defensibility only make sense once you understand the role of its Forward Deployed Engineers — not as a revenue-generating services arm, but as the company's primary product discovery and product-formation mechanism. Medium

The FDE model is Skunk Works logic applied to customer deployment. As Bob McGrew, early Palantir executive and former Chief Research Officer at OpenAI, describes it, the FDE model is effectively "doing things that don't scale at scale" — an acknowledgment that initial, high-touch efforts are essential for profound product discovery. remio Small teams. Direct accountability. Protected from the main machine. Measured on outcomes, not process compliance.

Palantir deploys its own people, on its own stack, directly into production. This blend — a product-first core combined with embedded, high-calibre field teams — allows Palantir to solve problems faster, prove value earlier, and create an adoption curve most competitors can't match. Everest Group

The model looks inefficient from the outside. Each FDE engagement is expensive, bespoke, and impossible to replicate at volume. But that's a misreading of what the model actually produces. Each deployment is simultaneously a customer outcome and a product discovery exercise — a field test that generates the kind of institutional understanding of real-world constraints that no roadmap session or user interview can replicate. Early Gotham deployments were deeply bespoke, built to answer highly specific intelligence questions. Over time, engineers observed the same structural problems recurring across customers — and rather than solving them repeatedly, Palantir encoded them as platform primitives: ontologies, object models, permissioning systems, workflow engines. Medium The non-scalable part was the research. The platform was the output.

The Knowledge Management Problem Nobody Has Solved

There is a hidden variable in the startup-versus-enterprise innovation dynamic that the Skunk Works and FDE models both address implicitly: the speed at which people can find what they need to know.

In a startup, knowledge flows fast because the organisation is small enough that you know who to ask. The person with the answer is two Slack messages away. The context that makes the answer meaningful is understood by everyone in the room. Speed of knowledge retrieval is essentially free.

In a large enterprise, knowledge flow is one of the most expensive problems in the business — and one of the least visible. The information you need exists somewhere in the organisation, almost certainly. But it's buried in a SharePoint folder from 2019, or locked in the head of someone in a different country, or distributed across four systems that don't talk to each other. By the time you've found the right person, scheduled the right meeting, and established the right context, you've spent two days on a question that would have taken ten minutes in a ten-person company.

This is one of the structural reasons that Skunk Works-style units work inside enterprises: they recreate startup-grade knowledge flow by keeping the team small enough that everyone knows who to ask. Palantir's FDE model does the same thing by embedding a small team directly into the customer environment, where the knowledge is.

AI knowledge management tools are starting to address the enterprise version of this problem — but the early experience suggests that technology alone isn't the constraint. The same logic explains what Satya Nadella, CEO of Microsoft, attempted with his March 2026 Copilot reorganisation. After years of building AI capabilities across separate consumer and commercial teams — each with their own roadmap, their own leadership, their own internal accountability structure — Microsoft found itself with a fragmented portfolio where organisational boundaries no longer reflected system architecture or product shape. Samexpert The response was structural: collapse the separate units, establish single accountable leadership reporting directly to Nadella, and protect that unit from the committee structure that had formed around it. The stated goal was to move from "a collection of great products to a truly integrated system" — simpler and more powerful for customers. Thurrott

This is a large enterprise attempting to manufacture Skunk Works conditions from the inside. Not a circus tent — a deliberate reorganisation designed to recreate the three things the original Skunk Works had: a small, accountable team, direct reporting to the top, and protection from the coordination overhead that had accumulated around the work. Whether it succeeds is a separate question. That Nadella felt it necessary is itself the data point. Even at the scale of one of the most valuable companies in the world, the answer to "how do we move faster and build something coherent" is structurally the same as Kelly Johnson's answer in 1943.

The Three Conditions Worth Manufacturing

The Skunk Works story, Palantir's FDE model, and Microsoft's reorganisation all point at the same set of conditions that separate organisations that can move quickly from those that can't. I've seen versions of this pattern in my own experience — the moments where a team suddenly started producing results that felt disproportionate to their size. Almost without exception, the explanation was the same three things.

Protected team size. The unit doing the work needs to be small enough that coordination is cheap and accountability is personal. In practice, this means resisting the organisational reflex to add people when a project feels important. Importance is usually used as a justification for expansion — more stakeholders, more oversight, more representation. But the projects that move fastest are almost always the ones where someone had the conviction to keep the team tight and absorb the political cost of the exclusions that required. A team of seven can make a call in thirty minutes that a team of forty would spend three weeks aligning on. That's not a small efficiency gain. It compounds across every decision the team makes.

Direct accountability to the outcome, not the process. Skunk Works engineers were measured on whether the aircraft flew, not whether the documentation was complete. Palantir FDEs are measured on customer outcomes, not activity metrics. The moment a team's primary accountability shifts from the outcome to the process of pursuing it, something changes in how people make decisions — they start optimising for what gets reviewed rather than what gets built. Small teams with outcome accountability tend to self-organise around what matters. Large teams with process accountability tend to organise around what's visible.

Deliberate protection from the parent organisation. This is the hardest one, and the one most often neglected. Skunk Works was physically separated from the rest of Lockheed. The goal was not only secrecy but to reduce distractions. Fly a jet fighter The parent organisation's natural instinct — to check in, to review, to ensure alignment, to add the person who "really should be in the room" — is precisely what the protected unit needs to be shielded from. Not permanently. Just long enough to produce something worth reviewing. In my experience, the teams that performed beyond expectation were almost always the ones where someone senior enough had made an active decision to run interference on their behalf — buying them the space to build before the organisation could form an opinion about what they were building.

The question worth sitting with isn't whether these conditions are desirable. Everyone who has worked in a large organisation knows they are. The question is who in your company has enough authority, enough conviction, and enough willingness to absorb the political cost of creating and protecting a unit that operates outside the normal machine.

Because that person — not the technology, not the strategy, not the innovation budget — is the actual constraint.

Next: Blog 5 — Category creation is a trap. Reframe instead.

If you haven't read Blog 3 yet — the PMM turf war is the reason most Skunk Works-style units eventually get reabsorbed. The narrative about what they're building gets contested before the building is done.