# Choosing a Second Engineering Hub From the Talent Numbers

*You can carry one real role through five cities and produce a ranked short list with a defensible hireable-pool count, demand pressure, and supply-growth read for each.*

- Canonical URL: https://www.refolk.ai/guides/choosing-second-engineering-hub
- Pillar: Market and talent intelligence
- Format: Teardown
- Published: 2026-09-04
- Last reviewed: 2026-09-04
- Reading time: 6 min

You need to open a second engineering team, and someone has to decide where. The cost spreadsheet is easy and it is also the wrong first question. This guide is for strategy and talent-intelligence analysts sizing a market for one specific role, and it carries a single real role through five candidate cities to a ranked short list you can defend on the numbers. The worked example is a Rust backend engineer. Substitute your own role and the method holds.

Every public answer to "which city" is a vendor leaderboard that ranks the same famous cities for a generic "software engineer" and stops. Those rankings are built for someone else. What follows is the opposite: how to size your own role in your own candidate cities, discount the raw count into something hireable, read the competitor pressure, and end with one pick a leadership review can challenge and you can hold.

## Why a city leaderboard cannot answer your question

A published tech-talent ranking scores a generic occupation for famous cities; your decision is one specific role in the cities you can actually staff. The two are not the same measurement, and confusing them is the most common way this job goes wrong.

CBRE categorizes any market with a tech-talent labor pool above 50,000 workers as "large," and below that as "small." That is a useful frame for real estate, but it counts the whole occupation. Cushman & Wakefield found that Paris has more than twice the technology workers of Chicago but less than half as many computer programmers. So "big tech market" and "deep in the role you are hiring" diverge routinely, and a leaderboard cannot tell you which way yours diverges. Worse, the marquee markets churn: New York overtook the SF Bay Area as the largest US tech-talent market not because New York exploded but because the Bay Area contracted 23,900 workers between 2022 and 2025 while New York added 30,640.

> A large market can be the least hireable one, because concentration hides inside the total.

The fix is to measure three things per city for your exact role: how many people plausibly hold the skill, how locked that pool is to existing employers, and which direction local supply is moving. The rest of this guide is how to produce those three numbers and rank on them.

## The worked example: one Rust role across four markets

The role is a mid-to-senior Rust backend engineer, and I am carrying it across the United States, the United Kingdom, Germany, and Canada. Here is the raw skill-in-market pool from Refolk's index, which counts profiles with the title Software or Backend Engineer and the skill Rust.

| Country | Pool count | Index vs Canada |
|---|---|---|
| United States | 608 | 8.7x |
| United Kingdom | 117 | 1.67x |
| Germany | 89 | 1.27x |
| Canada | 70 | 1.0x |

