People Analytics: Platform Operating Model

22 min readMar 31, 2020

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 the article below 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:

Reporting start

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 standardize 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, One Model, etc).

Survey start

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 defense to tackle incoming requests.
Operations again appears last to help stabilize 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 categorize 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.

What’s changing

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.

What’s driving the change — Scale

To talk through the drivers here, I see one main factor driving this shift in the operating model and two factors enabling it. I believe the driving force behind the emergence of these roles is the need to scale People Analytics.

Driving factor: Service models are expensive to scale

I’ve heard people say there’s a flywheel for People Analytics support.

People Analytics Flywheel

Teams in HR don’t know they need People Analytics,
They get a taste of insights from a PA team
They demand more
PA functions get more investment
Flywheel spins (return to step 2)

This is how PA functions go from a handful of reporting analysts or survey PhDs, to mega-teams in a matter of just a few years. HR as a whole has been starved for data support and when they finally get it, they want more immediately.

This flywheel may start off by supporting a key stakeholder. This is sometimes the CHRO or sometimes the parent org that owns analytics (frequently Comp or Talent). The PA team may pair that stakeholder with an analytics business partner guiding the relationship and researchers digging in to the stakeholder’s questions to understand the levers driving their business.

As the stakeholder starts to see success, not only will they ask for more support, but also the PA function will be approached by other HR teams. HR bringing data to the table is a recipe for success and word of success travels fast. Those other functions that have seen the success of that first mover will be eager to get the same level of support and bring data-driven insights into decisions about their own organizations and to their business partners.

But research and custom analysis takes time and hard-to-find skills. Every HR function wants their unique last mile problem solved. Reports end up being run and rerun with small tweaks and analysis is being done and then cut for a line of business and then redone and recut for a new line of business. New clients, their direct reports, and their direct reports all look to the PA team for support. After a while all of this white-glove work starts to add up. Adding heads to this model is the only way to meet additional demand.

In adding headcount to meet the demands of the flywheel, the investment in the service model starts to get heavy as it mirrors HR or, more realistically, the investment stops. When that investment stops, the People Analytics team has to make a call to prioritize clients and stop providing analytical support beyond a certain level in the organization or bubble-wrap their resources to be reserved for a special set of clients.

So what is it about these product jobs that could help with scaling? As it turns out, the scaling issue for service functions is not only occurring in HR. We’ve seen this across many disrupted service industries: a garage full of software engineers at Airbnb can collapse an industry of travel agents and a startup of software engineers at Uber can collapse an industry of taxi operators that used to take phone requests to tell cabs where to go.

As the service operating model of people analytics hits a certain scale in the organization, it starts to make more sense to invest in software to scale insights. The good news is, there have been some external factors shifting in the background over the last decade that enable PA and HR to move into this next phase of software driven scale. While HR has lagged partners before when it comes to automation, there’s an opportunity now to jump to parity due to advances in the tech space.

Enabling factors

I’d be remiss to skip over the enabling factors that are allowing HR to make this jump into developing products, but at the same time I could write an article about each of these factors and this blog is already getting long. So here is my rapid-fire argument as to why the environment has shifted to allow HR to make this jump into product.

Summarized: Data science, data engineering, and machine learning talent as well as computing power used to be incredibly expensive, but in recent years the cost has plummeted allowing HR to enter this space now.

Factors leading to this decline in cost for scaling HR with software

The other functions started to hit economies of scale for data science and data engineering talent (you don’t need the 10th data scientist as much as you need the first one.)
That led the talent market for product talent to normalize and saturate. This meant that HR making a request for product talent is no longer outlandish and with the growth of education in this space the supply of product talent started to look to HR as a function as a way into the field
There has also been an explosion in open source data science, programming, and automation tools like packages in R / Python which dramatically brings down the cost barrier to entry for HR to start developing products.
Combining that open source movement with a massive growth in cheap cloud processing and storage through services like AWS, Google Cloud, and Azure means that a capable person can now set up the foundation for a product in a few hours.
We’ve seen a dramatic rise in the capability in HR tech, which makes sense too with the drop in previous barriers of computing and talent. Over the past ten years, the value of modern HR management systems like Workday and SAP has become widely accepted and we’ve seen the emergence of data-oriented HR tech firms like Swoop Talent, OrgVue, One Model, which step in to do much of the hard lifting to organize and democratize insights. Many of these companies not only provide data reporting, but they also standardize data entry, act as the data warehouse, provide cleaning, and provide their own analytics.

