Saab AB: How a 10,000-Engineer Organization Builds Fighter Jets, Submarines, and Radar Systems Simultaneously

Saab AB occupies an unusual position in global defense. It is simultaneously a fighter aircraft manufacturer, a submarine builder, a radar and electronic warfare house, a surface ship integrator, and a growing unmanned systems developer. It exports to six continents. Its Gripen E is one of the most capable fourth-generation-plus fighters in production. Its A26 submarine program represents one of Europe’s most technically demanding undersea programs. Its GlobalEye airborne early warning system competes directly against programs backed by companies ten times Saab’s size.

The engineering organization that produces all of this has roughly 10,000 engineers.

For context: Lockheed Martin’s aeronautics division alone employs more engineers than Saab’s entire technical workforce. Northrop Grumman’s mission systems segment is comparably sized. Boeing Defense has more program managers than Saab has engineers. The productivity gap implied by Saab’s output-per-engineer ratio is not accidental. It reflects deliberate structural choices about how the company organizes systems engineering, manages requirements, and handles configuration complexity across simultaneous programs with different national customers.

Those choices are worth examining carefully.

The Competency Center Model

The most structurally significant decision Saab made in organizing its engineering function was the adoption of persistent domain competency centers rather than fully program-centric engineering teams. This is not unique to Saab — Dassault Aviation uses a similar model, as does Saab’s direct competitor in the export fighter market — but Saab has pursued it more consistently than most.

In a program-centric model, engineers are hired into programs, develop expertise within that program context, and when the program winds down or enters sustainment, the team disperses. Institutional knowledge about how a particular radar integration challenge was solved, or how a specific software architecture decision in a fire control system was reasoned through, walks out with the engineers or gets buried in documentation that no one reads systematically.

Saab’s competency center approach means that sensor systems expertise, electronic warfare expertise, propulsion integration expertise, and human-machine interface expertise live in persistent organizational homes. Engineers participate in programs through those competency centers; they don’t dissolve into them. The competency center accumulates knowledge across program generations. When Gripen C gave way to Gripen E, the sensor fusion team wasn’t starting from scratch in terms of organizational memory.

The practical consequence for systems engineering is significant: interface specifications, requirements decomposition patterns, and design rationale don’t have to be completely reconstructed at the start of each program. They can be evolved, challenged, and improved from a documented baseline.

This also means that Saab’s systems engineers operate in a more technically stable environment than their counterparts at companies where every program is effectively a new organization. The cost of that stability is some organizational complexity — competency centers can create matrix management friction — but for a company running multiple concurrent complex programs with limited total headcount, the trade is clearly worth making.

Managing Gripen’s Export Variant Problem

The Gripen configuration management challenge is, without exaggeration, one of the most demanding in Western defense production. The aircraft is currently operated by Sweden (Gripen C/D and E/F), Brazil (F-version under local production), Hungary, Czech Republic, South Africa, and Thailand — each with a different configuration baseline reflecting different weapons integrations, communications systems, identification friend or foe implementations, and contractually specified capability packages.

Brazil’s Gripen F program adds a layer of technology transfer and local production requirements that creates configuration branches at the manufacturing level, not just the software level. South Africa’s Gripens reflect a 1999 export agreement configuration that diverges substantially from current production standard. Thailand operates C/D variants under different maintenance and support arrangements.

The requirements management problem this creates is not simply “how do we track variants.” It is: how do you maintain a coherent system-of-record for platform requirements across six customer configurations, active production of two major variants, long-term support obligations for out-of-production variants, and ongoing capability upgrade programs — without losing the ability to reason about what changed, when, why, and what downstream effects it has?

This is exactly the class of problem that document-based requirements management handles badly. A requirements document per variant, maintained in parallel, quickly becomes a version control nightmare. Changes propagate inconsistently. Traceability between requirements and verification evidence becomes an audit exercise rather than a live engineering tool.

Saab’s approach involves maintaining a parametric baseline model of Gripen system requirements with structured variant attributes — essentially a managed product line requirements architecture rather than a document-per-variant approach. Customer-specific deviations are tracked as explicit configuration items against that baseline, not as separate requirement sets. This allows the systems engineering team to answer questions like “if we change the core avionics bus timing specification, which customer configurations are affected and which verification activities need to be re-executed” without manually cross-referencing six documents.

