The Lost Art of Developmental Engineering

By Andrew Park | 2026-01-21

How the Air Force Divested Its Weapons Innovation Capability

Executive Summary

The Air Force faces a persistent acquisition challenge: major programs routinely fail during the transition from development to operations, despite meeting technical specifications. This article documents the root cause: the 1992 elimination of a specialized career field that once owned integrated product risk across the full acquisition lifecycle. Without this capability, programs can't successfully navigate the transition between laboratory demonstration and operational fielding. The Secretary of the Air Force faces a decision: commit to a generational timeline to rebuild this capability while implementing near-term mitigations, or continue experiencing similar failures every 5 to 10 years. 

These failures persist despite decades of increased oversight and acquisition reform. The pattern reveals a structural gap: no single role owns integrated product risk as capabilities transition from laboratory to operational use.

While this analysis draws primarily from Air Force experience, the underlying failure mode isn't service specific. The Navy and Army face similar challenges as complex capabilities move from research and development into fleet and fielded use, particularly where no single role is accountable for owning integrated product risk across mission, technical, operational, and sustainment boundaries. 

In the early 1990s, the Air Force divested the career development system that produced Developmental Engineers as a profession. While related roles and titles remained, the institutional capability to deliberately develop professionals responsible for owning integrated product risk didn't. That loss fundamentally changed how risk is managed as capabilities moved from innovation into operational reality.

As transition approaches, multiple forms of risk converge simultaneously, including mission value, program viability, operational usability, technical feasibility, and lifecycle sustainability. These risks are touched by many organizations, but fully owned by none. No single role is accountable for resolving their interactions before commitment, which makes late stage integration failure predictable rather than exceptional.

Developmental Engineering existed to counteract this structural condition. When that professional capability disappeared, the failure mode became predictable. Rebuilding this capability will require sustained long term institutional commitment. Short term mitigations may reduce harm, but they can't fully substitute for deliberate professional development. The central question for Department leadership is whether the cost of continued delays and valley of death failures exceeds the cost of rebuilding this capability.

This capability gap directly undermines the Department's reoptimization for Great Power Competition. Without professionals who can rapidly eliminate integrated product risk, the Air Force can't execute the accelerated acquisition timelines required to pace China.

Introduction

The Air Force is experiencing a predictable pattern of late-stage integration failures across its most critical weapon systems. The majority of major defense programs consistently encounter cost overruns and schedule delays not because of inadequate technology or insufficient oversight, but because no single role is accountable for owning integrated product risk as capabilities transition from research to operations. This pattern has a specific cause: In 1992, the Air Force eliminated the career development system that produced professionals trained to own this integration challenge.

Today, as the Air Force struggles with chronic acquisition delays and cost overruns, the consequences can no longer be dismissed. The Sentinel ICBM program experienced 81% cost growth [2]. The F-35 Block 4 upgrade grew from $10.6 billion to $16.5 billion [3]. The new Air Force One is five years behind schedule and $1.7–2 billion over budget [4]. From 2012 to 2022, the Department recorded 24 Nunn-McCurdy breaches requiring Congressional notification [5]. Major defense acquisition programs now take almost 12 years to achieve even Initial Operational Capability [2]. These aren't isolated failures. They're the predictable outcome of a systemic capability gap that's gone unaddressed for three decades. 

Marc Ohmer, one of the last Reagan-era Developmental Engineers, provided me a unique perspective on what was lost and why it matters [1]. This article synthesizes these historical insights with broader analysis and recommendations for how Department of the Air Force leaders can move forward to address this capability gap.

A Note on Terminology

To avoid ambiguity, it's important to distinguish between the profession as it existed prior to 1992 and the modern career field that retains the same name. In this article, the term Reagan-era Developmental Engineer refers to officers developed under the pre-1992 system, which deliberately built broad, cross-domain expertise through decades of rotational assignments across operations, testing, depots, and acquisition. While a developmental engineer Air Force Specialty Code (AFSC) 62E still exists today, the career development model that produced this integrated capability doesn't. The distinction matters, because the argument that follows concerns the loss of that developmental system, not the disappearance of the job title.

The name survived. The profession didn't.

The absence of this capability isn't a reflection of individual engineer quality, but the predictable result of no longer developing engineers for integrated lifecycle ownership.

I. The Unique Role of Developmental Engineering

To understand what was lost in 1992, we must first understand what a Developmental Engineer actually did. Unlike traditional engineers who focus on design and technical specifications, or scientists who pursue knowledge discovery, Developmental Engineers occupied a unique space at the intersection of technology, mission requirements, and acquisition. Entering the 1990s, the Air Force was widely recognized as a premier technical acquisition enterprise, possessing a cadre of technical experts who were well respected by industry owing to their extensive experience with weapon system development [6].

