How software-defined vehicles are reshaping the automotive engineering org

The shift from hardware-led development to software-defined mobility

For most of the industry's history, vehicle capability was fixed at start of production. Features were realised through mechanical design, hardware selection and discrete electronic control units, each developed against a stable specification. Software existed, but it was subordinate to the hardware it controlled.

In a software-defined vehicle, functions are delivered through centralised or domain-based electronic architectures, service-oriented software layers and over-the-air update paths. Hardware becomes a platform; behaviour is expressed in software and refined across the vehicle's life. Powertrain calibration, driver assistance behaviour, comfort features and diagnostics all become software deliverables with their own release cycles.

The practical consequence is a change of cadence. Mechanical programs are milestone-driven and largely sequential. Software programs are iterative, versioned and continuous. Engineering organizations now have to run both rhythms inside the same product program.

What this means for engineering organizations

The most visible impact is on interfaces between disciplines. A feature that once belonged to a single team now depends on a chain of contributors, and the handover points between them become the main source of programme risk.

Close, continuous collaboration is now required across:

• Mechanical engineering — packaging, thermal behaviour and structural interfaces for new electronic content
• Embedded systems — controller software, drivers, real-time behaviour and resource budgets
• Electronics — E/E architecture, sensors, actuators, power distribution and EMC
• Software engineering — application logic, middleware, connectivity and update mechanisms
• Systems engineering — requirements, architecture, interface definition and traceability
• Functional safety — hazard analysis, safety goals and safety-related design decisions
• Cybersecurity — threat analysis, secure communication, key management and secure update paths
• Validation and testing — model, hardware and vehicle-level verification across software versions

New engineering skills are becoming essential

Demand is shifting toward engineers who can work across the boundary between physical systems and software. The capabilities most often requested in current programs include:

• Embedded software development in C and C++ for resource-constrained targets
• AUTOSAR Classic and Adaptive platform configuration and integration
• Functional safety engineering aligned to established automotive practice
• Automotive cybersecurity, including threat analysis and secure implementation
• Model-based development, including model design, code generation and model-in-the-loop verification
• Systems engineering — requirements engineering, architecture and traceability
• Vehicle networking across CAN, CAN FD, LIN, Ethernet and service-oriented communication
• Simulation and validation, including HIL, SIL and structured test automation

Depth and breadth are both required

Programs need specialists who can go deep on a domain, and integrators who understand enough of each adjacent discipline to resolve interface conflicts quickly. Organizations that staff only for depth tend to accumulate integration debt; organizations that staff only for breadth struggle at verification gates.

Why workforce models need to evolve

Software-defined development creates demand that is both specialised and uneven. A program may need concentrated cybersecurity or safety-analysis effort for a defined phase, then very little until the next release. Building every capability permanently is expensive; building none of it internally leaves the organization dependent on external judgement for core product decisions.

Most engineering organizations therefore need structured, reliable access to specialised talent that can be scaled to programme phase, without repeatedly restarting the hiring cycle from zero.

• Peak demand concentrated around integration, validation and release phases
• Skills that are scarce in the market and slow to hire through conventional cycles
• Knowledge that must be retained internally once a program moves to series support

Building engineering teams for the next generation of mobility

In practice, capable organizations combine several models rather than choosing one:

1. 1Permanent core teams that own architecture, requirements and long-term product knowledge
2. 2Specialised experts engaged for defined technical scopes such as safety analysis, cybersecurity or architecture review
3. 3Project-based engineering resources that scale delivery capacity during peak phases
4. 4Pre-trained talent pipelines that shorten ramp-up by preparing engineers on relevant tools and processes before deployment

The decisive factor is not the mix itself but the discipline around it: clear ownership of architecture, documented interfaces, consistent engineering processes and deliberate knowledge transfer whenever capacity is added or released.

Conclusion

Software-defined mobility is not simply a technology change. It changes the structure of automotive engineering organizations, the way disciplines collaborate and the skills those organizations need to sustain. Teams that treat it as an organizational transition — and not only an architectural one — are better positioned to deliver software-rich vehicles at a predictable cadence.