The autonomous defence platforms market is projected to grow from $69.77 billion in 2026 to $198.87 billion by 2034, expanding at 14% annually, according to Fortune Business Insights' June 2026 report. Goldman Sachs revised its robotics market forecast upward sixfold in a single year, as Bessemer Venture Partners noted in its April 2026 physical AI report. Across autonomous freight, defence robotics, electric aviation, and AI-driven logistics systems, a generation of European autonomous systems businesses has scaled past Series A on the back of mission-driven capital and deep technical ambition. Most of them have engineering teams of 200 or more. Most of them need a VP Engineering who can hold those teams together.

The brief they write leans toward the software side. They think of themselves as technology companies. They use Spotify models, chapter structures, and squad frameworks. They benchmark their compensation against Klarna and Zalando. When they describe the VP of Engineering they need, they describe someone who has scaled large engineering organisations at high-growth technology businesses, built cross-functional teams, and driven culture and process in a fast-moving environment. The executive search opens. The shortlist comes back. And when the scorecard is applied properly, it eliminates most of it.

The problem is not the calibre of the candidates. The problem is that the brief was written for a software engineering leader and the scorecard was built for an autonomous systems VP Engineering. These are not the same role, and the talent pools that produce them barely overlap.

We partnered with a Stockholm-based autonomous systems scale-up on a VP Engineering executive search. The company operated at the intersection of electric freight vehicles and autonomous driving technology, had raised significant venture funding, and needed an engineering leader who could build and scale a technical organisation that covered both the software systems (fleet management, AI, cloud infrastructure) and the hardware systems (vehicle hardware, sensors, embedded software, mechatronics) simultaneously. We evaluated over 500 candidate profiles across the European and global autonomous systems engineering leadership market. The scorecard had six criteria. The one that split the field was the very first line: hardware leadership experience. The second line was software leadership experience. Every candidate who scored a 1 on either criterion was not shortlisted, regardless of how strong they were on the other four.

Why the VP Engineering Role Breaks in European Autonomous Systems Scale-ups

The defining structural feature of an autonomous systems scale-up is that the engineering organisation is not one engineering organisation. It is two, operating on the same headcount budget and the same timeline, led by the same person. On one side: software engineers building fleet management systems, autonomous navigation stacks, machine learning pipelines, cloud infrastructure, and customer interfaces. On the other: hardware engineers building vehicle systems, sensor integration, embedded software, mechanical components, and physical testing infrastructure. These two populations have different hiring markets, different technical cultures, different toolchains, different development cycles, and different definitions of what "done" means.

A VP Engineering from a pure software background has spent their career in one of those worlds. They know how to hire software engineers at scale, how to build product engineering culture, how to manage sprint cadences and deployment pipelines, how to hold a large distributed software team together through rapid growth. They have no instinct for the hardware side. They do not know how to manage the relationship between a firmware engineer and a mechanical engineer working on the same subsystem. They have never managed the testing cycle for a physical prototype. They have not managed the cost and lead time implications of a hardware design change that ripples through a software stack that depends on it. These are not minor gaps. In an autonomous systems business where the hardware and software must work together under real-world operating conditions, a leader who is fluent in only one domain will fail the other.

The mirror problem is equally common. A VP Engineering from an automotive OEM or a traditional hardware engineering background brings deep technical credibility for the physical systems side. They understand vehicle architecture, sensor integration, embedded systems, and hardware programme management. They do not understand the software-first culture of a venture-backed scale-up. They have managed large engineering organisations, but inside mature corporate structures with established processes, dedicated QA teams, and timelines measured in product cycles rather than sprints. The autonomous systems engineering leader they have been is different from the one a scale-up needs: someone who can build the engineering function from first principles while the business is simultaneously scaling and shipping.