The Developmental Engineer's role was to bridge the gap between emerging technology and military requirements, integrating all aspects of acquisition including contracts, finance, and organizational requirements to field operational weapon systems. This was fundamentally a weapon system integration role that required mastery across multiple domains simultaneously.

 As depicted in Figure 1, the breadth of knowledge required was staggering. A Developmental Engineer needed to understand not just products and technology, but people, organization, and process. They had to master law, doctrine, policy, training, and tactics, techniques, and procedures (TTPs). But knowledge alone wasn’t enough. An equally indispensable characteristic was the people skills to work effectively across radically different organizational cultures. Scientists think in terms of uncertainty and discovery. Operators think in terms of mission and tactics. Acquisition professionals think in terms of contracts and compliance. Senior leaders think in terms of strategy and resources. Each group has its own language, terminologies, priorities, driving philosophies, and decision making frameworks. Developmental Engineers had to understand not just what each community knew, but how they thought, what they valued, and how to build trust across these boundaries. This combination of technical breadth and cross cultural fluency is exceptionally rare because it requires both deep domain expertise and the interpersonal skills to navigate organizational politics, build coalitions, and translate between worldviews. They were the translators who could speak the language of scientists, operators, acquisition professionals, and senior leaders, and synthesize all of these perspectives into a coherent weapon system development plan that each community would accept and support. 

This role was particularly crucial for baseline changes, which were evolutionary improvements to existing weapon systems that incorporated new technology while adapting doctrine, concepts of operations, and organizational structures. It wasn't enough to simply integrate new technology; Developmental Engineers had to orchestrate changes across people, process, and technology simultaneously.

This required mastery across domains that are normally stovepiped, including operational units, developmental test, operational test, depots, and program offices. Depots are facilities where the Air Force repairs, overhauls, and upgrades weapon systems over their full service life, revealing long-term reliability, maintenance, and sustainment problems that don't appear during development or early testing.

The complexity of this role is what made it so valuable, and so expensive to develop. An engineering degree was merely the entry criteria, the starting point for a 20-year career pyramid designed to build the breadth and depth of expertise required. The Air Force forced Developmental Engineers to move every 3 years, rotating through assignments in depot operations, developmental test and evaluation, operational test and evaluation, operational squadrons, and program offices. Each assignment added another layer of understanding, another perspective, another set of relationships that would prove essential when orchestrating complex weapon system developments. 

A. Why Developmental Engineering Takes a Decade or More of Continuous Learning to Form

Developmental Engineering capability can’t be regenerated on short timelines because it isn’t primarily instructional. Over 21 years of implementing continuous learning programs for engineers, I have consistently observed that developing the integrative judgment required for complex systems work requires a decade or more of sustained, deliberate practice. This pattern aligns with research on expertise development, which shows that becoming an expert in complex domains has biological foundations [11]. Studies on skill acquisition demonstrate that intensive practice drives measurable structural changes in the brain, including myelination [12][13][14]. While these studies examined motor and musical skills rather than engineering, they provide evidence for the biological mechanisms underlying a general principle observed across many domains: expertise development requires extended time because the brain needs time to build the neural infrastructure that enables expert performance.

The defining value of Developmental Engineers was integrative judgment: the ability to recognize system-level risk patterns across technology, operations, acquisition, and sustainment before those risks converged into late-stage failure. That judgment doesn't emerge merely from tenure or accumulated years of experience. It emerges only from sustained, continuous learning driven by repeated exposure to the same classes of integration failure across multiple operational contexts. 

10 years of experience isn't the same as 10 years of continuous learning. Engineers can accumulate years on paper while repeatedly solving similar problems at the same level of difficulty. That kind of experience plateaus. Developmental Engineering judgment required uninterrupted learning where each assignment deliberately expanded perspective across labs, test environments, operational units, depots, and program offices without resetting the learning curve.

Figure 2 illustrates this distinction. The upward trajectory shows continuous learning across different system transitions, where each assignment builds on previous understanding without resetting. Four historical examples in the upper left illustrate this pattern. Each required long periods of deliberate, uninterrupted learning to develop the integrated judgment needed to eliminate system level risk.

As implied in the figure, early in a career, integration challenges appear novel. Interfaces, test failures, sustainment constraints, training burdens, and certification issues all seem program-specific. With continuous learning over time, these challenges recur in recognizable forms. Only after many cycles does an engineer reliably anticipate failure before it manifests.

This type of judgment develops through deep practice that physically rewires the brain through myelination. That biological process occurs slowly and establishes a hard lower bound on how quickly integrative judgment can form. Intelligence, motivation, and formal training can't bypass this constraint.

These timelines represent minimum requirements, not maximum limits [11]. My 21 years of experience developing engineering talent confirms that expert-level integrative judgment consistently requires approximately 10,000 hours of domain-specific practice (minimum 10 years at full-time commitment). This observation aligns with research on deliberate practice and neural development across various skill domains [11][12][13][14]. Some individuals may require longer to develop equivalent expertise depending on aptitude and opportunity quality. What remains constant is the biological constraint: the neural infrastructure enabling expert performance requires extended time to form. Intelligence, motivation, and formal training can improve the quality of practice, but they cannot bypass the myelination process that underlies skill consolidation.

Engineers with roughly 10 years of continuous learning can and often do produce impressive and innovative work. History demonstrates that clearly. What Developmental Engineering added was the ability to systematically eliminate integrated product risk at scale. That capability consistently appeared later in careers, after extended periods of uninterrupted learning across multiple system transitions and consequences.

Artificial intelligence can accelerate learning quality by improving feedback and exposing engineers to more examples. It can help people learn more vigorously. What it can't do is convert fragmented experience into continuous learning or compress the biological process by which judgment forms. AI can amplify long-term cultivation. It can't replace it or reduce it to a small fraction of the time.

