Joby Aviation’s Systems Engineering Organization in 2026: What Certification Scale Reveals
Joby Aviation is no longer a startup demonstrating flight capability. In 2026, it is an organization actively working through the FAA’s most demanding airworthiness certification process for a new category of aircraft. The shift is consequential — not just for Joby, but for every eVTOL program watching from behind. What Joby has built in terms of systems engineering and compliance infrastructure over the past several years tells a clearer story about what this class of vehicle actually requires than any press release about range or payload.
This analysis focuses on one narrow slice: how a multi-hundred-engineer organization structures itself to manage DO-178C, DO-254, and ARP4754A compliance simultaneously, at scale, for an aircraft that has no direct heritage precedent. We are not evaluating the aircraft design. We are evaluating the engineering organization as a compliance machine.
The Certification Context: Why Joby’s Situation Is Structurally Different
Joby is pursuing FAA Part 21 type certification under Special Conditions — a path the FAA has been developing specifically for powered-lift aircraft. This is not a variation on a known type. The FAA is writing new requirements in parallel with Joby’s compliance work, which means Joby’s systems engineering organization must be capable of responding to regulatory evolution in real time while maintaining an internally consistent compliance baseline.
That is an unusual demand to place on any engineering organization. Most aerospace programs certify against a relatively stable regulatory target. Joby is certifying against a moving one.
This shapes everything downstream: how requirements are captured, how changes are tracked, how traceability is maintained, and how the organization decides when a subsystem’s compliance artifacts are stable enough to freeze.
ARP4754A — the SAE standard for development of civil aircraft and systems — was written with conventional aircraft architectures in mind. Its applicability to distributed electric propulsion systems with six tilting rotors, fly-by-wire as the primary control surface, and no mechanical reversion is not in dispute, but the interpretation of its development assurance levels (DALs) for novel failure modes is an active negotiation between Joby and the FAA. Systems engineering teams at Joby are not simply executing a known process. They are co-authoring the process while executing it.
Organizational Structure for Compliance at Scale
By most external indicators, Joby’s engineering headcount crossed 1,000 in 2024 and has continued growing into 2026. Not all of those engineers are doing systems engineering work, but a substantial portion are — and the organizational structure required to coordinate their compliance artifacts is non-trivial.
Programs at this scale typically resolve into one of two organizational models for compliance work: federated or centralized.
In a federated model, each major subsystem team (avionics, propulsion software, power electronics, flight controls) owns its own compliance documentation and maintains its own internal traceability. A central systems engineering function sets standards and audits, but does not own the artifacts.
In a centralized model, a systems engineering organization owns the master requirements hierarchy, the system-level FMEA/FHA (Functional Hazard Assessment), and the traceability architecture. Subsystem teams contribute to it but do not own it independently.
Joby has publicly structured around a model that leans centralized at the top of the V — meaning the aircraft-level functional hazard assessment, the preliminary system safety assessment, and the system-level requirements are owned by a core systems engineering group — with federated execution below. This is the correct architecture for ARP4754A compliance on a novel aircraft. The aircraft-level safety case must be owned somewhere, and it cannot be assembled post-hoc from independent subsystem documents.
The risk with this model is interface management. When a propulsion software team modifies a motor controller response characteristic, the change must be evaluated against aircraft-level requirements and safety assessments, not just unit-level DO-178C artifacts. The organizational mechanism for ensuring that happens consistently — across hundreds of engineers, multiple tools environments, and ongoing regulatory dialogue — is where eVTOL programs most commonly accumulate compliance debt.
The DO-178C and DO-254 Problem at This Scale
DO-178C governs airborne software development. DO-254 governs complex electronic hardware (primarily FPGAs and custom ASICs). Both require bidirectional traceability from high-level requirements through low-level implementation, with review and verification evidence at each transition.
Joby’s aircraft almost certainly has DAL A software — the highest criticality level, requiring the most rigorous verification — in its flight control and propulsion management systems. DAL A software under DO-178C is expensive not primarily in development cost but in verification cost. The ratio of verification effort to development effort at DAL A is often 3:1 or higher. Multiply that across multiple flight-critical software components and you have a significant portion of Joby’s engineering capacity allocated to producing and reviewing compliance evidence.
The structural challenge here is not producing the evidence. Modern development toolchains — certified compilers, model-based development environments, automated test coverage tools — have matured enough that generating DO-178C artifacts is more tractable than it was a decade ago. The challenge is traceability currency: keeping the requirement-to-test mapping accurate as the software evolves.
Aircraft software does not stop evolving during certification. Flight test reveals gaps. Regulatory feedback requires requirement changes. Hardware bring-up creates constraints that feed back into software requirements. Every change to a high-level requirement in a DAL A software component requires re-verification of all affected low-level requirements and test cases. In a program with thousands of software requirements spread across multiple components, the ability to answer “what does this requirement change affect?” in minutes rather than weeks is not a workflow nicety — it is a program schedule dependency.
The same logic applies to DO-254 artifacts for complex programmable hardware. FPGAs in flight-critical applications require hardware design life-cycle data analogous to DO-178C’s software life-cycle data, and the traceability demands are comparable. Joby’s distributed propulsion architecture almost certainly involves significant FPGA content in motor controllers, and managing that compliance data alongside software and system-level artifacts requires an integrated tooling approach.
Requirements Traceability as Infrastructure
The word “traceability” appears in every aerospace compliance conversation, but it is often discussed as though it were a documentation practice rather than an infrastructure problem. At Joby’s scale, it is infrastructure.
A traceability system for an aircraft in this class is managing something in the range of tens of thousands of requirements, verification cases, and compliance artifacts, with relationships between them that must be maintained accurately across years of development. The failure mode is not “we lost track of a requirement.” The failure mode is silent staleness — a requirement that was updated but whose downstream verification artifacts were not flagged for review because the change management system did not capture the dependency.
Legacy requirements management tools — IBM DOORS being the canonical example — were built for this problem but were not built for the change propagation velocity of a modern, iterative development program. DOORS manages requirements and links effectively, but its architecture reflects an era when requirements were relatively stable documents rather than living data structures. Programs using DOORS at Joby’s scale often find themselves maintaining the tool’s integrity as a significant engineering task in its own right: schema management, module architecture decisions, and link consistency checks consume engineering time that could go elsewhere.
Newer platforms — Jama Connect, Polarion, Codebeamer — offer web-based architectures and better collaborative tooling, but many remain fundamentally document-centric in their underlying data model. They represent requirements as structured text with links, rather than as nodes in a graph where relationships are first-class objects. That distinction matters when you are trying to answer impact questions quickly: “If this system-level requirement changes, which DAL A software requirements are affected, and which DO-178C test cases need re-verification?” A document-centric tool requires a human to trace that chain. A graph-native tool can answer it directly.
This is the architectural divide that modern eVTOL programs are encountering in practice, and it is where tooling investment decisions made early in a program have compounding consequences. Teams that built their requirements infrastructure on graph-based, relationship-native data models — treating requirements, hazards, verification objectives, and design artifacts as connected nodes rather than linked documents — are better positioned to handle change propagation at scale.
Tools like Flow Engineering, which were built natively around this graph-centric model for systems engineering work, represent the architectural direction that compliance-at-scale demands. The ability to traverse a live requirements graph from aircraft-level functional requirements through system requirements, software high-level requirements, and into test cases — and to immediately surface what is stale when a parent changes — is not a feature. It is the precondition for operating a compliance program at Joby’s scale without an army of dedicated traceability administrators.
What Joby’s Timeline Reveals About Enterprise Systems Engineering Maturity
Joby received its Part 135 air carrier certificate in 2023 and has been progressing through type certification milestones since. The program has taken longer than originally projected — a fact that has been reported extensively and that Joby has addressed in investor communications.
What the timeline actually reveals is worth examining without the hype filter in either direction.
The honest interpretation is that eVTOL type certification is harder than the first generation of programs estimated, and harder specifically in the compliance infrastructure dimension. The aerodynamics were understood early. The propulsion physics were demonstrated early. The vehicle works. What takes time is building and sustaining the organizational and tooling infrastructure to produce, maintain, and defend a complete, consistent, auditable body of compliance evidence to the FAA’s satisfaction — across dozens of subsystems, multiple standards, and years of design evolution.
Joby’s timeline also reflects something constructive: the program has not collapsed under compliance weight. Programs that treat ARP4754A as a late-stage activity — capturing “what we did” rather than driving development — often hit a wall in the third or fourth year when they discover that their system safety assessments do not support their design choices, or that their requirements traceability has gaps that require redesign to close. Joby appears to have avoided the worst versions of that failure mode, which suggests that its systems engineering investment was structural rather than cosmetic.
The pacing signals that the right model is: two to three years to build a compliance-capable systems engineering organization, then type certification on top of that foundation. Programs that try to compress that sequence — certifying first, building the infrastructure second — are not moving faster. They are deferring costs that will arrive with compounding interest.
Honest Assessment
Joby’s systems engineering organization in 2026 is one of the most advanced in the eVTOL sector by almost any structural measure. It has operating compliance programs across DO-178C, DO-254, and ARP4754A simultaneously. It has maintained a coherent safety case through years of design evolution and ongoing regulatory dialogue. It has not had to retreat to a fundamentally different aircraft architecture under compliance pressure.
What remains genuinely uncertain is whether the compliance infrastructure Joby has built can sustain the pace of change that production-intent certification requires. The transition from “we can demonstrate compliance for this configuration” to “we can sustain compliance across an evolving production design with multiple aircraft in service” is a second infrastructure problem, not a continuation of the first. Requirements management, change control, and traceability systems that worked for a single prototype configuration will be stress-tested hard as production design locks in, as in-service issues require software updates, and as field configurations diverge from certification baseline.
That is the next systems engineering challenge for Joby — and, in different timeframes, for every eVTOL program behind it. The programs watching Joby’s certification progress most carefully are not watching for flight test results. They are watching the compliance infrastructure and asking whether it holds.