I’ve seen a lot of articles around the “why” of people analytics, and an encouraging trend of articles on the “how” of data science for People Analytics, but there are not many articles exploring the operation of a People Analytics function. I think this is a critical time to dig into that space, namely because I see trends happening across People Analytics that indicate many teams are on the verge of a shift in their operating model.
In this three part series I’m going to touch on the initial operating model that launched many People Analytics teams, go deep on the service operating model that many teams operate under today, and lay out a framework for the next phase of operation, the platform operating model.
Please review the arguments and ideas below with a grain of salt and take what you find useful to fuel your own understanding of the trends out there. I’m really looking forward to the dialogue (comments, criticisms, and questions) in the comments after the article.
Initial Operating Model
While some parts of the PA function date back to the 40s (IO psych), the 2000s saw people recruited for the first time into formal HR analytics, employee insights, or People Analytics “functions”. I put “functions” in quotes because these early teams largely had budgets for just one person or if they were lucky two people. These early functions did full-service and white-glove People Analytics. They tackled everything from data collection, to cleaning, to reporting, to partnering, and even doing start to finish research projects.
For small teams or new teams, this operating model is defined by the all-in-one leader who wears every hat within People Analytics. This is where almost all teams start (you have to start with one hire) and I’ve heard that teams that operate under this model are still one of the best ways to quickly learn about all aspects of the People Analytics space.
While those first ten years of the function were defined by lean teams, there were a few super teams emerging (Google’s People Operations / People Analytics group as detailed in “Work Rules”) and the investment across other companies started to open up. Over the next decade full functions began to spring up from these all-in-one teams.
The Service function
From those teams of one, the operating model I’ve seen most teams grow into over the next decade (2010–2020) ends up with loose sub-functions of what I’m calling reporting, partnership, research, and operations. Reporting being a front-line team to generate custom and scaled reports, partnership refers to client-based decision support, research tackles the deep-dive gnarly problems that requires the PhDs and heavy data scientists, and the smallest investment being operations which does the… drum roll… operation of the function (project management, tooling, and sometimes HRIS).
If I’m being quick here in describing this arrangement of the function, it’s because many other people have talked through this model. I also imagine for most readers who are going to find this article, you’re at least a little familiar with this model since it has become a fairly wide-spread across the field.
For the curious, from what I’ve seen there seems to be two commons paths that those all-in-one teams to grow into this model:
An HRIS reporting analyst starts getting more and more requests so a formal reporting function is developed to make sense of incoming requests and to standardise output and quality of reports.
As that reporting function gets more sophisticated, researchers are brought on to tackle the harder problems that start to appear.
Executives eventually make more and more specific requests and require a different white-glove approach than most PhDs or data people are trained in, and so consultants are brought in as analytics partners.
Once the team scales, an operations group is developed to operate inner workings of the function or to support technology roll-out across the team (Tableau, Visier, etc).
A talent, engagement, IO Psych, or survey function of 1–2 people starts getting more and more requests for complicated downstream analysis
They bring on more researchers and eventually start to partner closer with other HR and business functions,
As more executives require analytics support, the team brings on consultants or research program managers to support the researchers.
Eventually, the function builds a strong reputation as the go-to resource for HR data, but in order to protect the researchers from all data requests, they build a reporting function as a first line of defence to tackle incoming requests.
Operations again appears last to help stabilise the function and manage projects across the team.
There are many other ways to get to the service model, but these two paths are the most common that I’ve seen (lately I’ve even seen HR teams roll out a full budget and plan to grow up front). This could be a natural equilibrium for the PA function with the reporting team protecting researchers and delivering scalable insights, the analytics partners coordinating resources to strategic places and advising key leaders with white-glove support, and the researchers delivering on big bets, while operations supports the team as a whole.
Alternatively, maybe this seemingly “natural” structure is the result of a tight-knit PA community with leaders supporting each other, sharing notes, and frequently jumping between companies to set up teams. Either way, this operating model has proliferated and served People Analytics well.
I would categorise this operating model as a service function. Sometimes people recoil to the word “service” as sounding less strategic, but I would push back on that. From how I see it, there are clients inside HR (and in mature teams also outside of HR) who need help with decisions related to the workforce and the People Analytics function provides a service in the form of generating data, reports, analysis, or research to support decision making. This is still a highly strategic function, but we have to acknowledge the work is being done based on client needs. There may be independent research being done within PA separate from client requests, but ultimately that research always needs to get into the hands of a client to influence the business.
The thing about service functions is that they are inherently dependent on their human capital. If you want to scale support, you’ll need more people. Many PA functions have found this out quickly as demand for work rapidly outpaces supply of talent (more on this later). Ideally there’s a ratio greater than 1:1 for clients supported and members of the People Analytics team (e.g. one partner could support multiple leaders or one researcher could support L&D research), but for VIP clients (CHRO, head of recruiting, etc) there might need to be a 1:1 or greater level of support for partnership which starts to get heavy over time.
I’m also just talking about the People Analytics function at its core, as many teams may own People Analytics + other HR functions. I’ve seen PA combined with HR strategy, HR tech, Workforce Planning, Talent, or Compensation, and in those cases it’s a credit to that leader to manage multiple functions. In that framework that whole super-function might provide more of a hybrid service support and operational ownership, but if you can separate the People Analytics work from other functions, People Analytics operates as a service function with SME individuals serving clients who need decision support.
You might be saying “Richard, this operating model seems like it’s working”, “Richard, that sounds great!” or “Richard, you’re out of your mind. We would kill someone if we could get the investment required to build the function as you described”, and you’re absolutely right (except there are better, albeit slower, ways to get that investment before resorting to violence).
The People Analytics service operating model as detailed above is a huge success in many companies around the world. Full stop there. If you’re looking to build a People Analytics function, the service operating model works well today and it’s going to deliver a ROI higher than the cost of the model for a long time. There are many small companies too that a lean version of the service operating model or even the initial model might be the model that works best indefinitely.
The People Analytics service operating model as detailed above is a huge success in many companies around the world.
I’m not even looking to make an argument that this model is broken today or not delivering on its promises. What I’m hoping to highlight is that at certain bellwether firms I’ve seen this model actively changing and I believe that shift tells us something about the function. If we can figure out some root causes for that shift then we can see what we can take from those firms to better prepare other teams for the future.
Burying the lede here, the trend that has caught my attention is the recent increase in product roles appearing in the HR and People Analytics functions. By product roles I mean the collection of roles required to create software products (e.g. product managers, data engineers, software engineers, and machine learning engineers).
I’ve collected a few examples of these product roles in the Google drive Link below. These job descriptions were all pulled on just one day, but this article has been weeks in the making as I’ve seen more and more companies post and hire product roles to their PA teams.
If you look at the service operating model above and the examples above, these product roles stand out from roles needed for the first two iterations of the PA operating model. What’s happening in HR that we need this heavy firepower? Where do these roles fit into the service operating model? It starts to tell the story of a different type of PA operating model emerging or an evolution of the PA operating model. In part two of this three-part blog series I will examine the factors driving this shift in the operating model.