For this reason, rebuilding Developmental Engineering capability requires generational timelines. The constraint isn't organizational will or acquisition policy. It's the pace at which human beings internalize complex systems behavior under operational consequence.

II. The 1992 Divestment: Keeping the Title, Losing the Capability

The end of the Cold War forced a reassessment of defense priorities and force structure. With the Soviet Union dissolved and major peer conflict viewed as unlikely, the Air Force came under intense pressure to reduce costs [6], [7]. Between 1989 and 1997, the officer corps was reduced by 29 percent, one of the largest drawdowns in service history [7].

The broader drawdown was severe. In 1989, more than 600,000 people worked in defense acquisition across the Department [1]. By 2026, that number had fallen to roughly 160,000, a 73 percent reduction. When an organization loses about 75 percent of its workforce, critical skills don’t gradually erode. They disappear.

Leadership faced a stark manpower tradeoff in the post Cold War era. The Air Force concluded it couldn’t afford to sustain both pilots and Developmental Engineers. Because the service’s identity centers on flying and fighting, and because pilots occupied senior leadership roles, pilot training was preserved. Developmental Engineering, the second most expensive career field and one that required roughly 20 years of deliberate investment to produce an elite practitioner, was eliminated.

What’s notable is what was eliminated versus what was retained. Officers can still be assigned to AFSC 62E positions today [9]. What disappeared was the system that created true Developmental Engineering capability. The 20 year career pyramid. Forced rotations every 3 years. Institutional investment in building breadth across operations, testing, depots, and acquisition. The Air Force kept the job title but dismantled the pipeline that produced the profession.

This wasn’t a leadership failure. The long term effects on acquisition capability weren’t foreseeable in 1992 and only emerged decades later through repeated integration failures. Leaders acted rationally with the information they had, but those choices compounded over time and now demand corrective action.

The result is analogous to a company retaining the title Senior Systems Architect while eliminating technical training, mentorship, and career progression. The label remains, but the capability doesn’t. Most Developmental Engineers trained under the earlier system were reassigned, retired, or left the service. The institutional knowledge and trust networks they carried largely left with them.

From 1970 through 1992, the Air Force operated a deliberate rotational system that reliably produced senior Developmental Engineers with cross domain authority. The elimination of this system in 1992 marks a clear inflection point. In the years that followed, late stage integration failures became increasingly common across major programs, from F 22 modernization delays to current Sentinel ICBM cost growth. While the 62E position remained, the profession that specialized in crossing valleys of death disappeared.

A. What Remains: The Current 62E Development Pipeline

To understand what was lost, it helps to look at what pre-1992 Developmental Engineers received versus today.

Pre-1992 Developmental Engineer Path

• A structured 20 year career pyramid

• Mandatory rotations roughly every 3 years

• Assignments spanning depots, developmental test, operational test, operational squadrons, and program offices

• An engineering degree used as entry criteria, not as the defining qualification

• Continuous immersion in the full weapon system lifecycle from concept through operational use

• Intentional development into weapon system integrators capable of aligning technology, mission needs, and acquisition

Current Developmental Engineer Path

• 3 weeks of Fundamentals of Acquisition Management training at Wright Patterson Air Force Base

• Ongoing Defense Acquisition University (DAU) coursework throughout the career

• Optional advanced degrees at the Air Force Institute of Technology, typically 1.5 to 2 years

• Predominantly CONUS (continental United States) based assignments

• Limited exposure to operational squadrons, deployed environments, and end to end weapon system lifecycles

• Common transition into 63A acquisition manager and program management roles

The pre 1992 system was built to accumulate integrated judgment over decades by forcing breadth, repetition, and accountability across every part of the system an engineer would later be expected to integrate. Operational reality, technical tradeoffs, acquisition constraints, and organizational behavior were learned through lived experience, not coursework.

Today’s model produces capable acquisition professionals and program managers. What it doesn’t produce anymore is the weapon system integrator which requires long horizon development and deep rotational exposure. No amount of short course training, even when paired with advanced degrees and DAU coursework, can replace decades of immersion across the full weapon system lifecycle.

B. The Fragmentation of the Developmental Engineering Mission

The elimination of the career development system was compounded by organizational changes that fragmented the Developmental Engineering mission itself. Understanding this sequence is critical to understanding why the capability was lost so completely.

In 1990, Air Force laboratories were merged with program offices in what were called Super Labs: Rome Lab, Eglin, Wright Lab, Phillips Lab, and Armstrong Lab. This structure kept developmental engineers embedded with acquisition programs, maintaining some connection between technology development and program execution.

However, in 1997, the Air Force consolidated these laboratories into the Air Force Research Laboratory (AFRL) as an independent organization reporting directly to Air Force Materiel Command. The intent was to give laboratories autonomy for long term research. But when AFRL was created, the develop and transition mission transferred with the laboratories.

This created a fundamental problem: the laboratories inherited a mission to transition technology into operational systems, but without the rotational career development system that built engineers capable of executing that mission. The laboratories increasingly focused on scientific research, a more straightforward mission with clearer metrics. The developmental engineering capability atrophied even as the organizational chart maintained positions with developmental engineer in the title.