This drop in barriers to entry for computing and product talent has opened the door for HR to enter the product space.

Platform Operating Model

If you were part of an enterprise tech company, you could expect to find the following functions working within the business to deliver the technology to clients

Enterprise Tech model

Product — People who build the tech product and enhance the product to meet customer needs (R&D, SWE, Data Engineers)
Solutions — Solutions teams work with buyers to ensure that they are getting maximum value out of the product.
Training — Training teams consist of specialists who help customers learn how to use the product. Usually scaled support (videos, lectures) and some custom support (on-site setup).
Client acquisition — Client acquisition (sometimes referred to as marketing & sales) works to increase market share, onboard new clients, and track portfolios of current client’s usage to ensure renewal agreements.
Specialty Research — No product serves 100% of client needs, so some shops have a custom research or custom tooling group to go the last mile
Operations — HR tech firms need an operations team to run the business of the firm. Project management, program management, business analysts, and internal operations.

Over the next decade, I believe People Analytics is shifting to a similar operating model especially when it comes to the focus on the products. By supporting a product you can make incremental improvements to a core piece of software and then sell that software 10,000 times over to scale your support instead of relying on an increase in human capital to scale the team.

I’ve put together a loose draft of what a Platform People Analytics team could look like below. Remember when I mentioned before to take these arguments with a grain of salt? This is a good time to pick up your salt. I’d love to hear your thoughts on the model below and I especially look forward to hearing if you’ve seen this in practice or if you think this is a model that your team could operate under.

Platform

The platform team is the engine of the People Analytics machine. The People Analytics platform team in this model is a collection of products, built internal and external, that are delivering analytical services to the business as a whole and the people who support them. This involves tools like One Model to scale reporting or custom built dashboards all the way to the internal analytics built into HR tech products. In this model you would even manage some 100% human processes as “Products”, but that’s an article for another day.

Each of those products within the platform would have their own product manager and for the internal products there would be teams with developers, data engineers, research scientists, and analysts. User experience skill sets would work across the team as a whole as a pooled resource supporting product teams to better understand the clients in the business. This sub-function would build, maintain, support, and understand the tools that scale people analytics into the business.

I’ve included a graphic with examples of what types of tools could fall into the People Analytics Platform area of work.

It would be unlikely that a PA team would own all of the tools listed above due to redundancy, but I wanted to show examples to put ideas out there about what would be owned by a platform team. Some People Analytics teams in the future may decide to own and build a single full stack product, ingesting data, warehousing data, and delivering data and insights back to users, but with the large upfront cost required and advancements in external HR tech, it seems more likely teams will own a blended ecosystem of internally built and externally purchased HR technology.

Types of talent required to support this part of the operating model: data engineers, product managers, data scientists, developers, visualization experts, former HRIS, user experience,

Solutions

Solutions is the team focused on increasing the value that HRBPs, HR line, Finance, and the business get out of the platform. It differs from partnership teams in the service model because it is a pooled resource instead of a client-allocated team. This team is brought in to maximize the value of the user experience between the enterprise clients and the Platform team.

Work on this team could include direct education on the ecosystem (where to go for what), helping HR team members start projects that need data or insights from the ecosystem (with a mindset to get the team to self-service), or making technical tweaks to the platform as needed (in conjunction with the platform group) to make the platform work for the end users.

