The corporate restructuring report (Employment) shows two trajectories crossing: European automotive is structurally shedding jobs, while defense and aerospace are growing again. This raises a question: can workers leaving the first sector genuinely enter the second, and which other sectors as well. Up to this point the answer was argued on the basis of technical adjacency and comparable employment intensity. This report examines the question starting from the data: 16,386 real job postings, 93 companies, seven sectors.

16,386
postings analyzed
7
engineering sectors
93
companies, EU + USA

What the postings are actually about

For each sector, how the "technical budget" of mentioned skills breaks down — how much each category weighs in the total technical mentions for that sector:

SectorCAD/PLMSimulationSoftwareAutomationSystemsCyberERP
Rail/Naval29.2%4.7%18.7%7.0%11.7%0.6%22.2%
Construction/AEC13.3%19.6%24.2%12.7%11.7%4.0%10.1%
Mechanics/Automation12.5%5.6%25.5%19.6%7.0%2.4%17.2%
Energy11.6%8.1%28.9%8.5%9.6%2.0%18.8%
Automotive7.8%14.3%27.5%10.3%15.8%3.8%8.0%
Defense/Aerospace6.9%7.8%27.4%5.9%20.2%17.1%8.1%
Electronics/Semic.6.0%11.6%27.0%8.9%15.2%1.8%9.6%

Three main signals emerge. Rail/Naval is the sector most oriented toward CAD design: nearly a third of technical mentions concern CAD/PLM, double any other sector. Cybersecurity is an almost exclusive trait of defense (17.1% versus 0.6-4.0% elsewhere). And ERP is not a marginal category: 22.2% in Rail, 18.8% in Energy, 17.2% in Mechanics, but just 8.0% in Automotive, the lowest value among the main sectors. A spot check confirms these are real roles (buyer, quality, HR, accounting), not statistical noise; a plausible hypothesis is that automotive already has management systems consolidated over decades, with lower turnover in those roles.

Three categories worth distinguishing

Software, Automation and Systems sound similar, but they capture three different things — which is exactly why it's worth distinguishing them before reading the rest of the table.

Software/Programming