The distinction between scientific research and developmental engineering matters for workforce development. A university graduate with a PhD in physics is 80% prepared to be an Air Force scientist on day one. The same can’t be said for developmental engineering, which requires operational experience, acquisition knowledge, and cross functional integration skills built over a decade or more. Scientists can contribute meaningfully to research programs within months of arrival. Their university education directly prepares them for scientific investigation.

Developmental Engineers, by contrast, require years of post commissioning development. The engineering degree is merely the entry credential, the starting point for a 10 to 20 year career pyramid designed to build the breadth required. From an organizational perspective, maintaining a science mission is more straightforward: recruit talented graduates, give them interesting research problems, measure their publications and patents, and maintain infrastructure for experiments. The requirements are clear, the timelines are often flexible, and the outputs are quantifiable.

Developmental engineering required something far more complex: a managed career system with forced rotations, deliberate exposure to operations, and sustained investment in individuals who wouldn’t reach peak capability for a decade or two. In an environment of severe budget pressure and personnel reductions, the choice to preserve the science mission while allowing the developmental engineering capability to atrophy was, in some sense, predictable. Science offered faster return on investment, clearer success metrics, and less organizational friction.

By the late 1990s, the Air Force had inadvertently created a system where no organization owned the complete problem. Research labs developed technology. Program offices managed contracts. Test organizations evaluated systems. Operational commands prepared to receive capabilities. But the integrating function, the role that understood how all these pieces converged into operational weapon systems, had been distributed across organizations without the career development pipeline to create professionals capable of spanning those boundaries.

III. Risk Management: Scientists vs Developmental Engineers

There’s a common belief that because scientists are brilliant, they should be well suited to produce operationally viable solutions. That belief misses a fundamental difference in how the two roles manage risk.

Scientists are trained to operate with open ended risk. Uncertainty is expected, timelines are flexible, and unexpected results are often valuable. The goal is knowledge creation, not operational certainty.

Developmental Engineers worked in the opposite direction. Their job was to drive risk toward zero because they were fielding weapon systems used in lethal operations. Uncertainty wasn’t explored. It was systematically eliminated until system behavior was predictable, bounded, and repeatable under operational conditions.

This difference matters. A scientist may welcome surprise. A Developmental Engineer must prevent it. That requires not just technical skill, but deep integration of operations, test, manufacturing, sustainment, and failure mode analysis. Both roles are critical, but they aren’t interchangeable, and treating them as such misunderstands why Developmental Engineering existed as a distinct profession.

A. Source Code Sustainment Risk: A Case Study

The distinction between research and operational objectives becomes especially visible in software development. This observation represents a core driver of the Valley of Death between labs and PEOs (i.e., Program Executive Offices, the organizations responsible for acquiring, fielding, and sustaining operational systems): source code sustainment risk.

My teams have had to take software written by scientists and turn it into operational systems that operators rely on in real missions today. That typically meant completely rewriting the code after carefully studying the underlying algorithms, reading books and papers, and walking through the logic with the scientist to verify we truly understood what the code was doing. A large amount of critical meaning usually lives outside the source code.

Scientist written code is usually created to demonstrate an idea or prove a result. It often looks complicated on the surface, but the behavior underneath is relatively simple and heavily dependent on assumptions, data conditions, and human judgment. The code works in the lab because someone is always nearby to notice problems and intervene.

Operational software is built for a very different purpose. It must behave correctly every time, even when inputs are messy, systems are partially down, or no one is watching. To do that, highly skilled software engineers must build structure into the code so important rules, limits, and behaviors are made explicit and consistently enforced. In operational environments, all safety nets disappear.

There’s a huge gap between code that works most of the time and code that operators will choose to trust because it never fails. My teams had to apply significant engineering rigor to meet that trust bar. Lives were in the balance. This wasn’t about elegance or best practices. It was about making sure the system behaved predictably under stress.

Department leaders shouldn’t expect scientists to possess these skills. They weren’t trained to produce operational, sustained software. Asking them to do so without support sets everyone up to fail. That gap is source code sustainment risk. When critical knowledge lives in people’s heads rather than in the software itself, the system becomes fragile the moment it leaves the lab.

This isn't to say scientists lack rigor. They possess immense rigor for discovery. But the rigor required for operational certification is a fundamentally different discipline that requires ensuring a system works when the creator is no longer in the room. A scientist may welcome surprise as data; a Developmental Engineer must prevent surprise to ensure safety and mission success.

This gap between research quality code and operational quality software is one specific manifestation of the broader problem Developmental Engineers were trained to solve. A scientist can produce brilliant algorithms. A Developmental Engineer ensures those algorithms become systems that operators will trust with their lives. The distinction isn’t about individual capability. It’s about fundamentally different professional objectives and the training required to bridge them. If we want research to transition successfully, we have to treat sustainment as a discipline, not an assumption.

IV. The Valley of Death: Why Transition Failures Persist

The Air Force acquisition system is designed to distribute responsibility across many organizations, which works for governance at scale but leaves no single role accountable for owning and reducing integrated product risk as capabilities move from Research toward Operations.

Figure 4 illustrates how product risk concentrates during Transition and why deliberate ownership of integrated risk reduction is required to cross the Valley of Death.