Solutions teams help scale PA by creating a pool resource instead of a 1:1 partnership for direct client support, but they also help scale PA by allowing the platforms team to focus on the 80–90% need and filling in the gap for the 10–20% need of clients. Without a solutions team, the platform team would get overrun with direct requests from clients for custom changes to core products, which leads to technical debt, forked systems, and increased overhead on the products.

Types of talent: technical consulting, project managers, portfolio leaders, HR analytics partners, enterprise technology solutions partners.

Training

The training team onboards and trains new clients or the company at large on how to interact with the products in the Platform. While the solutions team still requires human capital to interact with the business (though less than a partner model), the training team can operate with a lean team to create scaled resources like video training, interactive demos, or FAQs that can be accessed through self-service tools.

Training helps scale People Analytics by working to get ahead of requests to the solutions team. Requests to the solutions team are a great source of data about what a training team should develop, but the training team can also measure success by how much they reduce ticket volume to the Solutions group for commonly asked questions. This helps elevate the value driven by the Solutions team, which in turn further protects the Platforms team.

PA getting a dedicated L&D / training function may not be a reality in most companies, but in those cases where they can not, a direct partnership with L&D is critical.

Types of talent: L&D professionals, consultants, trainers, designers, production staff

Client Acquisition

It may seem odd to think about building an internal marketing and sales group, but the skill-set required to deliver a People Analytics platform is different from the work of selling People Analytics. Many times I’ve seen People Analytics teams ask a PhD from a STEM background to pitch an idea for a project or the impact of a potential project to an executive in the business and while there are some rare people that can do it all, more often than not the sales skills are not present on the data science team.

Ian O’Keefe said the following during a recent talk at PAFOW west

A question I get a lot is what do you hire for. What kind of skills do you see in this space? Skills and the combination of skills is one of the first things I looked at when I joined and that we continue to look at over time.
Typically we see people come to us from four different areas and they’re deep in one and dangerous enough to be good enough in another one. I’ve yet to meet someone who has an advanced degree in mathematics, spent time managing a tech stack, has also spent time at a top tier strategy consultancy, and has also gone deep on IO psych research or team leadership. If you are one of those people, come see me after the talk.

When we let people play to their strengths we build stronger and more diverse teams. So to scale the platform to the business at large, having a dedicated team to focus on how to sell the products within the People Analytics platform to 100% of HR or the business is a critical skill-set.

It’s a team that works both ways too. They would pitch the platform to new potential clients and sell those clients on the training and solutions support structure, but they would also act as eyes and ears of the platform, doing competitive analysis and understanding customer pain points. Marketing and sales are on the front lines in enterprise tech; talking to clients every day and getting a pipeline of that information back to the people working on the product is critical.

It’s also worth keeping in mind that the flywheel of People Analytics adoption can also mean that the functions that got access early are the ones getting the most access today. When PA teams hit their limits for investment they start to prioritize and shut down new clients as they scale, which might not be maximizing strategic value to the business. Building a client acquisition team can ensure that PA is delivering service to a strategic portfolio of clients.

Types of talent: UX, Marketing, sales teams, content creation, portfolio management

Specialty Research

Even with a full and functioning platform of products, the one-off and custom projects will not go away, but if the Platform, Training, and Solutions teams are doing their jobs the remaining needs from the business will be intensely complicated. This is the final 3% of projects which can sometimes consume an entire PA team’s capacity. There’s always going to be a need for someone to tackle strategic or high profile projects that don’t quite fit the platform (yet or ever) and the specialty research team acts as a SWAT team to tackle those needs.

The existence of a specialty research team also allows the platform scientists to work on scaled solutions instead of getting caught in a cycle of one-off high priority requests. By separating these teams into platform data science and specialty research, the platform team can fix root causes and the specialty research can focus on the high-profile fires. Likewise, establishing a training and solutions team ensures that this specialty organization does not get bogged down in regular reporting or education requests.

In the long run, one additional goal of specialty research should also be to act as an external R&D function to the platform. If they find themselves doing the same project 3 times over, there should be a connection point to the platform to either find an HR tech solution or build a scalable product which can support that repeating question moving forward.