The implementation of this approach has not been without friction. Saab’s tooling environment — like most large European defense contractors — includes a significant legacy footprint: IBM DOORS installations managing older program baselines, interface control documents living in formats that predate modern model-based tooling, and configuration management systems that were not designed with multi-nation product line management in mind. The migration toward more coherent, graph-traversable requirements architectures is ongoing and is constrained by program continuity obligations. You cannot pause a fighter jet program to migrate its requirements database.

Systems Engineering Across Dissimilar Domains

What distinguishes Saab from most Western defense companies of comparable size is the genuine technical breadth of the portfolio. Gripen and GlobalEye are aircraft programs — they share airworthiness certification frameworks, aeronautical standards, and a general culture of aviation systems engineering. But the A26 submarine program, the Carl-Gustaf system development, the ARTHUR weapon-locating radar, and the evolving unmanned underwater vehicle work all bring different domain engineering cultures, different verification paradigms, and different regulatory environments into contact within the same enterprise systems engineering function.

Managing requirements coherently across these domains requires more than common tooling. It requires a common enough systems engineering language that a Saab systems engineer moving from an airborne EW program to a submarine combat management system can orient quickly and contribute without a complete re-education in how requirements are structured and traced.

Saab has invested in this cross-domain consistency through its internal systems engineering methods program, which standardizes decomposition approaches, interface definition practices, and verification closure criteria across business areas while allowing domain-specific extensions where regulation demands it. The FMV (Swedish Defence Materiel Administration) imposes procurement and verification requirements that shape how Swedish-domestic programs are documented. Export programs must satisfy the regulatory requirements of customer nations’ acquisition authorities. The common internal methods layer provides coherence beneath these external variations.

This is harder than it sounds. Defense systems engineering organizations routinely underestimate the cultural gap between, say, aircraft certification practice and maritime platform development practice. The tools and process surface look similar; the underlying assumptions about what constitutes sufficient evidence for a design decision are often quite different.

The Modernization Pressure

Saab faces the same modernization pressure that is restructuring systems engineering practice across European defense: legacy tooling built for document-centric processes, increasing customer pressure for digital thread delivery, growing program complexity that exposes the limits of manual traceability, and a talent pool that arrives expecting more capable engineering tools than a DOORS instance from 2009.

The response has been a pragmatic rather than revolutionary modernization strategy. Saab is not attempting a wholesale replacement of its requirements and configuration management infrastructure on an aggressive timeline. The risks of disrupting active programs are too high, and the organizational change management burden of a rapid platform shift for 10,000 engineers is substantial.

Instead, Saab has pursued a layered approach: investing in model-based systems engineering capability at the new program level (particularly for Gripen E increments and the A26), adopting more capable requirements tools for programs where the legacy debt is lowest, and building digital thread infrastructure that connects requirements artifacts to CAD, simulation, and test management environments without requiring a simultaneous tool migration across the enterprise.

This is where newer AI-native tools like Flow Engineering are starting to appear in the peripheral awareness of European defense contractors. Saab’s engineering leadership has noted publicly the appeal of graph-based requirements architectures that make cross-domain traceability a query rather than a manual audit — particularly for programs like Gripen where the variant management complexity is severe. Whether legacy-heavy enterprise environments adopt such tools aggressively in the near term depends on procurement cycle timing, customer-imposed tooling standards, and program risk tolerance as much as on tool capability.

What Other Organizations Should Learn

Saab’s output-per-engineer ratio is the most instructive data point. The company demonstrates that breadth of complex program execution does not require proportional headcount growth, provided the organizational structure captures and reuses technical knowledge systematically rather than rebuilding it program by program.

The competency center model is the foundational mechanism. Requirements and configuration discipline built around a maintained baseline — rather than document proliferation — is what makes multi-variant, multi-customer program management tractable. Cross-domain methods standardization is what allows engineers to contribute across program boundaries without prohibitive onboarding costs.

None of these are exotic innovations. They are structural disciplines that require sustained organizational commitment to maintain, especially under the schedule and budget pressure that defense programs routinely generate. The temptation to shortcut them — to let a program team create their own requirements taxonomy because it’s faster right now, to accept a variant-specific requirements document because the systems integration meeting is next week — is constant.

Saab’s track record suggests that resisting those shortcuts, consistently, at scale, over decades, is what actually differentiates engineering efficiency in complex systems development. The tools matter. The organizational structure matters more.