Historical accounts suggest the Valley of Death wasn’t an inevitable feature of complex system acquisition but rather the predictable result of eliminating the professionals who were well prepared in how to navigate it [1]. Reagan-era Developmental Engineers didn’t fear the Valley of Death because their training and experience had prepared them to cross it routinely. The challenge wasn’t mysterious or intractable. It was simply hard work understanding the convergence of functions that must align for a capability to successfully transition: safety, testing, doctrine, operations, logistics, personnel, and acquisition.

When these functional intersections aren’t addressed deliberately, integration failures become predictable. A technology might be brilliant in isolation but fail because no one verified it could be maintained with available personnel, or tested with existing infrastructure, or operated within current doctrine. Each function touches the risk but none owns it completely. The result is predictable: integration failures emerge late, when they’re most expensive to fix and most likely to trigger program crises.

The persistence of the Valley of Death isn’t because the challenges are insurmountable. It persists because the Air Force no longer develops professionals with the breadth of knowledge required to recognize and eliminate the five integrated transition risks depicted in Figure 4 before they become program killing failures. What was once routine professional work has become an organizational gap that no amount of process improvement can fully address.

Developmental Engineering existed to counteract exactly this problem. Reagan-era Developmental Engineers were trained to own Transition risk as a single integrated problem and reduce it before full commitment. When that profession disappeared, the failure mode became predictable.

In practice, the five integrated transition risks shown in the diagram are handled in organizational stovepipes, with no single role accountable for reducing them together. Each risk can appear manageable in isolation. Their interaction is what consistently drives late stage integration failure.

Early in my career, I encountered the Valley of Death 4 times, each driven by a different combination of these risks. Once I began deliberately reducing them as an integrated set, the pattern stopped. Over the next 21 years, I didn’t encounter it again. The system didn’t change. Risk ownership did.

The Valley of Death isn’t a gap between organizations or phases of work. It’s what happens when one or more transition risks remain unresolved as operational accountability arrives.

This becomes most visible during systems integration. Independent technologies must operate as a coherent whole. Flexible interfaces become commitments. Tolerated behaviors must become deterministic. Latency, reliability, cybersecurity, training burden, sustainment, and interoperability surface simultaneously, often for the first time.

As a capability approaches Operations, rigor is imposed by operational reality, not process preference. Command accountability demands predictable behavior, controlled change, and mission reliability. Sustainment and long term viability can no longer be deferred. These constraints are unavoidable when lives and missions are at stake.

This is precisely the problem Reagan-era Developmental Engineers were developed to solve. Their role wasn’t to manage individual technologies or enforce compliance. It was to own the integrated risk of turning possibility into dependable operational reality. When that capability was dismantled, the Valley of Death didn’t disappear. It became inevitable.

Without deliberate Integrated Product Risk Ownership, systems integration becomes the point where complexity overwhelms intent, and transition failure remains the rule rather than the exception.

A. Cross-Service Relevance

While this article examines Air Force Developmental Engineering as a case study, the underlying failure mode transcends service boundaries. The Navy experiences similar late-stage integration challenges across combat systems modernization, DDG Flight III (Arleigh Burke-class destroyer) upgrades, and submarine systems integration, where no single role owns integrated product risk from early development through fleet introduction. The Army faces parallel issues in weapons system modernization and battlefield network integration. The loss of professional systems integrators who can orchestrate technology, requirements, and acquisition simultaneously is a Department-wide capability gap, not an Air Force anomaly. Addressing it requires recognition at the Office of the Secretary of War (OSD) level, but the Air Force case provides the clearest historical example of what was lost and what must be rebuilt.

The Navy faces this acutely in shipbuilding integration, where combat systems, propulsion, and mission systems must converge into operational vessels. The Zumwalt-class destroyers, Ford-class carrier elevators, and Littoral Combat Ship mission packages all experienced late-stage integration failures characteristic of this gap. No single role owned the integrated risk of turning individual subsystems into operational warships capable of meeting fleet requirements.

The Navy’s experience with Engineering Duty Officers (EDOs) offers a parallel worth noting. EDOs held responsibilities strikingly similar to Air Force Developmental Engineers: research, design, development, construction, procurement, evaluation, maintenance, and repair of ships and their systems. A 1965 Proceedings article by Charles R. Peck warned that inadequate staffing was creating a “vicious cycle spiralling into self-destruction” [15]. Critically, Peck documented that attempts to substitute line officers with technical subspecialties had “proved unrealistic,” foreshadowing the same mistake the Air Force would make decades later. While the Navy maintained the EDO designation, the community numbered 838 experienced officers in 1964 despite these warnings. Whether the Navy subsequently scaled this community to match increasing fleet complexity, or maintained the long term development model necessary to avoid valley of death transitions, remains an open question requiring further investigation.

B. Why Contractor-Led Integration Hasn’t Eliminated the Valley of Death

Given the erosion of government technical capability, Department leaders have increasingly relied on prime contractors to provide system integration expertise. Major defense contractors employ talented engineers with deep technical knowledge. When properly managed, contractor integration teams can be highly effective.

But contractor-led integration can’t replace government ownership of integrated product risk. Contractors optimize for contract performance and profit, not lifecycle integration across decades of upgrades, changing threats, and organizational evolution. Their expertise leaves when contracts end or staff rotate to other programs. The government loses the institutional memory needed to understand why design decisions were made, what tradeoffs were accepted, and which assumptions must hold for the system to remain viable.