The third feature is the build context itself. The autonomous systems scale-up at the stage where this executive search becomes live is not inheriting a mature engineering organisation. It is building one. The VP Engineering will typically arrive with several teams already in place, most of them founded by engineers who joined early and grew into technical leadership without formal management experience. The engineering leader must assess who to develop, who to move, and how to build a structure that can scale from 150 engineers to 400 without breaking the culture that made the early teams effective. This is an organisational design challenge that neither the pure software background nor the pure hardware background has necessarily encountered at this specific intersection.

What the Brief Describes vs What the Business Needs

The job descriptions we see at European autonomous systems scale-ups emphasise the engineering culture and organisational dimensions: building high-performance technical organisations, driving team collaboration, scaling engineering headcount, and leading across multiple functions. These are genuine requirements. They are also framed in the language of software-first technology companies, which shapes who applies and who the hiring team unconsciously favours when they read CVs. Hardware leadership experience sits at the bottom of the requirements section, if it appears at all, or is represented by a single phrase like "experience in a hardware environment." The scorecard, when built honestly from the role's actual demands, puts hardware and software leadership on exactly equal footing. Most briefs do not.

The consequence is a candidate field that qualifies easily on the explicit criteria and reveals the gap at the scorecard stage. The candidates from Meta, Spotify, Zalando, and other high-profile software businesses look outstanding on paper. The hardware leadership question is the first screen, not the last. When it is applied early, the field changes significantly.

"The pool of candidates with genuinely strong software engineering leadership backgrounds is large. The moment you add hardware leadership at the same level, it becomes very small. The best candidates we found were almost all at other autonomous or robotics businesses already. They were not looking. They had come to see those environments as a specific kind of work that most tech companies cannot offer, and they were not interested in moving to a business that did not match that profile. The mission had to be credible before the conversation could progress." a composite drawn from autonomous systems VP Engineering candidate evaluation notes across our executive search.

The Autonomous Systems VP Engineering Candidate Profile

Non-negotiables

The autonomous systems VP Engineering hire needs demonstrated, senior-level leadership across both hardware and software engineering disciplines in the same role, not at separate points in their career. The distinction matters. A candidate who led software engineering for five years at a technology company and then moved into an autonomous systems business where they inherited a pre-existing hardware team has a different profile from a candidate who built and led both disciplines simultaneously from early headcount. The first has experience in hardware environments. The second has hardware leadership experience. The scorecard requires the second.

Experience building a high-performance technical organisation from a relatively early stage, rather than optimising a mature one, is the second hard requirement. Autonomous systems scale-ups at this stage are building the engineering function while shipping real products under real operating conditions. The engineering leader who has only operated inside mature engineering organisations with established processes, dedicated infrastructure teams, and stable headcount will find the first-build environment structurally different. The signals to look for: candidates who joined a business before the engineering team had formalised its structure and who were directly responsible for the architectural decisions about how the function was built, not just how it was run.

The third requirement is team scale. The scorecard for the executive search we conducted stated it explicitly: managed engineering teams of 250 or more. This is not an ego metric. It reflects the specific management surface area of an autonomous systems engineering leader role that spans hardware, software, embedded systems, and the infrastructure that connects them. A candidate who has led an engineering organisation of 50 to 80 engineers has not encountered the second-order management challenges of a 250-person organisation: the span-of-control decisions, the layer of senior technical leaders between the VP and the engineers, the culture coherence problem across teams that are now large enough to develop independent subcultures.

What Separates the Good from the Great

The strongest candidates across our evaluation had built engineering organisations at businesses that were genuinely comparable in operating model, not just in stage or sector. This meant autonomous or semi-autonomous systems businesses, businesses with physical products that were controlled by software systems, or businesses where the hardware-software integration was the core technical challenge rather than a secondary concern. The candidate who built the engineering organisation at a delivery robotics company, an electric vehicle start-up, or a drone logistics business has encountered the specific management challenges of the role. The candidate who built an excellent engineering organisation at a consumer fintech or marketplace business has not.

