Choosing a Second Engineering Hub From the Talent Numbers

Picking the city for a second engineering team is usually done backwards. The reader here is a strategy analyst, a talent-intelligence lead, or an operator who has been handed a shortlist of cities and a cost spreadsheet. This guide carries one real decision, a 30-person automotive embedded team, all the way through a specialty-level counting procedure, with the actual searches, the intermediate head counts, the competitor overlap, and the wrong turn where the obvious city collapsed once the specialty filter went on.

The point is not to admire a finished answer. It is to give you a procedure you can run on your own two or three cities and defend line by line in a leadership review.

Why the cost-spreadsheet ranking fails

The best public answers today rank whole cities on generic parameters, and that abstraction is exactly where the money leaks. Consultancy funnels evaluate hundreds of locations down to five or ten sites, then to a top two or three, using average salary and time zone before workforce depth is ever examined at the specialty level. So a European automotive firm ends up paying a headline hub's prices for engineers who cannot do AUTOSAR.

The failure is a units mismatch. A city ranking measures the wrong thing: it counts all engineers, or all IT workers, and treats that base as if it were your hireable pool. It is not. The moment you apply the skill and seniority filter your team actually needs, the base collapses by a factor that differs wildly between cities, and the ranking inverts.

Consider the worked case. The spec is 30 automotive embedded engineers, AUTOSAR plus C/C++, roughly 60% mid-level and 40% senior. The obvious move for a European automotive firm is Germany: it is the home market, and it has by far the largest engineering base. On a cost-and-scale spreadsheet, a German metro wins before the meeting starts.

Then you apply the specialty filter, and the obvious answer wobbles.

What sources give a defensible specialty count

Four open, searchable source types recur, and each has a documented step to size the pool. Use them together; no single one is trustworthy alone, and the point of cross-checking is that a real signal shows up in more than one.

• Professional-network headcount, filtered by skill and city. This is the base layer. The public Sequoia Atlas method is explicit about it: roughly 3 million software engineers across Europe, analysed across 14 skill areas, over the 50 largest engineering hubs, with the top 15 cities shown per skill. The step is to start broad and apply skill, then seniority, then language filters, each as a multiplier.
• University output. TUM reports around 14,000 new students enrolling each year across about 180 programs, with total enrolment over 48,000 and 38% international. Graduate flow feeds the base, but slowly, for reasons in the failure section.
• Employer R&D-center headcount, as a proxy for installed specialty depth. Aptiv's Kraków Technical Center runs more than 3,100 employees including 1,600 engineers, its most extensive R&D facility worldwide. A large, long-tenured center concentrates specialists and ages the local pool upward.
• Interview-performance panels. Karat measures engineering talent from performance data across more than 600,000 real technical interviews, focused on problem-solving, coding, and system design, which is how it ranks cities by the share of candidates in the global top quartile.

The stack matters because your team competes for the bottom layer, not the top. A city can be enormous at the top and starved at the bottom.

The specialty count, city by city

Here is where the case turns. Germany holds six times Poland's embedded/AUTOSAR pool, yet Poland's senior share is denser. This is not a rounding artifact; it flips the recommendation.

In Refolk's index of professional profiles, the embedded/AUTOSAR pool with a senior tag is 19.9% of the total embedded/AUTOSAR pool in Germany and 33.5% in Poland. The raw counts sit behind those percentages.

Table A. Specialty pool by country and seniority (embedded/AUTOSAR)

Columns one to three come from Refolk's index; column four is derived as senior over total. Poland's total pool is 15.6% of Germany's, but its senior share is far denser.

The mechanism behind the inversion is visible in the employer data. Mature offshore R&D centers such as Aptiv's 1,600-engineer Kraków center concentrate long-tenured specialists, aging the local pool upward. Germany's much larger base is diluted by juniors and adjacent roles that pass a loose title filter but not a skill filter. So the country that loses on scale wins on the metric your senior slots actually draw from.

The larger pool is not the denser one, and density is what a senior slot draws from.

One caution that this table forces immediately: these are national figures. Within Germany, Munich is the top region for this pool in Refolk's index; within Poland, Kraków and Wrocław lead. You cannot credit Munich with all 4,378 of Germany's senior profiles. Constrain to the metro before you decide, or you will overstate every candidate city.

The number that actually binds: churn flow

The pool you can see is not the pool you can hire. Almost everyone in it is employed and not moving. The binding constraint is annual churn flow, and it is where a deep-looking market fails.

European tech attrition averaged 17.4%, but by function engineering is the lowest at 12%, while operations runs highest at 21%. If you apply the blended 17.4% you overpredict engineering churn and inflate your available movers. Use the function-specific 12%.

Table B. Annual churn-available senior candidates (engineering attrition 12%)

Senior pool from Refolk's index; the 12% rate from public European compensation data; the final two columns derived. A higher percentage means a harder single-year fill.

Read Table B against Table A and the story completes. Poland won on density, but density buys you a small senior pool in absolute terms, and 12% of a small pool is a thin annual flow. A 30-person team is 21.7% of Poland's entire senior churn flow for the year. That is a red flag: you would be trying to absorb more than a fifth of every senior embedded specialist who changes jobs in the country, in a single year, in one metro.

Germany's larger base makes the same team 5.7% of flow, which is comfortable, but its lower senior density means more sourcing effort per hire and more junior dilution to sift. Neither is a clean win. That tension is the real output of the analysis, and it is exactly what the cost spreadsheet hides.