More fundamentally, when contractors possess technical knowledge the government lacks, the power dynamic inverts. Government program offices can’t validate contractor claims, can’t challenge questionable assertions, and can’t distinguish between genuine technical constraints and contractor preference. This knowledge gap often gets filled by Systems Engineering and Technical Assistance (SETA) contractors who themselves lack the cross-domain expertise to validate recommendations. Prime contractors often spend weeks explaining sound technical solutions to intermediaries who can’t effectively evaluate them. The result is decision friction without improved decision quality. If Developmental Engineers existed today, decisions would move at the speed of understanding, not the speed of explanation.

Complex weapon systems require someone who remains accountable across the full lifecycle, someone who can’t walk away when integration problems emerge years after fielding. Contractors fulfill their contractual obligations and move on. The government, specifically the uniformed services and their civilian workforce, remains responsible for maintaining, upgrading, and operating these systems for 30 to 50 years. That enduring accountability requires enduring capability. Reagan-era Developmental Engineers provided that capability. When they disappeared, the government became dependent on contractors for expertise it could no longer validate, creating the conditions for systematic integration failure.

C. Why Modern Systems Engineering Hasn’t Eliminated the Valley of Death

Department leaders have increasingly turned to systems engineering approaches like Model-Based Systems Engineering (MBSE) and Modular Open Systems Approach (MOSA) to manage growing system complexity. These approaches can improve traceability, enable earlier analysis, and reduce certain classes of integration error.

But they don’t own the five integrated product risks. Systems engineering tools model system behavior, but they can’t resolve conflicts between operational doctrine, sustainment reality, training burden, organizational incentives, and acquisition constraints. They can define interfaces, but they can’t determine whether those interfaces remain viable once a system enters sustained operational use across decades of upgrades and adversary adaptation.

In practice, these approaches depend on human judgment to decide which risks matter, which tradeoffs are acceptable, and when modeled assumptions no longer hold. When that judgment isn’t deliberately cultivated across the full lifecycle, systems engineering artifacts create the appearance of control without actually eliminating the underlying risk. Programs can pass every technical review with models that accurately represent design intent while still failing at transition because the models never captured operational reality.

Reagan-era Developmental Engineers didn’t compete with systems engineering. They completed it. They were the professionals trained to interpret models, challenge assumptions, and intervene when technically correct designs were operationally brittle. When that profession disappeared, systems engineering tools remained, but no one owned the judgment required to use them as intended. When systems engineering is treated as a substitute for integrated judgment rather than an input to it, the Valley of Death becomes inevitable.

V. The Path Forward: Rebuilding What Was Lost

The solution is conceptually straightforward: reinstate the long-term career development system that once produced Developmental Engineers capable of owning the five integrated product risks across the full acquisition lifecycle. This means recreating rotational assignments that built expertise over decades through operations, test, depots, labs, and program offices. It requires accepting that this capability takes 10 to 20 years to develop.

The challenge is temporal. Even starting today, the first cohort wouldn’t reach senior expertise until the mid-2030s, and wouldn’t possess elite Developmental Engineer capability until the 2040s. Programs struggling today wouldn’t benefit. Yet without this investment, the Air Force will face identical crises in 2035, 2045, and beyond. 

This suggests a two-track approach: near-term mitigation and generational reconstitution.

A. Long-Term Reconstitution

Rebuilding the Developmental Engineering pipeline would require several interconnected elements. First, it must deliberately produce professionals who understand mission needs, operational realities, and how acquisition actually delivers capability. They must also stay continuously current on modern technology, especially computing and software, since those now dominate feasibility, integration risk, cyber exposure, and long term sustainment outcomes.

This reconstitution requires formal career pathways rotating officers through operations, test, depots, labs, and program offices with assignments long enough for deep learning (3 to 4 years minimum). It also requires institutional protection so these developmental pathways don’t erode under competing priorities, backed by sustained senior leader ownership anchored in designated offices with flag officer sponsorship to protect and enforce the career pipeline over decades.

It requires continuous technical education throughout 20 year careers, not just early graduate degrees. That continuous learning must include modern software architecture, integration and interoperability patterns, cyber survivability, verification and test realities, embedded and edge constraints, software sustainment engineering, and the data and AI dependencies increasingly shaping weapon system behavior.

Finally, it requires acceptance of generational timelines, understanding this investment won’t yield fully capable senior Developmental Engineers for 10 to 20 years. The biological constraints of expertise development can’t be bypassed. The Air Force can begin rebuilding this capability now, or continue deferring it as system complexity accelerates and transition failures become larger, slower, and more expensive.

B. Short-Term Mitigation

While reconstitution proceeds, there are concrete actions that can materially reduce today’s Valley of Death risk. These are not speculative reforms. They address structural weaknesses in the acquisition system that drive transition failure regardless of whether Developmental Engineering is formally restored. The common thread is shifting effort earlier, toward mission outcomes, system integration, and long term sustainability, where risk is still cheap to discover and correct. Taken together, these actions directly attack the concentration of integrated product risk depicted in the Valley of Death, shifting risk resolution earlier in the lifecycle before operational commitment makes failure inevitable.