Mission alignment was the second consistent differentiator. The strongest profiles in our evaluation were not simply interested in the opportunity. They were already engaged with the problem space. They had followed the business, had opinions about its technical direction, and could articulate why the work mattered in operational terms, not just in vision terms. In a category where the product is a physical system operating in the real world, the robotics VP Engineering or defence AI VP Engineering who sees the work as a career move rather than as a mission-driven technical challenge will find recruiting and retaining engineers who have multiple options significantly harder. The engineering talent in this space is not primarily motivated by compensation. They are motivated by the quality of the technical problem and the credibility of the leadership that is working on it.

Red Flags

Autonomous systems VP Engineering candidates from large consumer technology companies who describe their hardware experience as "working with hardware teams" or "managing a team with hardware components" are giving a precise signal about the depth of their engagement. In a business where the hardware engineering function is as large and as critical as the software engineering function, the engineering leader who relates to hardware as an adjacent domain they collaborate with, rather than a domain they personally understand and can technically evaluate, will struggle to make good hiring, promotion, and architectural decisions on that side of the organisation. The software engineering instinct will dominate every trade-off, and trade-offs between hardware and software timelines and cost structures are constant.

Candidates from automotive OEM engineering backgrounds who have managed very large teams present the mirror risk. They bring credibility and genuine hardware depth. The gap that surfaces consistently is speed and build culture. Large OEM engineering organisations operate at a timescale and with a process rigour that does not transfer cleanly to a venture-backed autonomous systems scale-up shipping on a 12-week product cycle with a fraction of the specialist support infrastructure. The candidate from this background will instinctively reach for process solutions that the organisation cannot yet support and may slow down the engineering team at the moment when speed matters most.

"We had candidates who were genuinely exceptional in one dimension. Software leaders who had built engineering organisations of 400 people at some of the best technology companies in Europe. Hardware leaders who had managed vehicle engineering programmes of real scale and complexity. When you put the full scorecard in front of them, the same gap appeared every time. The hardware leaders wanted process and rigour and dedicated testing infrastructure that the business could not give them yet. The software leaders wanted to organise the hardware teams the same way they organised software squads. Neither of those instincts is wrong. They are just wrong for this specific moment at this specific business." a composite from autonomous systems VP Engineering candidate debrief notes.

Where the Talent Is

The autonomous systems engineering leader talent pool is small and highly concentrated. The primary feeder businesses are comparable autonomous or semi-autonomous systems companies: electric vehicle scale-ups, delivery robotics businesses, drone logistics platforms, autonomous freight operators, and defence AI businesses that have themselves reached the 150 to 400 engineer scale. The candidates who have led engineering at these businesses have the dual-discipline leadership experience the role requires. They are also almost always employed, often with equity that has not yet vested, and actively working on problems they find meaningful. The executive search that draws only from inbound applications or from visible candidates will reach a fraction of this pool.

Adjacent pools include aerospace businesses with strong software integration practices, and industrial automation companies where the software engineering function has grown to parity with the hardware engineering function. The candidates from these environments bring the hardware credibility without the consumer-tech software culture assumption. They require more evaluation on the scale-up build dimension but are consistently stronger on the technical integration dimension than candidates from pure software backgrounds.

The European autonomous systems talent market is geographically concentrated in a way that shapes the executive search significantly. Stockholm, Munich, and Eindhoven produce disproportionate numbers of qualified candidates, reflecting the clusters of automotive, industrial, and autonomous systems businesses in those markets. London and Berlin produce strong software engineering leaders and relatively fewer candidates with genuine hardware leadership depth at the required scale. An executive search that focuses geographically on the most visible markets will systematically undersample the strongest part of the available pool. Our executive search work across European autonomous systems and deep tech scale-ups maps the target company universe against the specific dual-discipline requirement before the sourcing begins.

Why the Autonomous Systems VP Engineering Executive Search Keeps Going Wrong

The Brief Is Written by the Software Side of the Business

