A key thing about setting up a new role is to show how it enhances or benefits the business. The I found in my current team was that me role was not established in a way that would do exatcly that; support the business function in a meaningful way.
The chicken and the eggs
When I arrived, people mostly understood my role to be a glorified spreadsheet maker for data that is available within the tools/apps themselves already (don’t want to dive too deep into the why’s here, but the tldr is that there was someone before me that essentially established my role to be that.. nice).
The problem is: if a role is ill-established it becomes very easy for stakeholders to start wondering: ‘hrm… what is this person’s job? is it really that helpful for us to have someone doing this?’ This results in said stakeholders not associating me with the type of impacful work I can deliver. Slowly I was getting pushed to the side and the requests became ‘make me a spreadsheet with dropdowns’.
Over time I had conversations with people about my role and purpose within the business function. Without that clarity, it becomes difficult on both sides (and evidently what I described above had happened). If there are no processes for how to contact me, how to involve me in projects, or even what I bring into projects, then there’s no way for me to 1) get the time to develop meaningful work and 2) become aware of projects where I know I can be useful and 3) actually deliver impactful work that shows the value of involving people analytics in the first place. It’s a chicken-and-egg problem.
Documentation I tell ya
I also realised that the conversations alone weren’t enough, my stakeholders needed a clear reference point. I ended up writing documentation for our people partners that describes what People Analytics (PAX) does for people partnering, what a partnership with me looks like, and how they can get in touch with me. I also tried to more clearly define areas of responsibility, including responsibility related to data within people teams that I would expect people partners to own.
I realised that what I wrote probably applies more broadly to a variety of stakeholders, so I thought it would be cool to share it on my blog, too! One note: I wrote in plural because my team consists of me, one other analyst and my team lead. They cover different areas of the people team but I wanted to articulate a united narrative.
Without further ado:
Our scope and ways-of-working as People Data Analysts
People Partnering self-service goal
- We want People Partnering to be able to retrieve recurring insights from dashboards and understand when analytical support is appropriate and required.
- We want People Partnerings’ data literacy to be at a level that we can deliver dashboards that can be used for self-serve analysis and interpretation.
- We want to be able to support People Partners experience and ideas with data by becoming a trusted point of contact for providing strategic thought partnership.
Please know, you can always come to us if you have any questions about how to interpret data / read dashboards or even if you’re just confused about something that has to do with data. We always have time for a curious learner!
What we need to achieve the self-service goal
- People Partnering knows what we can and can’t do, and knows where to go for tasks that are outside our scope *our responsibility
- People Partnering understands where to submit analytics requests *our responsibility
- People Partnering needs to have (at least) basic data literacy skills *shared responsibility
The following walks through these bullet points.
What type of work PAX can provide to People Partnering
General Work
- Structured analysis answering defined business questions
- Dashboards to automate recurring reporting
- Structured datasets (for repeated use, or ad hoc if agreed upon)
- Urgent/high priority insights as ad-hoc requests*
Examples of what could be included in this general work:
- Datasets that combine data from multiple HR tools (e.g. CultureAmp + HiBob)
- Cohort, trend, segmentation analysis
- Metric definitions and standardisation
We can also be discussion partners:
- Our skillset includes thinking strategically through problems, and how to best visualise and explain data so it is easily understood by non-technical people or people that are not familiar with the subject matter. Therefore you can come to us with the following:
- We can give feedback on data/findings that you have created.
- We can function as a rubber duck / thinking partner if you would like to talk through an idea. We could also work through a structure on how to implement your idea or create a case to support implementing it. We love hearing all your ideas!
What type of work PAX does not provide to People Partnering
- We do not prepare spreadsheets, including ‘live’ sheets where one can input data in one sheet and visualise the outcome in another (For the why, refer to this article).
- Simple spreadsheet creation sits within the general skillset of a People Partner. If help is needed for a more complex input-spreadsheet the correct partner would be one of the Strat&Ops Managers.
- Any agreed-upon tabular data will always be delivered in the BI tool (mode) as we have live-connections on the back-end that ensure the data is always up-to-date.
- We do not manually overwrite singular datapoints (in any spreadsheet or elsewhere).
- If there are patterns in the data that cause a problem we can complete data cleaning on the backend for our data pipelines so that we have cleaner output.
- If the issue is based on a process issue, we should book a session together with POps to create documentation rules for said input.
(*) A kind ask and sharing some trouble about ad-hoc requests
It significantly impacts our productivity if we need to interrupt scheduled work to work on ad-hoc requests as our work requires deep-/focused thinking and developing code. If you realise you need something that is not available, please give us a shout sooner rather than later so we can plan for it.
Diagnostically, I have noticed a few times that ad-hoc requests may come from a lack of us participating in meetings where data needs may be revealed, and a lack of available data / outdated dashboards.
We are working on being more involved so we can anticipate your needs - if you will be working on something where you create graphs/insights that include people data please get in touch the moment you realise that the data is not currently available (or just drop us into the meeting, we can provide answers pretty quickly during the meeting).
We are also working on building long-term reliable pipelines and exposures (e.g. dashboards / regular reporting) so that these requests are reduced and you can also have data available when you need it and don’t have to chase it down with us.
At what stage People Partnering should involve PAX
There are two ways that PAX will be involved with People Partnering:
- As contributors to a bigger project (e.g. performance cycles, DEI analysis report)
- Here, we should be involved at the project planning stage
- As owners of a project that seeks to deliver insights for a specific purpose (e.g. Monthly Business Review Dashboard for all SLTs)
- Here we will plan the project together
- PAX will ensure ongoing contact / iterations are appropriate to ensure we deliver the right thing for you and that you are clear on timelines / feasibility
Our scoping includes the following:
- We need to understand how time-sensitive, urgent and longevous the project is.
- We need to understand what decision your project is informing, what action could change based on this, and who the audience is. Without this context, we risk delivering output that is technically correct but not useful.
- We need to understand in which way the output should be provided (refer to ‘How PAX delivers output to People Partnering’ section below).
- Understand how much time may need to be spent post-delivery (e.g. maintenance & iteration if we build a new dashboard/regular reporting structure).
We need to know this because:
- We need to find out if (& how much of) the data exists, whether we need to build models/logic on top, or/and source data from somewhere.
- We may need to replan our roadmap if the project is more urgent and time-sensitive than other, already planned projects. This also includes contacting stakeholders whose projects may be pushed back.
- For some outputs, we have some limitations on what & how we can deliver and want to make sure the expectation is clear at planning-stage.
- For some projects that recur (e.g. performance cycles) we may need to build more complex, long-lasting models so we can iterate through these in the future (check this article for an example).
- Our systems are currently still being built and we have very little engineering support so most of this work falls on us analysts. When we work on a project it often includes building and testing ‘foundational’ models until we come to a point where all these foundational models have been built. If we do not do this, it means we have to keep re-building the same thing and insights based on ‘temporary models’ become outdated and unusable quickly.
- Making sure that we agree on the time-sensitivity and urgency for project work is important so we can balance our foundational needs with the needs for the project.
How PAX delivers output to People Partnering
- Any delivered output should include (where relevant):
- A walkthrough of the new tool or the insight
- A short written summary / announcement
- In written form:
- Explanation of all columns and terms used in the output
- Definitions of all metrics that are calculated (or a link to documentation)
- Information on limitations of the data (other than assumed limitations of qualitative people data)
- A list of action points that were concluded as part of an analysis
- Any delivered output will be provided as:
- A dashboard in our BI tool (mode)
- A structured table output in our BI tool (mode)
- A written analysis or report, dated and in pdf form
- In rare cases, a single graph / viz
- For thought-partnership; a written plan/summary on how we go forward (if appropriate)
Known limitations
PAX can only provide analysis and insights based on the data that is available & provided to us. Most data is based on manual input from People Partnering / POps or employees. If data is/looks inaccurate we need to sit together and determine why the data is inaccurate. We can then together optimise our data documentation processes or consider changing resources to ensure that data insights can be trusted.
How to request work from PAX
Go here (slack channel link) to submit a request after you have read through this article.
Before you request:
- Check if what you are looking for is already available
- If yes, and it is available in a way that is useful to you: Please use it.
- If yes, and it is not available in a way this is useful to you: If you can, think about in what way this would be more useful to you, and bring this to the intake meeting.
- If not, spend time thinking about how/what you need and write it down. If you have absolutely no idea, that’s also fine, we can generally discuss an idea in an intake meeting and discover together what would be the most useful for you. To give you some idea of what can be delivered you can refer to sections above this one.
- Check if we are the correct people to send the request to
- Read through this current article to decide if we are the appropriate contact person for the job. If you cannot find an answer, check in with one of us.
We (I, Fiona) would usually have an intake meeting that is close to the time of when you contact me, even if you come to me with just an idea. I would grab the information I outlined above from you so I can scope the project on my side and give an estimate on availability / possible timelines.
To give you a general idea, delivery timeline depends heavily on:
- current priorities within PAX
- the project’s relevancy to OKRs
- urgency of the ask
Finally, work on a project will never start unless we have defined the scope, output, and timeframe.