Product management expertise infused across the acquisition workforce is the fastest way to introduce disciplined ownership of integrated product risk. The product management discipline has developed explicit practices for managing four of the five integrated product risks that drive transition failure, with lifecycle sustainability requiring additional, explicit treatment in defense contexts. [16][19]

1. Mission Value Risk asks whether a capability will measurably improve mission outcomes rather than merely satisfy documented requirements. 

2. Program Viability Risk examines whether the capability can be delivered and sustained within cost, schedule, policy, and organizational constraints. 

3. Operational Usability Risk focuses on whether operators can effectively employ the capability under real operational conditions, not idealized test environments. 

4. Technical Feasibility Risk assesses whether the capability can be built, integrated, and evolved with available technology, skills, and workforce capacity. 

5. Lifecycle Sustainability Risk captures whether a capability can be sustained, maintained, and evolved over decades of operational use without accumulating prohibitive technical debt, cost, or operational fragility.

The commercial technology sector learned that delivery speed is meaningless if the wrong capability is built or if operational users reject it. As a result, product management emerged as a discipline specifically designed to prevent requirements failure and late discovery of value gaps. While these practices were developed in commercial contexts, defense can adapt them rather than starting from scratch.

On the government side, program offices need training in modern product management approaches that go beyond compliance oriented program execution. The Project Management Institute’s PMBOK 7th and 8th editions have integrated product management thinking into their standards [17], making them a practical starting point given the trust PMI already holds within the acquisition workforce. However, this material is insufficient on its own and must be supplemented with deeper, defense specific training that addresses mission critical fielding, multi team development at scale, and the realities of defense acquisition and operational accountability.

On the contractor side, program offices can demand this capability directly through source selection, requiring bidders to demonstrate talent that actively manages these five integrated product risks rather than simply coordinating backlogs, schedules, and artifacts.

Cross functional integration teams should be embedded in major programs from inception, with representatives from test, operations, logistics, acquisition, safety, and sustainment working concurrently rather than sequentially. Their purpose is to surface and resolve the five integrated product risks early, in parallel with technology development, rather than discovering conflicts at transition milestones. These teams must have explicit authority to elevate cross domain conflicts directly to program leadership so unresolved interactions between these risks are addressed while design freedom still exists.

Program success should be evaluated not only by cost and schedule performance, but by objective, documented evidence that the five integrated product risks have been systematically reduced to acceptable residual levels, or explicitly accepted by the Milestone Decision Authority, as a condition for Milestone B approval.

Contractual requirements for sustainable source code are necessary to address Lifecycle Sustainability Risk. Program offices should require contractors to deliver code that can be maintained by engineers other than the original authors and to uphold that standard throughout the system’s operational life. Contracts should define specific maintainability criteria [18] as conditions of acceptance prior to operational transition and enforce those criteria during sustainment. This ensures software represents technical wealth rather than technical debt that silently increases cost, fragility, and readiness risk over time.

Retention incentives for experienced acquisition personnel are critical to preserving system level knowledge accumulated over 15 or more years on the same platform or system family. This targets the small cadre of government civilians and military officers who understand how subsystems interact, know the history behind design decisions, and can anticipate downstream consequences of proposed changes. These individuals provide continuity across modernization cycles and prevent costly relearning during technology insertions and capability upgrades. Without deliberate retention, this expertise exits at retirement, forcing programs to repeatedly rediscover the same integration lessons.

While these actions strengthen acquisition capability, they don’t replace the need for Developmental Engineers on highly complex systems. Product management expertise improves how programs identify and reason about integrated product risks, but it operates primarily within program boundaries and near term delivery horizons. Complex weapon systems require professionals who integrate these risks across multiple programs, contractors, and organizations over decades long lifecycles. Product managers ensure individual capabilities are valuable, viable, usable, and feasible. Developmental Engineers ensure those capabilities function as a coherent system when brought together at transition. The distinction isn’t individual competence, but the depth of cross domain judgment that only develops through 10 to 20 years of deliberate, rotational experience. Product management raises the floor across the enterprise. Developmental Engineering defines the ceiling for complex system integration. 

C. The Decision Point

Only the Secretary of the Air Force can break this cycle. The short-term mitigations described above provide immediate actions that can begin in the next budget cycle. Cross-functional integration teams can be established on current programs. Product management expertise can be demanded in the next contract awards. Sustainable code requirements can be added to active solicitations. Retention incentives can be budgeted immediately. These actions will reduce integration failures while long-term reconstitution proceeds.

The long-term solution requires a different kind of commitment: accepting that rebuilding Developmental Engineering capability will take 10 to 20 years. Officers entering the pipeline today wouldn't possess senior-level expertise until the mid 2030s. This timeline can't be shortened. The biological constraints of expertise development are immutable. But the alternative is continuing to face identical capability gaps in 2035 and beyond, because the fundamental problem remains unaddressed.

The decision is whether to begin both tracks now. The short-term actions provide relief during the next decade. The long-term reconstitution ensures the Air Force of the future doesn't face the same crisis the Air Force faces today. The cost of reconstitution would likely be modest compared to the $140 billion Sentinel overrun or cumulative transition failures over the next 20 years.

Acknowledgments