Types of talent: full stack swat team, IO psych, data science, project managers, consultants, data engineers

Operations

Lastly, the People Analytics function needs operations to keep all of the gears moving. In the service model today, we’re just starting to see operational roles appearing and I think the slow appearance can be traced back to the service model roots. Operations roles can sometimes feel like optional “self-care” for a team and it’s hard to make the choice to invest in what appears to be operational overhead when your clients are demanding more direct service support.

However, operations roles are leverage roles to increase the overall efficiency and effectiveness of the operation of People Analytics. A strong operational team to track projects and priorities across groups can help balance the workload across the team. While each sub-teams can get focused on their own silos, an operational team should be analyzing across silos to keep the team balanced and working with cross-functional partners.

Platform Operating Model Visualized

Platform Operating Model Example

To illustrate, I’ve put together an example of a small unit of the platform operating model in the example below. It’s easy to picture this operating model working on a platform built around a One Model instance.

Team members:

1x Data Engineer (Platform)
1x Data Analyst (Platform)
1x Client Acquisition / Training (Client Acquisition / Training)
1x Solutions partner / Training (Solutions / Training)
1x Researcher (Specialty research)
1x Team Lead (Operations)

Software:

Workday
Recruiting System (ATS)
One Model
Tableau

In this example, the platform would consist of Workday and an ATS feeding directly into One Model. The data pipelines and data quality / integrity would be managed by a data engineer on the team. The data analyst would work with HR teams and their client acquisition coworker to develop scaled reports for the HR function based on customer need. Since the team is lean, the data engineer would also work with the data analyst to pull data from Workday and other HR systems directly to generate additional scaled reports in Tableau.

And in the spirit of keeping a lean team, the training for the enterprise on how to use One Model and Tableau reports would be split between the solutions employee and client acquisition employee. A stand alone training role might not make sense while this team is lean, but if/when complexity to the platform increases it could be added to the team.

The client acquisition employee would be charged with tracking, monitoring, and scaling One Model rollout across the company and the solutions employee would work with new teams that come on board to teach them how to build custom reports and manage a ticket-based queue of questions and requests regarding the team’s scaled One Model and Tableau dashboards.

The specialty researcher would pull data directly from all systems and One Model to generate custom analysis. They would work on projects ranging from compensation studies to diversity analysis. Their work would be at the direction of the CHRO, supporting decisions across the enterprise.

The team lead would manage the team, manage contracts for systems, work with the data analyst and data engineer to set strategic direction for scaled reporting, ensure that workload is balanced across the team, and measure KPIs for success of the team as a whole.

As the team grows, you could see the data analyst shifting into a product manager role for One Model with a few data analysts or visualization reports working for them. Additional products like an ONA tool or a labor market tool could also be added to the Platform, increasing the need for additional product teams and client acquisition groups.

As complexity of the products grows, the need for a stand alone Data Warehouse may rise, bringing developers, data engineers, and automation experts into the picture to streamline the ingestion, cleaning, and delivery of data to the products. As the flywheel for PA projects spins, a centralized solutions team may be stood up with a ticketing system to better serve the organization and a stand alone training function may emerge.

When you play this model forward though, the pooled client model and focus on scaled services through software allow this operating model to scale to support the full enterprise.

The shift

This isn’t a theoretical shift. I believe I’m just shedding light on this model as practitioners are starting to put it into place already. Within some teams there is an overhaul moving them this direction, but in other teams it’s a subtle shift with an increased focus on data solutions, automation, and HRIS. I’m seeing teams move this direction today and that pace is going to pick up over the next few years.

To summarize, what got us here might not get us where we’re going if we want to scale People Analytics across all enterprise clients. When they are ready to hit the next level of scale, PA teams may start to shift away from operating models that support white-glove custom reporting and analysis and invest more effort into operating models that support a scaled platform of software and helping HR engage with the software.

I’m excited to see that future unfold and to help that future unfold over the next decade and I hope you are too.