The founding teams of most autonomous systems scale-ups come from software backgrounds. The CEO thought about the problem computationally first. The CTO built the first version of the autonomy stack. The investors think in software multiples. When they write the VP Engineering brief, they write the role they understand, which is the software engineering leadership role. The hardware requirements appear in the brief as experience in a hardware environment rather than as hardware leadership experience. These are not the same thing, and the brief that uses the first framing will attract a very different set of candidates than the brief that uses the second.

What works: involve the most senior hardware engineer in the business in writing the brief. Have them define what hardware leadership experience means in the context of this specific engineering organisation: the team size, the technical disciplines, the hardware development cycle, and the specific decisions the VP Engineering will make that require direct hardware understanding. That definition becomes the primary screen, not the final check.

The Scorecard Is Not Applied Until the Final Stage

The dual-discipline gap is rarely visible from a CV screen. Software engineering leaders from strong brands pass the initial filter easily. The hardware leadership criterion is tested at the interview stage, often only in the final round when the organisation has already invested significant time and energy in a candidate. The pattern across our evaluation was consistent: candidates who performed well in the first and second interviews, where the questions focused on engineering culture, team building, and strategic thinking, struggled in the late-stage conversation where the technical and operational specifics of hardware-software integration leadership were tested directly.

What works: make hardware leadership the first screen, not the last. A single, specific question in the first conversation is sufficient: can you describe an engineering decision you personally made in the last twelve months that required you to directly understand and trade off both hardware and software considerations? Candidates who have this experience answer immediately and specifically, naming the technical trade-off and the consequence. Candidates who do not answer at the organisational or cultural level, describing how they managed the relationship between hardware and software teams rather than describing a technical decision they personally owned.

The Comparable Business Test Is Not Applied to the Target Universe

VP Engineering executive searches at autonomous systems businesses typically draw the target company map from the general technology sector: large software businesses, well-known consumer technology companies, and high-growth SaaS platforms. These companies produce excellent engineering leaders. They do not produce autonomous systems engineering leaders. The target universe for this executive search needs to be built around businesses that are operationally comparable, not stage-comparable or valuation-comparable. A Series C autonomous freight company has more relevant talent in common with a Series A delivery robotics business than with a Series C fintech.

What works: build the target company map around the hardware-software integration operating model as the primary filter, not around funding stage, geography, or company size. For a robotics VP Engineering executive search, the relevant universe is businesses where the core technical product requires the simultaneous engineering of a physical system and the software that controls it. That universe is smaller and more specific than the general technology sector, and it is the right place to look. Our executive search process for autonomous systems and deep tech engineering leadership roles builds that map as the first step, before the brief is finalised.

Mission Alignment Is Underweighted in the Evaluation

The autonomous systems engineering leadership market in Europe is small enough that most of the strongest candidates know each other and know the major businesses in the space. They have opinions about the technology, the product strategy, and the competitive position. When they engage with a new opportunity, they evaluate the mission credibility of the business as carefully as they evaluate the role itself. The executive search process that treats mission alignment as a soft criterion at the end of the process, after the technical and leadership competencies have been assessed, misses the filter that matters most to the candidates who are hardest to reach. The best candidate for this role is not making a career move. They are making a mission decision. The executive search needs to be designed accordingly.

Before You Open the Executive Search

One question to ask before writing the brief: if you removed every software engineering requirement from the job description and replaced it with hardware engineering leadership requirements of equivalent specificity, would the role still make sense? If the answer is yes, the brief is ready. If the answer reveals that the hardware side of the brief was always thinner and less precisely defined than the software side, the brief needs to be rewritten before the executive search opens. The autonomous systems VP Engineering who will succeed in this role holds both with equal depth. The executive search that finds them starts from a brief that demands both with equal precision.

The Big Search partners with growth-stage and venture-backed scaling companies across Europe on executive hiring for engineering leadership roles, including VP Engineering and VP of Engineering executive searches at autonomous systems, robotics, defence AI, and deep tech hardware-software businesses. If you are opening an autonomous systems VP Engineering executive search and want to test your brief against the scorecard before you write it, we would be glad to talk.

‍