The author gratefully acknowledges Marc Ohmer of the Air Force Research Laboratory (AFRL) for sharing his insights into the history and structure of the Reagan-era Developmental Engineering career field. His firsthand accounts of what that profession entailed, how the 20-year rotational system functioned, and the institutional knowledge that was lost in 1992 were invaluable in understanding this capability gap. The historical context of the 1992 divestment decision were informed by Ohmer’s perspective as one of the last officers developed under that system. The analysis of integrated product risk ownership and biological constraints on expertise development reflects the author's 21 years of direct experience implementing continuous learning systems for an engineering organization and observing talent development across multiple operational contexts. The author is responsible for all interpretations and conclusions presented in this analysis, which may not represent official positions of AFRL or the Air Force.

References

[1] M. Ohmer, Chief Engineer, Air Force Research Laboratory Information Directorate, private communication regarding Reagan-era Developmental Engineering practices and contemporary transition challenges in C4I and Battle Management systems, January 2026.

[2] U.S. Government Accountability Office, Defense Acquisition Reform: Persistent Challenges Require New Iterative Approaches to Delivering Capability with Speed, GAO-25-108528, Jun. 2025. [Availalble Online, Accessed: Jan. 8, 2026].

[3] S. LaGrone, "Pentagon cuts back F-35 upgrades to slow schedule slips: Auditors," Defense News, Sep. 3, 2025. [Available Online, Accessed: Jan. 8, 2026].

[4] "Boeing's Air Force One Project years late and billions over budget, report says," News 4 San Antonio, Jul. 2, 2025. [Available Online, Accessed: Jan. 8, 2026].

[5] "The Pentagon is Overhauling the Defense Acquisitions Process: What to Know," Steptoe & Johnson LLP, Nov. 7, 2025. [Available Online, Accessed: Jan. 8, 2026].

[6] National Academies of Sciences, Engineering, and Medicine, Owning the Technical Baseline for Acquisition Programs in the U.S. Air Force, Washington, DC: The National Academies Press, 2016. doi: 10.17226/23631.

[7] Congressional Budget Office, The Drawdown of the Military Officer Corps, Washington, DC, Nov. 1999. [Available Online, Accessed: Jan. 8, 2026].

[8] M. G. Mattock, B. J. Asch, J. Hosek, and M. Boito, The Relative Cost-Effectiveness of Retaining Versus Accessing Air Force Pilots, RAND Corporation, Santa Monica, CA, Rep. RR-2415, 2019. [Available Online, Accessed: Jan. 7, 2025].

[9] U.S. Air Force, “Air Force Officer Classification Directory,” 31 Oct. 2023. [Available Online, Accessed: Jan. 8, 2026].

[10] "Acquisition Management in the United States Air Force and its Predecessors," Air Force Materiel Command History Office, Wright-Patterson AFB, OH. [Available Online, Accessed: Jan. 7, 2025].

[11] G. Colvin, Talent is Overrated: What Really Separates World-Class Performers from Everybody Else, 2nd ed. New York, NY: Portfolio/Penguin, 2010.

[12] I. A. McKenzie, D. Ohayon, H. Li, et al., “Motor skill learning requires active central myelination,” Science, vol. 346, no. 6207, pp. 318–322, Oct. 2014, doi: 10.1126/science.1254960.

[13] S. L. Bengtsson, Z. Nagy, S. Skare, L. Forsman, H. Forssberg, and F. Ullén, “Extensive piano practicing has regionally specific effects on white matter development,” Nature Neuroscience, vol. 8, pp. 1148–1150, 2005, doi: 10.1038/nn1516.

[14] J. Scholz, M. C. Klein, T. E. Behrens, and H. Johansen-Berg, “Training induces changes in white-matter architecture,” Nature Neuroscience, vol. 12, pp. 1370–1371, 2009, doi: 10.1038/nn.2412.

[15] C. R. Peck, “Engineering Duty Officers: The Dwindling Muster,” Proceedings, vol. 91, no. 12, pp. 754, Dec. 1965.

[16] A. Park, “Product Management Talent: The Critical Gap Agile and DevSecOps Can’t Fix,” LinkedIn, Oct. 2025. https://www.linkedin.com/pulse/product-management-talent-critical-gap-agile-devsecops-andrew-park-i7the/?trackingId=Wzj8DBsYQ1W3lULm5sF2ow%3D%3D

[17] A. Park, “Product Management in PMBOK 7th Edition: The Complete Analysis,” LinkedIn, Oct. 2025. https://www.linkedin.com/pulse/product-management-pmbok-7th-edition-complete-analysis-andrew-park-qasoe/?trackingId=Wzj8DBsYQ1W3lULm5sF2ow%3D%3D

[18] A. Park, “Debunking the AI Documentation Myth: What Engineering Leaders Must Know,” LinkedIn, Aug. 2025. https://www.linkedin.com/pulse/debunking-ai-documentation-myth-what-engineering-leaders-andrew-park-feyye/?trackingId=Wzj8DBsYQ1W3lULm5sF2ow%3D%3D

[19] M. Cagan, “Inspired: How to Create Tech Products Customers Love. 2nd ed.”, Wiley, 2017. The framework of value risk, viability risk, usability risk, and feasibility risk is adapted from Cagan’s work. Lifecycle sustainability risk is added in this paper to address the unique challenges of defense platforms that must be sustained and evolved over decades. 

The views and analysis presented in this article are those of the author and don't necessarily reflect official Air Force positions.