What it captures: programming languages (Python, C++, C#, Java), development practices (Git, Agile, Scrum, DevOps), cloud infrastructure (AWS, Azure), and embedded software/vehicle protocols (AUTOSAR, CAN bus).

The question it answers: "does this role require writing code or working with software development tools?" It is the broadest and most generic of the three categories — which is why it is nearly identical in absolute value everywhere (27-29% in almost every sector except Rail). Writing software is now cross-cutting across all of modern engineering.

Automation/Control

What it captures: industrial automation in the strict sense — PLC, SCADA, robotics. These are the keywords of those who design or program machines and physical plants, not generic software applications.

The question it answers: "does this role work with industrial control systems or robotics?" This is why Mechanics/Automation dominates by a wide margin (19.6%, nearly double anyone else) — it is literally the sector that sells automated production lines, PLCs included.

Systems/Engineering

What it captures: not a tool or a machine, but a discipline/methodology — systems engineering, MBSE (Model-Based Systems Engineering), requirements management, verification and validation, safety engineering, standards such as ISO 26262 (automotive) and DO-178 (aerospace).

The question it answers: "does this role require managing the complexity of a system through a formal engineering process — traced requirements, verification, safety certification?" This is why Defense (20.2%) and Automotive (15.8%) lead: they are the two sectors with the strictest safety-critical regulatory regimes (DO-178 for aerospace, ISO 26262 for critical automotive systems).

Why the distinction matters for reading the table

A sector can be high on one of these three and low on the other two, and each of those combinations tells a different story.

High Automation, low Systems (Mechanics: 19.6% versus 7.0%) → machines are programmed, but with less formalized engineering processes — consistent with a sector where the certification cycle is less regulated than in aerospace.
High Systems, low Automation (Defense: 20.2% versus 5.9%) → the work is more about "governing complexity and compliance" than "programming a physical plant" — consistent with defense producing complex systems (a fighter jet, a radar) where the risk of failure requires formal requirements traceability, not necessarily production robotics.
Software high everywhere, nearly constant → confirms that writing code is now a cross-cutting prerequisite, not a differentiator between sectors. Systems and Automation, being more selective, remain the two most informative categories for telling one sector apart from another.

Similarity between sectors

Each circle is a sector, sized by number of postings. Position reflects how similar the skill profiles are — the exact index for each pair is in the table right below; the circles alone are not enough to read a precise number.

Automotive Construction Defense Electronics Energy Rail Mechanics software systems software systems software simulation software erp software automation software cad/plm Position calculated via multidimensional scaling on the similarity matrix (9 technical categories); circle size ∝ number of postings for the sector (relative value, not to scale). The lines connect the sector pairs from the "Overlapping skills" table below: software is the skill shared by every one of them. Rail/Naval remains isolated because it does not appear in any pair in the intersection table.

Sector similarity index

AutoConstrDefenseElectrEnergyRailMech
Automotive0.960.920.980.930.740.89
Construction0.960.850.920.910.800.90
Defense/Aerospace0.920.850.880.840.690.78
Electronics0.980.920.880.940.730.88
Energy0.930.910.840.940.860.95
Rail0.740.800.690.730.860.84
Mechanics0.890.900.780.880.950.84

Overlapping skills

PairIndexShared skills
Automotive — Electronics0.98software, validation/verification
Automotive — Construction0.96software, fem
Energy — Mechanics0.95software, sap
Electronics — Energy0.94software
Automotive — Defense/Aerospace0.92software, validation/verification (detailed in the next section)
Construction — Energy0.91software

The clearest signal remains the isolation of Rail/Naval: in the table it is the only row that never exceeds 0.86 (its highest value, with Energy), consistent with its CAD/PLM-dominant profile seen above. The rest of the sectors form a more cohesive cluster (0.78-0.98, with only the Defense/Aerospace—Mechanics pair below 0.80) linked almost everywhere by the same skill core — software appears in every shared pair in the table.

Automotive and Defense: the real degree of overlap

The synthetic similarity between Automotive and Defense is 0.92 — high, but the whole map ranges between 0.69 and 0.98: a single number tends to make all sectors look more similar than they are in practice. The keyword-by-keyword detail is where the real information lies:

KeywordStatusAutomotiveDefense
softwareShared12.5%24.9%
validation / verificationShared7.1%16.7%
pythonShared4.0%10.7%
sapShared4.4%10.9%
agile / cloudShared4.0-4.3%9.3-11.3%
fem (finite elements)Automotive-exclusive5.6%0.4%
systems engineeringDefense-exclusive0.5%11.4%
cybersecurityDefense-exclusive1.8%8.6%
radar / avionicsDefense-exclusive0.2%6.1%
c++ / matlabDefense-exclusive1.3%5.2%

The pattern confirms the thesis argued earlier: the shared skills are platform-level — software, validation, ERP systems, agile methodologies — the same ones an automotive mechanical engineer already has regardless of sector. Defense-exclusive skills concern almost entirely cybersecurity, systems and embedded, a specific refinement more than a career change. The only skill clearly exclusive to automotive is structural simulation (FEM).

It should be noted that most of the entries classified as "Defense-exclusive" are so more by intensity — defense cites almost every skill with higher frequency — than by genuine absence in Automotive. The data does not indicate a lack of skills, but that the same skills are demanded by defense with a higher intensity, and likely a higher certification requirement.

The pivot is not the same for everyone

Asking whether a sector already has the necessary skills only makes sense if the destination sector also hires staff to be trained, not only ready-made experts. Here the difference is stark:

SectorInternship/Apprentice.JuniorExpert/SeniorManagement
Automotive30.8%4.7%39.0%21.5%
Construction21.9%12.0%39.4%22.3%
Defense/Aerospace15.8%15.9%67.8%42.9%
Electronics16.4%10.1%61.0%41.4%
Energy23.9%9.4%59.6%43.1%

Automotive is nearly double defense on internships/apprenticeships (30.8% versus 15.8%): it builds pipelines. Defense asks for "expert/senior" in 67.8% of postings, nearly double automotive (39.0%). For a senior automotive worker, the door into defense is more open than it is for a fresh graduate — the same distributional asymmetry that already emerged in the restructuring report: the cost of the transition falls unevenly depending on how much room a worker has to reinvent themselves.

A finding that contradicts the most intuitive hypothesis

A widespread hypothesis is that defense's growth is mainly about R&D roles, while automotive stays concentrated in production. The data does not confirm this reading:

SectorR&DProductionQualitySales
Automotive9.2%27.6%3.3%16.5%
Defense/Aerospace11.6%43.0%5.9%21.6%

The difference in R&D exists but is modest (11.6% versus 9.2%) — not the leap intuition would suggest. And defense mentions "production/manufacturing" more than automotive, not less. This should be read with caution: "manufacturing" often appears in process-engineering roles too, not only line workers. But the message stands: the pivot is not primarily a jump toward design — it more likely concerns operational roles with a technical content and a higher seniority requirement. The real barrier looks less like "lack of R&D skills" and more like "insufficient seniority relative to what defense demands even for operational roles".

How this data was collected

Two complementary sources. Adzuna, an aggregator with a public API, provides breadth — seven sectors, four geographic areas, dozens of companies — but only a truncated snippet of the description. Direct access to corporate career portals (Workday, Oracle Cloud HCM, SAP SuccessFactors) instead provides the full text of the posting, but only for a subset of 27 companies exposing an accessible public endpoint — 5,887 of the 16,386 total postings, averaging 4,199 characters per posting.

The same taxonomy was applied to both sources: ten technical skill categories, plus academic background, seniority and role function. Before classification, every text was cleaned of recurring company-specific boilerplate (the standard introductory paragraph, often repeated identically across hundreds of postings) — otherwise a company describing itself as a leader in "cybersecurity" would have had every one of its postings classified in that category, including an administrative internship.

The set map uses classical multidimensional scaling on the cosine-similarity matrix between the 9 technical-category profiles per sector: relative positions are calculated, not eyeballed.

Stated limits The Country field remains partially unresolved in the full-text data (~90% "Other/N.A."): the analysis is therefore aggregated by sector across all countries together, not split by geography. The classification is heuristic (keyword matching), a starting point to refine, not an official figure. Academic background, seniority and role function are only captured when the posting explicitly states them. Coverage is uneven between the two sources (93 companies on Adzuna, 27 on full text): the deeper subset is not necessarily representative of the entire sector. Full list of sources and limits shared across all reports: Method page →

Historical data indicates that economies tend to absorb technological unemployment over the long run, but the cost of that transition falls disproportionately on those with the least room to reinvent themselves. The data in this report does not resolve this question, but helps define it with greater precision.