**608 - Rust backend engineers in the US pool (Refolk's index)**

The largest raw pool, but raw pool is a ceiling, not a hireable count.

Read this the way a leaderboard would and the US wins by a mile, with the UK a clear second. That read is wrong, and the next two sections show why. The number you carry forward is not the pool. It is the pool minus everyone you cannot realistically reach, and that haircut is set by who already employs them.

One note on geography before you go further. Refolk's index counts by country here for illustration, but for a hub decision you run the identical skill query at city level (the example queries later name Toronto, Berlin, Vancouver, Austin, and non-London UK). Keep the geography definition consistent, because a professional-network city filter, a GitHub city, and a BLS metro are three different shapes of the same word.

## Bounding the real count between a floor and a ceiling

No single source gives you the true count, so use two with opposite biases and read the truth between them. A professional-network skill filter is your ceiling; a GitHub location-plus-language count is your floor.

The network filter over-counts for two reasons. It treats query terms as AND against self-reported profiles, so it keeps people who listed a skill they no longer use and drops people who omit one they use daily. A single Java-stack query run with AND operators returned a little over 200,000 professionals globally and about 57,000 in the United States, and a large share of any such headline is stale. GitHub does the reverse. It is concrete for a named language, but only around 15% of accounts have a location in their profile, and only about 9% of GitHub users carry a country code in the archived graph. So a raw GitHub city count can run five to seven times low. The GitHub Innovation Graph will only report an economy's metric when 100 or more unique developers perform the activity, which tells you the floor is genuinely a floor.

BLS OEWS is the third leg, but treat it as a sanity ceiling, not a skill count. The program covers over 800 occupations with national, state, and metro estimates, and the software developers occupation (SOC 15-1252) had a 2025 national median annual wage of $132,684. That occupation counts every developer in the metro, not your language, so a huge metro figure can sit on top of almost none of your specialty. Use it to catch impossibilities, not to size the pool.

#### The three-source sandwich for a skill count

1. **BLS occupation (SOC 15-1252)** - whole developer occupation in the metro, a hard ceiling on everything
2. **Network skill filter** - largest count, over-counts stale self-reported skills
3. **GitHub location+language** - concrete but ~15% carry a location, so a floor

*GitHub floors the count, the network filter ceilings it, and BLS bounds the whole occupation above.*

> **Rule:** Two sources or the number does not ship
>
> Never carry a single-source pool count into a hub decision. Report a network count and a GitHub count for every city, note the divergence, and treat the gap itself as a data-quality signal.

## Turning a raw count into a hireable pool

The hireable pool is raw supply minus the share locked to existing employers, and the size of that haircut comes from named-employer concentration, not a guess. This is the step every leaderboard skips and the one that flips the ranking.

The opportunity to hire in a market is set not just by supply but by how many other employers target the same base and at what volume. Refolk's index adds the signal the public indices miss: the named current employers holding the skill pool, so you see concentration directly rather than inferring it. Here is that read on a 25-profile sample per market.

| Market | Top current employer | Count in sample | Share of sample |
|---|---|---|---|
| United Kingdom | Meta | 14 | 56% |
| United States | Google | 4 | 16% |
| Canada | AWS | 4 | 16% |
| Germany | Helsing | 2 | 8% |

Now the UK number reads differently. The headline UK pool was 117, larger than Canada's 70. But 14 of 25 sampled UK profiles sit at one employer. Hiring against a single anchor is slow and expensive, because that anchor sets the local wage and the lock-in. After a haircut sized to 56% concentration, the accessible non-Meta UK pool plausibly drops below Canada's more distributed 70. The German pool (89) has the flattest concentration in the sample at 8%, which makes more of it reachable than its raw rank suggests.

```stat
number: 56%
label: Share of the sampled UK Rust pool sitting at one employer
note: A single-anchor market where the accessible pool is far smaller than the headline count.

## Frequently asked questions

### How do I count software engineers in a city for one specific skill?

Use two sources with opposite biases and read the truth between them. A professional-network skill filter over-counts because it treats terms as AND and includes stale self-reported skills. A GitHub location-plus-language count under-counts badly because only around 15% of accounts list a location. Treat GitHub as a floor and the network count as a ceiling, then narrow to a hireable pool by subtracting an employer-lock haircut.

### Why not just use a published tech-talent city ranking?

Because those rankings score a generic 'software engineer' for famous cities, not your role in your candidate cities. CBRE's threshold calls any market above 50,000 tech workers 'large', but that total says nothing about how many hold your specific skill or how many rivals already employ them. A ranking built for someone else cannot be defended to your leadership review; a sized-per-role count can.

### How big does a hireable pool need to be to open a hub?

There is no universal number, and I would not pretend otherwise. CBRE categorizes markets above 50,000 tech workers as 'large', but that is a whole-occupation figure, not your skill. Set a per-role floor against your hiring plan: if you need to fill six seats in a year, a hireable pool in the low hundreds after the employer-lock haircut is defensible, while a pool of a few dozen is not.

### How do I account for competitors hiring the same people?

Two signals. First, a job-posting intensity or tightness read tells you demand pressure on the occupation. Second, and more directly, the named current employers holding the skill locally reveal concentration. In a 25-profile UK Rust sample, 14 sat at Meta, meaning the accessible non-anchor pool was a fraction of the headline count. Size the haircut to that concentration.

### Should I rule out a city if the exact skill pool is thin?

Not automatically. A rigid skill filter can rule out a strong adjacent pool that a short ramp would close. Before dropping a city, check whether an adjacent-language pool plus training time beats a thin exact-match pool elsewhere. Treat the skill as trainable unless your hiring lead confirms it is genuinely fixed for the role.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/choosing-second-engineering-hub*