Leidos: Systems Engineering at the Scale of National Infrastructure

Leidos is not a product company. It doesn’t ship a device in a box or maintain a discrete hardware platform across decades. What it does is arguably harder to engineer: it integrates the work of dozens of subcontractors, government-furnished equipment vendors, legacy systems, and new development efforts into coherent, functioning systems — on programs where failure is measured in national security terms, not quarterly revenue.

With approximately $15.4B in annual revenue and operations spanning defense, intelligence, civil infrastructure, and health IT, Leidos sits in a category of company that systems engineering literature rarely addresses directly. Most SE frameworks were designed for product developers. Leidos applies those frameworks to a fundamentally different problem: making other organizations’ outputs interoperate, at scale, under government oversight, on fixed-price schedules that were bid before the requirements were stable.

Understanding how Leidos does systems engineering — where it works well, where it strains, and how it develops the human talent to execute it — is a useful lens on systems engineering practice in the real world.

The Integration Problem Is Structurally Different

When a product company applies systems engineering, the primary challenge is decomposing a set of stakeholder needs into a physical architecture the company controls. The company owns the design authority. It chooses the suppliers, defines the interfaces, and can change them.

Leidos, on many of its most significant programs, does not have that authority in the same form. Its customers — the Department of Defense, the TSA, intelligence community agencies, HHS — often bring pre-existing government-furnished equipment (GFE), legacy systems that cannot be replaced, regulatory constraints that function as hard requirements, and multiple other prime contractors or government-owned labs working in adjacent lanes. The interface management problem isn’t internal. It’s external, political, and evolving throughout the program lifecycle.

This changes the nature of systems engineering work. On a program like the Next-Generation Identification system or a large-scale transportation security integration effort, the SE team’s primary function isn’t architecting a clean design — it’s maintaining a coherent model of what has been agreed, what is still open, where interfaces are owned, and what the downstream consequences of a change to any one node actually are. Requirements don’t just come from a single customer; they come from CONOPS documents, interface control documents owned by other primes, regulatory agencies, and informal agreements that never made it into a formal baseline.

That is a data management problem as much as an engineering problem. And most large integrators, including Leidos, have historically managed it the way the industry has always managed it: with documents.

NISC3 and the Challenge of Enterprise-Scale Integration

The NISC3 — the Navy’s Next-Generation Information Technology Services Contract — is a representative example of the integration challenge at this scale. The program is not, at its core, a technology development effort. It is an enterprise IT modernization program: consolidating and replacing aging Navy IT infrastructure across a distributed, classified environment with modern cloud, cybersecurity, and managed services capabilities.

The systems engineering challenge on a program like this is requirements volatility compounded by organizational complexity. The Navy as a customer is not monolithic. Requirements emerge from N6 (the Deputy Chief of Naval Operations for Information Warfare), from fleet users, from program offices managing adjacent systems, and from cybersecurity directives that arrive mid-program and carry mandatory compliance timelines. A change to a security baseline can invalidate interface agreements with other systems that took months to negotiate.

For Leidos, managing this means maintaining traceability not just within its own architecture but across the boundary of its own control. Which requirements are derived from government-directed policy? Which are allocated to subcontractors whose change management processes are not synchronized with Leidos’s own? Where an interface is shared between a Leidos-delivered component and a government-owned legacy system, who owns the change authority when a requirement shifts?

These are not hypothetical questions. They are operational realities that SE teams on these programs navigate every week.

TSA Checkpoint Modernization: Requirements at the Intersection of Policy and Technology

The TSA’s checkpoint modernization programs present a different flavor of the same structural problem. Physical checkpoint systems involve hardware (screening equipment, lanes, sensors), software (image processing, threat detection algorithms, access control), network infrastructure, and human workflow — all of which must satisfy TSA operational requirements, FAA airspace security directives, privacy regulations, and accessibility law simultaneously.

For a system integrator in this environment, requirements don’t exist in a clean hierarchy. An Americans with Disabilities Act compliance requirement from the Department of Justice can interact with a throughput requirement from TSA operations, which interacts with a detection accuracy specification from TSA’s security laboratory, which interacts with a physical lane geometry constraint from the airport operator who isn’t party to the prime contract at all.

