Who’s Who in the Zoo?: A Practical Guide to Federal Workforce Data
There are many reasons why you might want to get a sense of who the civil servants at a particular agency are and what they do. Maybe you’re newly in leadership and trying to better understand the folks you’re overseeing. Maybe you’ve been tasked with counting and describing your agency’s technical workforce, or you need to talk to some coders to understand their tech needs. Or maybe you’re a job seeker wanting to know what agencies have people who do the kind of work you do and how they pay.
While I was detailed to data workforce efforts at the Army, I realized that it's not always obvious what data is available, and what’s available isn’t always useful. In this guide, I’ll walk you through your options for understanding the federal civil servant workforce, from public data to internal systems to ad-hoc solutions for when nothing else quite fits.
A Quick Note About Occupational Series and Job Title
Most civilian executive-branch federal employees—not contractors or uniformed service members—are classified by occupational series based on their job’s duties and qualifications. There’s a big book describing these occupational series, and most analysis of federal jobs—for instance, anything about technical hiring – relies on disaggregating employees by this variable. In other words, typically when we talk about what jobs federal employees have, we’re talking about this four-digit code.
But is occupational series ‘what someone does’? Will it fully answer your questions? In some cases, sure: if someone is in the dental hygienist or the electrical engineer occupational series, their occupational series is likely also a rough description of their duties. But there are a lot of occupations where job series are broad and, in practice, overlapping.
Take a data scientist, for instance. You might think they'd all be classified under the Data Science occupational series (1560). But in reality, you'll find data scientists spread across multiple series codes—they might be classified as IT Specialists (2210), Operations Research Analysts (1515), or Statisticians (1530). Each of these series can contain data scientists doing very similar work, just classified differently. Counting just the 1560s will miss those folks—but including all of those occupational series will lead to a significant overcount.
In some data sets, you’ll also see a title field, which is the official position title. Each occupational series has certain authorized job titles. Sometimes these are limited to the overall occupational series (like "Computer Scientist") or, for supervisory roles, the prefix "Supervisory" added to the basic title (like "Supervisory Computer Scientist.”) Within other occupational series, there is more flexibility, like multiple different titles and parentheticals to more accurately reflect the specific duties of a position—for instance, Management Analyst (Data Analytics). Agencies may or may not choose to use these parentheticals.
So in some cases, this title field doesn’t provide much additional information beyond occupational series, whereas other times it might. And this official title field is distinct from what OPM calls “organizational and functional titles”, or the kinds of titles people sometimes put on LinkedIn or in their e-mail signatures and that more closely describe what they actually do. For instance, my official job title is IT Specialist, stemming from my occupational series, but the title I actually use is Machine Learning Engineer, which doesn't exist as an official title for any occupational series.
Both occupational series and official title are useful – but you should know what the limitations are. In some cases, like with data scientists, you'll find some people who match what you're looking for, but it won't be complete. In other cases, like with Machine Learning Engineers, you won't find anyone, even though we do exist.
Public Data Sources
While public data is useful for people who can’t access internal data, it’s also valuable even if you work at or with the agency you’re researching. This is because finding the person who has access to internal data and obtaining it within your desired timeline may not be trivial. Pulling the public data also gives you more control over what you’re getting and more ability to quickly iterate if you need additional fields or additional years.
FedScope: The Most Comprehensive Public Data
FedScope offers the most comprehensive public data about federal employees, including agency, occupational series, length of service, age range, gender, education level, supervisory status, and more. You can see how these factors intersect— want to know the education level of IT specialists in your agency? Or the age distribution of recent hires? FedScope can tell you.
In addition to quarterly snapshot data, there’s also annual separation and accession (leaving and hiring) data. You can track not just how many people are leaving, but whether they’re retiring, transferring between agencies, or leaving the civil service. For hiring, you can see what kinds of positions you’re filling and the characteristics of new hires.
The data is typically a quarter or two behind, and longer for separation and accessions. But even if you might need more up-to-date or detailed data from your agency, the public data can get you started on understanding these data fields and determining whether you need more.
There are two ways to interact with the data. First, there are raw data tables you can download and analyze yourself. You can do this solely in Excel, but because of its structure—one main table, many lookup tables—I would suggest you instead write code to merge and clean it. There’s also a drag-and-drop interface that I find cumbersome, but does contain variables that are not available in the raw data, like veteran status, disability, and telework eligibility—and you can download the aggregated results of your analysis.
The main limitation? It’s anonymous, so you can count people but not use it to find them afterwards.
FedsDataCenter: Limited Data, But Has Names
FedsDataCenter is a website that contains annual FOIA’d data on government employees in its Search Federal Employee Salaries tool. The data is less recent than FedScope, isn’t comprehensive (many agencies are not included), is far less detailed, and you can’t download any data sets.
Its advantage? It has names in it. This means you can search by agency and occupation and find the actual names of the people in each occupation, which is useful if you need to contact someone. You can also search by name if you’re trying to figure out what a particular individual does. Finally, you can see multiple years of data for the same person, if they were at a federal agency that is in this data set at the time of the data disclosure.
As a note, in some years the occupation field contains official title data rather than occupational series, which is what’s in the FedScope occupation field. I believe the most recent occupation data is just occupational series, but that’s based on spot checking it, since I can’t download the whole data set.
USAJobs: What They’re Advertising For
USAJobs is where most executive agency jobs are listed. It contains not just occupations and job titles that agencies are posting for, but also more detailed qualifications and job descriptions than you can get from the earlier data sets. It can't tell you what civil servants are doing, exactly—but it can tell you what they're trying to hire for.
There are two USAJobs APIs: the current jobs API and the historical API. You may also supplement the APIs by scraping data from the USAJobs site itself. This is particularly useful if you're using the historical jobs API, which doesn't contain quite as much about the listing—but does have some additional info about search outcome, as well as about applicant numbers from agencies that choose to make this available.
USAJobs has a couple of limitations. Some agencies use their own hiring systems instead of USAJobs, so their data isn't included. The USAJobs outcome data is limited too: you can't see how many offers were made or accepted from any posting. And perhaps most importantly, the duties described in listings often end up being quite different from the day-to-day work.
Internal HR Data
If you do actually sit at the agency you’re researching—or they’re your client, or you’re overseeing them—there are a various official data sources that can tell you more about what folks do there.
The Personnel Database: Comprehensive Internal Data
Somewhere in your agency, there’s a personnel database. This contains the “faces” data, or the data on actual people, as distinct from the “spaces” data, or the positions that are authorized but may not actually be filled. It has everything you’d find in FedScope, plus names. You might also find additional fields like manager, awards history, training completions, and field of study. And unlike FedScope’s quarterly updates, this database provides current, up-to-date information.
But you’ll still run into the same issues as before—the occupational series and job title fields are only as useful as what’s actually in them.
Position Descriptions: “What They Do” Details
Executive agency employees have Position Descriptions, or PDs. A PD is supposed to describe in detail what a person actually does in their job, and will typically describe both major duties and what categories they’re being rated on in terms of performance. Getting PDs can be a great way of obtaining more information about what people actually do.
However, these come with a different set of limitations. They’re often outdated or are used for everyone in a particular occupation in that office, even if there’s variation in what those people do. Because of this, they may not match actual duties. For instance, if you’re looking for someone who does data engineering or works in a particular programming language, that kind of information may be on some agency PDs, but you should not expect that it will be comprehensive. That is, this could be useful as a way of finding someone with those duties, but it will not find you everyone in those duties.
If you go down this route and request the data, you may receive a spreadsheet with PD text, or you might get a stack of PDFs with the actual PDs plus a spreadsheet with a list of employees and the PD numbers associated with their PDs.
Unofficial Data Sources
Sometimes, the only way to get the data that you’re looking for is to go outside of what’s typically considered a data source.
Outlook Directory: Unofficial Job Titles
Remember how I mentioned organizational and functional titles that are distinct from official titles? In some cases, people put those more-descriptive unofficial titles in their Outlook profiles—and if you’re at the agency you’re interested in, you might consider extracting that data. However, there are a few caveats about treating this as a data source:
This field lacks consistency. Some people update it, some people don’t. This likely varies significantly by agency. Like with PD, this is a way of finding some people with a particular role, not all people with a particular role.
If you’re not interested in contractors, you’ll have to figure out how to filter them out.
Pulling this at scale from Outlook will be dependent on your specific IT setup. That is, if what you want is an actual data set with everyone with certain titles, you may have to work for it. I’ve tried to pull this programmatically using PowerShell at two different agencies, and struck out both times. What I wound up doing was instead searching, adding people to my address book, and then downloading that as the data set to use. You might also explore if there’s a Microsoft Teams API you can pull this info out of, but you should make sure this is not a security violation.
LinkedIn: Data Grab Bag
LinkedIn can be powerful for understanding who does what, despite three major limitations:
Many people aren’t on it, or don’t list much info about what they do.
It can be difficult to tell who is a contractor and who is a civil servant.
You not only will likely struggle to pull data at scale, if you actually do it, you will definitely be violating LinkedIn’s terms of service and they may ban you.
That said, if you’re interested in questions like “where are we hiring our data scientists from” or even “can I find someone who knows a particular engineering tool”, as bad as LinkedIn is for this, doing manual searches and then copying and pasting the results may be your best option.
There are also queries/situations where it would make sense to actually work with LinkedIn and get a data pull, but I haven’t done that and it would be a pretty specialized question you’d be asking where this would make sense.
Conclusion: What We Can Answer With Data and What We Can’t
What questions can we answer with these data sets? What can’t we answer? Let's revisit our initial scenarios and what we can learn from each data source:
New Leadership: Official data will show you your workforce structure—occupations, grade levels, titles, and turnover patterns. But all this formal data won't reveal what your people actually do day-to-day.
Technical Workforce Count: You can identify everyone in technical occupational series, but this approach has blind spots. You won't catch the developer who's classified as a Program Analyst, or distinguish between the IT Specialist who codes and the one who manages projects.
Finding Coders: While occupational series data gives you a starting point, you'll likely need to get creative. LinkedIn and Outlook titles can supplement or replace official sources (along with FedsDataCenter) if you can't access internal data. Don't forget system access lists—pulling user data from your agency's GitLab or other tools developers use can help identify them as well.
Job Hunting Research: FedScope shows which agencies hire your target job series and their pay ranges. USAJobs adds detail about qualifications and typical duties—but remember that these duties are often generic or inaccurate. Plus, you might miss listings at agencies that don't use USAJobs for hiring.
The core challenge across all these scenarios is that official data sources—whether public or internal—struggle to capture what people actually do, especially in technical roles where job duties evolve faster than official documentation, and where similar work gets classified differently across or even within agencies.
Also, if you think this is needlessly complicated, it's much simpler than understanding the federal contractor workforce, where there are no standardized or centralized data sources!
Beyond Understanding Roles: Other Useful Federal Workforce Data
I wanted to keep this post narrowly focused on “what people do” data, but here’s a quick rundown of some other public data sets that may interest you. These are all able to be downloaded as spreadsheets without coding.
The Plum Book (Periodically Listing Updates to Management) tracks political appointees across the government. Agencies must update it at least annually, and it gives you a snapshot of each agency’s political leadership layer, with basic info like names, job titles, and sometimes pay levels.
The Federal Employee Viewpoint Survey (FEVS) is an annual survey that asks federal employees what they think about their jobs, their agencies, and their work environment. OPM releases public datasets from this each year that let you slice the data by agency and some demographic factors.
The Federal Hiring and Selection Outcomes dataset tracks how agencies are doing their hiring—everything from what assessment tools they’re using to how many people make it through each stage of the process. It covers the biggest agencies and includes details about hiring outcomes that you won’t find in the USAJobs API. This is also annual.
And if you want even more data, OPM has some additional personnel data, and data.gov has a huge range of data on many topics, including some personnel data sets from specific agencies.