Talent intelligence teams are usually asked a version of the same question: how is this company actually organized, and where are the gaps we could hire into or sell into?
The instinct is to go looking for the org chart as though it were a document sitting somewhere. It is not. What you can build from public sources is a model of the structure, assembled from evidence, with parts you know and parts you inferred. The difference matters, because a model presented as a document is how talent mapping goes wrong.
Start with the boundary, not with the sources
This is work about people, so the constraint belongs at the front rather than in a compliance paragraph at the end.
The defensible version of talent mapping describes organizational structure: which functions exist, how deep the layers go, roughly how large teams are, where hiring is happening, which skills are concentrated where. It uses information organizations publish about themselves.
The version that gets teams in trouble builds individual dossiers: aggregating personal details about named people, collecting contact information because it was technically visible, or scraping content behind a login on a platform whose terms prohibit automation. Under GDPR and similar regimes, personal data is personal data regardless of whether it was easy to find, and “it was public” is not by itself a lawful basis.
Two practical rules keep the work clean. Collect at the role level wherever the role answers the question, because “a director of platform engineering exists and reports into infrastructure” is usually the fact you need, not who holds the post. And where you do record a named individual, because a leadership page names them, keep it to what the company itself published in that professional context, and strip everything else at ingestion.
The sources that actually carry structure
Most public-source org mapping gets built from six inputs, and they differ a lot in signal quality.
Job postings. The strongest single source, and consistently underused. Postings frequently state the reporting line outright (“reports to the VP of Data”), name the team, describe adjacent functions, and list the tools the team runs. A posting is also dated, which makes it evidence about now rather than whenever a profile was last updated. Volume by function is a good proxy for where a team is growing. Collection mechanics for this surface are covered in job-board data and labour-market intelligence.
Company leadership and team pages. Authoritative for the top two layers and usually silent below that. Worth treating as ground truth where it exists, because the company published it deliberately.
Press releases and appointment announcements. Excellent for senior changes, with dates attached. This is where you catch a reorg early, since a new function usually gets announced before it appears anywhere else.
Regulatory filings. Officers and directors in national company registries, and equivalents in public-company filings. Narrow in scope, high in reliability, and often the only verifiable source for legal-entity structure across subsidiaries.
Conference talks and technical publications. Speaker listings, published papers and patents place named specialists inside named teams, and they reveal what a company is actually building rather than what its marketing says.
Open-source and public technical activity. Organization-level repositories and contribution patterns can indicate team composition and stack. Read this at the team level, not as a per-person productivity signal.
Turn evidence into a structure
The assembly step is where discipline pays off, and it comes down to separating what you observed from what you concluded.
Layers from titles, carefully. Title conventions differ by company and by country. A “director” in one organization sits where a “senior manager” sits in another. Normalize to your own internal seniority ladder rather than trusting the words, and record the raw title alongside the normalized one.
Team size from hiring, not from headcount claims. Sustained posting volume for a function over several quarters says more about real team size and trajectory than any published figure.
Reporting lines only where stated. This is the discipline most maps abandon. If a posting says the role reports to a named function, that is an observation. If you inferred it because the titles look adjacent, that is an inference and it must be labelled as one.
Every node in the resulting structure should carry three things: the source it came from, the date it was observed, and a confidence level. A map where a filing-verified officer and a guessed reporting line look identical is a map that will eventually embarrass whoever presents it.
Org data decays faster than almost anything else
Reorganizations, departures and renamings happen continuously, and none of them generate a notification.
A talent map is accurate on the day it is built and degrading from the next one. Treat every node as an observation with a timestamp, apply an explicit staleness threshold, and re-observe on a schedule rather than building once and referring to it for a year. For fast-moving companies a quarter is already long.
The corollary is that recency should be visible to whoever uses the map. A node last confirmed eleven months ago should look different from one confirmed last week.
The collection layer
Three properties of these sources make the transport matter.
Postings and registries are geographically filtered, so a company’s German organization can be invisible from a US vantage point. If you claim international coverage, the collection has to come from those markets. Result sets are paginated, and the interesting roles are rarely on page one. And these are ordinary web surfaces with ordinary rate limits.
With the Shifter gateway, the vantage point and session go in the credentials against p.shifter.io:443:
customer-USERNAME-country-de-city-munich-sid-map-4412-ttl-600:PASSWORDcountry-de and city-munich put the request in the right market, sid-map-4412 holds one exit across a full query including its pagination, and ttl-600 keeps that address for ten minutes. One session per query rather than per request is what keeps a paginated result set internally coherent.
Cadence should be steady and modest rather than a burst, with real backoff on errors, as covered in rate limiting and request throttling. The product view of this work is on the recruitment and talent page, and the recruiting-side companion is residential proxies for recruiting and job market data.
What a public-source map cannot do
Being honest about the limits is what makes the rest credible.
It cannot prove a reporting line that nobody published. It cannot see the informal structure, which in most organizations is what actually determines decisions. It cannot tell you who has budget. And it cannot substitute for a conversation with someone inside the company, which remains the only way to learn most of what matters.
What it can do is tell you which functions exist, roughly how large and how deep they are, where hiring is concentrated, which skills cluster where, and when something changed. For most talent-intelligence and go-to-market questions, that is the useful part.
FAQ
Can I just scrape a professional network for this?
Not behind a login, and not where the terms prohibit automation. That route is also the one most likely to produce personal data you have no basis to hold. The sources above are public in a way that a logged-in profile feed is not.
How accurate can a public-source org chart get?
The top two layers are usually reliable because companies publish them. Middle layers are inference with varying confidence. Below that you are describing functions and team sizes rather than individuals, which is usually sufficient.
What is the minimum viable version?
Job postings for one company, normalized to your seniority ladder, with stated reporting lines recorded as observations and everything else as inference. That alone answers most structural questions.
How do I avoid holding personal data I do not need?
Decide at ingestion, not at storage. If the question is answered by the role, do not write the name. Strip contact details from posting text as a matter of course, since a recruiter’s phone number is never the thing you were looking for.
The bottom line
An org chart built from public sources is a model with confidence levels attached, and it is genuinely useful in that form. It becomes a liability the moment it is presented as fact or drifts into collecting people rather than describing structure.
Work at the role level, record the source and date for every node, separate observation from inference, collect from the markets the company actually operates in, and re-observe on a schedule. Rates for the collection layer are on the pricing page.