This is what practicing systems engineers at large integrators spend most of their time on: not elegant architecture, but the unglamorous work of maintaining a defensible baseline in conditions designed to undermine it. The skills required are part technical, part contractual, part organizational. You need to know what a well-formed requirement looks like, but you also need to know what change authority to invoke when one is wrong, and how to get the right people in the room before the schedule impact becomes unrecoverable.

Developing SE Talent Across a Distributed Workforce

Leidos has roughly 47,000 employees. A significant fraction of those are, in some functional sense, doing systems engineering work — but not all of them carry that title, and not all of them are trained against a common SE framework.

This is an underappreciated challenge in large government services firms. Product companies can build an SE center of excellence, standardize a toolchain, and enforce a methodology across a relatively bounded population. Leidos’s SE workforce is distributed across programs that started at different times, were bid under different process standards, use different toolchains, and are physically separated across dozens of sites and classification levels.

The response to this challenge, at Leidos and at peer firms, has involved a mix of internal SE communities of practice, competency frameworks, and certification requirements aligned to INCOSE standards. But the practical effectiveness of these efforts varies. On high-profile programs with strong engineering leadership, SE discipline tends to hold. On lower-margin, time-pressured programs, it compresses — requirements get managed in spreadsheets, traceability gets maintained in static documents, and the interface control discipline that was specified in the program’s SE Management Plan gets honored in name more than in practice.

This is not a failure unique to Leidos. It is the structural tension in any large integrator: the corporate process says one thing, and the program’s earned value pressure says another. The firms that resolve this tension most effectively are usually those where SE leadership has both technical credibility and the organizational authority to enforce standards even when a program manager is trying to cut corners to hit a milestone.

The Toolchain Reality

A frank assessment of systems engineering toolchain practice at large government integrators in 2026 looks something like this: IBM DOORS remains pervasive, particularly on older programs and in defense environments where the government customer mandates specific tools or data formats. DOORS Next has made inroads where programs have invested in modernization. Polarion and Codebeamer appear on development-heavy programs, particularly in automotive-adjacent or embedded systems work. Jama Connect shows up on newer programs where teams have more latitude to choose their stack.

What most of these tools share, in the context of large-scale integration work, is that they were designed to manage requirements within an organization’s control. They handle traceability well when all the requirements live in the same database. They handle it less well when requirements span documents, systems, and organizational boundaries that don’t share a data model.

This is where newer, AI-native approaches to requirements management are beginning to matter. Tools like Flow Engineering, built specifically for connected traceability and AI-assisted analysis across complex system models, represent a different architectural assumption: that the requirements graph is a living artifact, not a document frozen at CDR. For a firm like Leidos, where the practical problem is maintaining coherence across a requirements landscape that is constantly disturbed by external forces, the ability to propagate impact analysis across a graph model — and to use AI to surface conflicts, orphaned requirements, and stale interface assumptions — is not a feature; it’s an answer to a structural problem.

The adoption curve in large government contracting is slow. Tool changes require program office approval, sometimes customer concurrence, and always a training and transition cost. But the firms that begin standardizing on graph-based, AI-assisted SE tooling at the enterprise level now will carry a real advantage as programs grow more complex and the cost of requirements failures continues to scale.

An Honest Assessment

Leidos does systems engineering well enough to win and execute some of the most complex government programs in the world. That is not a small claim. The NISC3, the Air Force’s AFNCR IT services, the Transportation Security Administration’s modernization work — these are programs with real technical risk, real organizational complexity, and real consequences for failure.

What Leidos, like its peers, struggles with is the gap between how SE is supposed to work on these programs and how it actually works under schedule and margin pressure. The interface management discipline that distinguishes good integration from bad integration is exactly the kind of work that gets deferred when a program is behind. And in a distributed workforce, enforcing that discipline requires more than a policy — it requires tooling that makes the right behavior easier than the wrong behavior, and leadership that treats requirements integrity as a program health indicator rather than a documentation burden.

The companies that close that gap — that make rigorous, connected, AI-assisted requirements management the default rather than the exception on large integration programs — will outperform on schedule, on rework cost, and on the customer trust that drives re-compete wins. Leidos has the scale, the program portfolio, and the engineering depth to be a leader in that transition. Whether it moves fast enough is an execution question, not a capability question.