For the counting layers above the funnel, running the skill and seniority filters by hand across a professional network is slow and inconsistent between analysts. Refolk lets you express the whole spec in plain English and get the metro-level specialty pool back in one query, so the survival fraction in Table A is reproducible rather than an artifact of who ran the search.

Reading saturation and competing employers

Time-to-fill is the earliest saturation alarm, and it moves before salary does. Posted roles accumulate faster than the specialty pool regenerates, so an unfillable market shows up as stalled requisitions long before the pay signal reacts.

In Kraków, a Senior Cloud Architect role typically stays unfilled 95 to 120 days, and AI/ML engineering roles show a 78% failure-to-fill rate after 90 days. Those are not automotive embedded numbers, but they read the same climate: a hub where installed employers have already bid the senior tail scarce. Karat notes AI-skill markets where OpenAI, Microsoft, Amazon, Anthropic and others recruit from the same limited pool, and the same clustering that makes a hub attractive multiplies the employers bidding for each senior specialist.

To turn this into a decision input, map the named employers with installed specialty headcount in the metro and estimate their combined draw against your annual flow.

Table C. Destination-market talent base and saturation signals

Base figures from public Małopolska sector data and Refolk's index; employer figures from company sources; time-to-fill from a Kraków IT market report.

Two honest gaps sit in that table. Munich's time-to-fill for automotive embedded is not established publicly, so I mark it rather than invent it; you would source it locally from your own requisition data or a recruiter panel. And the Bosch figure is Germany-wide, not Munich, so it overstates local pressure if used carelessly. Both cells are more useful as a marked gap than as a confident fabrication.

The procedure, end to end

Run these seven steps on every candidate city, identically, so the numbers are comparable. Owners and rough durations are noted so you can plan the work; the whole pass for two or three cities is a few analyst-days.

One live disagreement worth naming at step four: consultancy funnels narrow geography first, then workforce, while talent-first practitioners like the Sequoia Atlas filter by skill before ranking cities at all. This teardown sides with skill-first, because the whole failure of the cost spreadsheet is that it ranked geography before it ever looked at the specialty. Order the filters skill, then seniority, then language, and let the surviving count pick the city.

SPEC: 30 automotive embedded engineers | skills: AUTOSAR, C/C++ | seniority: 40% senior, 60% mid | language: German or Polish | metro: [one metro per pass]
BASE SEARCH: all embedded OR software engineers in [metro]
SPECIALTY SEARCH: embedded engineers in [metro] with AUTOSAR and C/C++
SENIOR SEARCH: senior embedded engineers in [metro] with AUTOSAR and C/C++, 5+ years
RECORD PER METRO: base count / specialty count / survival % / senior count / senior survival % / source / date

How this goes wrong

This is the most valuable part of the analysis, because every failure here is one that produces a confident wrong answer rather than an obvious blank. Each has a check.

• Aggregate headcount masks a split market. Kraków's 105,000 IT workers looks deep, but the market splits: mid-level Java is available, senior specialists are not. Check: always report the senior and specialty count, never the raw base.
• Counting a title, not a skill. A "software engineer" filter catches web developers who cannot do AUTOSAR. Check: require the skill keyword and confirm the survival fraction drops, because it should.
• Ignoring installed-employer demand. A large pool ringed by Bosch, Continental, and Aptiv is functionally locked, showing a big base with near-zero movers. Check: compare team size to churn flow in Table B, not to the static pool.
• Treating graduates as immediately hireable. Only 35% of entry-level advanced R&D roles fill from local graduates without certification. Check: discount graduate output by an onboarding-readiness factor before adding it to flow.
• Averaging city attrition instead of function attrition. Using 17.4% overpredicts engineering churn; engineering is 12%. Check: use the function-specific rate.
• Country numbers used as city numbers. Refolk's index totals are national; only the region breakdown localises them. Crediting Munich with all 4,378 of Germany's senior profiles is a false positive. Check: constrain to the metro region before deciding.
• The obvious hub collapses under the specialty filter. A city that wins on raw base can lose on senior-specialty density, exactly as Poland's 33.5% senior survival beats Germany's 19.9% despite a six-times-smaller pool. Check: never let the base number stand as the conclusion.

Two limits I will state plainly rather than paper over. First, no published body sets a universal go/no-go multiple of pool to hire, so the 21.7% threshold above is a judgement, not a standard; treat any city near or above a fifth of annual flow as a warning to investigate, not an automatic reject. Second, the senior tag in the index is a signal of tenure and title, not a guarantee of AUTOSAR depth, so confirm the top of any shortlist against public work before you commit budget.

Before you call the decision defensible

Run this checklist against your finished workbook. If any item fails, the number in your recommendation is not yet reproducible.

Keeping the analysis current

Three of these numbers move, and each has a mechanism you re-check rather than a value you memorise. Attrition drifts with the labour market, so re-pull the engineering function rate before any decision rather than reusing last cycle's figure. Installed-employer headcount changes when an R&D center expands or contracts, which shifts both the density and the competition, so re-scan the anchor employers in each metro. And the specialty pool itself grows and ages, so re-run the base, specialty, and senior counts fresh for the metros on your shortlist rather than trusting a cached number.

The durable output is not the recommendation; it is the workbook. When the case reopens next year, you re-run the same seven steps with the same filter string, and the only thing that changes is the counts. That is what makes a hub decision survive a leadership review: not a slide that ranks cities, but a procedure that anyone on the team can re-run and land in the same place.