How I became a people analyst
I've had a number of connections reach out and ask me for advice on how to get into people analytics or develop skills in that space. I really wish I could help everyone, but there's no way I can do so equitably so I thought I would put it in a post that I can share with everyone.
If you are reading this because you were recently laid off, my good vibes are with you. I hope this post helps you but more importantly I hope you find yourself on your feet ASAP.
I started working in data analytics through an unpredictable combination of opportunity, luck, motivation, and good mentorship (both hands on and off). I really wish I could tell you to ‘read one book' or 'enroll in my class' and then you are an analyst... But it's not that easy. All I have is my experience, so I'll present that alongside the resources that might help you if trying to create a similar path.
Part 1: Protiviti
I joined Protiviti as a new grad in 2013. This work involved consulting in the internal audit space and I was learning a lot with your tried and true control tests and risk assessments. Audit makes you think in incredibly detailed ways, and I can point tangibly to many skills I learned that I still use daily (access privileges, data security, retention to name a few).
However, I wasn't necessarily as passionate about that work as I find myself towards data analytics today. I'd also like to consider myself a friendly and happy person, and thus it can be pretty crushing to inform a well-intentioned client that they've produced a bunch of audit exceptions.
As I proved my value to my primary client, they surfaced more interesting and analytical projects for me. Expense reviews. Audit scheduling. Fraud assessments. These are all things that may not sound "analytical" but are areas where data analysis can very much raise the value of the deliverable.
The thorn in every analyst's side is data availability and reliability. You can't analyze data you don't have, and the company may not have dedicated Business Intelligence teams to structure and surface reliable data. So the dirty not-so-secret is that data collection, manipulation, and aggregations are what analysts need in their toolbox regardless of how sexy it might be.
(Note: I find it incredibly sexy and if you feel that way, you might find yourself specializing in data engineering down the road - which is a lot of the work that I perform in my day to day now)
My earliest projects could be trivially summed up as:
Gather data from a bunch of bespoke sources (ERPs, HRIS, audit tracking tools, or the crappy spreadsheets saved on local machines that act as critical business infrastructure)
Get that data into a tool I had on hand and could manipulate with. This was Excel and Access in the earliest days of my career.
Shape the data how I needed it by using spreadsheet formulas or VBA most often.
Aggregate that data into top level summaries and relevant breakdowns aka "make pretty charts"
Present that data in email summaries, executive presentations, or summary tabs in the spreadsheet itself. Delivery mechanism highly depends on the audience and use case of the data.
So, I lived in Excel for a while. I'd be shocked if most other analysts haven't started in spreadsheets - it's a very logical platform to do so. If you are a Google shop - Sheets is also an excellent place to learn. Spreadsheet formulas are fairly universal across platforms, and they can serve as great primers to learning SQL, R, or Python for data manipulation down the road. Every good analyst I've encountered can manipulate their own data in a spreadsheet tool.
One of my clients had a manager who was starting to push the department towards more data visualization. Tableau had just IPO'd, and was a darn cool technology. Following our successful teamwork on some spreadsheet analytic projects, he convinced my managing director to have my firm purchase me a license so we could continue collaborating.
I still remember the paper he came and dropped on my desk showing a very beautiful, client branded dashboard displaying the status of audits and findings in a one-page view. "You made this in Tableau?!" I said as he brought his laptop over and started showing me how easy it was to make charts and interactive visuals.
I was hooked. As soon as that Tableau license came through my email I was pumping all those nice spreadsheets I made into it to see what dashboards I could create over top of it. Some of that work went back to the client. Much of it was throwaway dashboards that I was using to grow my own skills. How do I make a donut chart? Do I need a level-of-detail calculation to achieve my visual? Also, what the heck is a level of detail calculation? (For the nerds - it's a window calculation equivalent)
And this is where the hands-off mentorship was also super helpful. My managing directors gave me the space I needed to learn these techniques and how we could apply them to our client work. I also had a bit of a fire in my belly to validate the firm's money that they spent to acquire my Tableau license.
In addition to the pretty charts, I liked how Tableau made it really easy to wrap my head around more advanced calculations. Helpful source documentation and error messages made things like LOD calculations easier.
I started shifting my deliverables from "open up this spreadsheet" to "open up this interactive dashboard to review results" and the client really took to it. As the firm's first Tableau user, I started gaining a bit of notoriety throughout the different offices. Eventually, the firm's HR department found me and asked if I could try and solve similar data problems in their space (performance reviews, project scheduling, employee engagement, etc).
Around the same time, another manager would join my client and become another analytics mentor to me. He especially turned me on to good data visualization, which can really make or break an analysis. There is some awesome literature on this topic out there - consult your favorite search engine - because every good analyst can visualize their own data. Ideally, while leveraging visual best practices and keeping accessibility in mind. And "best practices" isn't some necronomicon of magic viz - it's things like not using red/green because that's awful for many people with colorblindness, and making data labels so that you don’t have to squint to read them.
So what happens once you've spent all that time collecting, aggregating, and visualizing data? You present it! A major benefit of working in consulting is that you get numerous clients, projects, and subject matters. So I got to present to an array of individuals with different data proficiencies and in doing so learned how to better articulate all this sometimes-obscure work. Every good analyst can professionally and clearly describe their data and findings.
My consulting MDs would drag me into meetings with C-people all the time because I was the best equipped at the firm to talk about these things, regardless of the fact that I was young. Endless hierarchical bureaucracy makes that a lot harder to achieve in industry - your boss's boss's boss would rather represent your work to the C-people than let you in the room. It happens. Don't take it personally. I do encourage time in both consulting and industry to round yourself out - there are pros / cons to each that would take another blog post to dive into. Regardless, Every good analyst can see the bright side.
The last major takeaway I consider while reflecting on Protiviti is that I was making my own opportunities. Clients that possessed data didn't necessarily know everything that could be produced by it - you don't know what you don't know! Oftentimes I was saying things like "let me take a look at the data and get back to you", go dig at it on my own, and then come back to review with the client with views of the data they had never seen before.
The incremental progress would open up new questions and data and this starts to produce a snowball effect. A good analyst doesn't wait for a crystal-clear dataset and instructions to arrive from their management, because it's rare for both to exist simultaneously.
---
Part 2: Google R&I Delivery Pod
 |
| Me standing in the Googleplex on my first day. Also the only day I've ever worn a tucked in shirt. |
Megan and I got married in late 2016, and celebrated by fleeing DC to move to the West for myriad reasons that could also be another blog post. I took an office transfer and not long after realized that my personality probably wasn't going to mesh with that office's culture. I wish I could say there was a grand plan to find a job in Google People Analytics, but there wasn't. The truth is that I got chided for wearing jeans in the office on a Wednesday, which was not uncommon in my original office, and went back to my computer and searched "tech jobs in my area". Turns out that was the most fortuitous chiding of my whole life.
I saw Google was located in Boulder, and the very first job posting that popped for me was "People Analyst, Reporting & Insights". I read the job description and it largely mirrored the work I was doing for the firm's HR department.
"Oh wow - am I already doing People Analytics?"
I rang up a friend working for Google and asked if they could consider referring me. Because all job hunters should definitely try and get a referral. I went through the interview process, even though I certainly didn't feel like much of an analyst given all my skills were home-grown. But what did I have to lose?
After a long interview cycle, I was extended an offer. Looking back at it six years later, I did have the skills that the job description was asking for. I also interviewed with a sheer, honest enthusiasm for the field. I liked the idea that my work was making Protiviti better for *the consultant*, and I wanted to do the same thing for employees at Google. I still want that. Believe in yourself - even if you aren't trying to be an analyst.
I learned through the interview process that R&I was a brand new team trying to solve the "last mile" problem of data delivery. Similar to horse / water / drink, you can't always bring a stakeholder to a dashboard and have them derive insights. This team would have technical and client-facing arms. The mandate of the team, the challenge at hand, and the opportunity to move from a really barebones analytic environment to arguably the world's foremost one fascinated me. The recruiter sent me a bunch of pre-read links - but the one that excited me the most was Prasad Setty and ‘The science of storytelling’. For some reason they made the video unlisted. If it ever disappears, email me, because I made 100 flash drives containing the file for such a scenario.
I joined the technical arm of the R&I team, dubbed the Delivery Pod, in 2017. In this role I learned about fielding ad hoc and operational analytic requests, delivering data solutions at scale, but most importantly -- SQL. Structured Query Language.
In 2022, it's entirely possible that I can speak better SQL than English. But back then, I just had some exposure in college (shout-out to Dr. Zobel's class and my homework partners Lauren, Ruby, and Matt) as well as *very* basic SELECT statements to power some Microsoft Access based deliverables I created. Google has mature data infrastructure, so your most direct path to data is fire up your query editor and start writing - pulling it into a spreadsheet for analysis is a step that wastes time.
Which brings us to - good analysts have at least one data manipulation language of choice. Notice I say language, as in programming language. We are transcending spreadsheets at this stage, though we still love them very much. Here is my general outline of "the big 3" analytic languages as I see them. There are many resources out there to compare them and you shouldn't rely entirely on me before you go diving into a language.
SQL - very ubiquitous across tools and uses simple words (SELECT, FROM, WHERE, GROUP BY) to clearly convey what it is you are asking from the data. To simply extract data from a table and get results / aggregations with the least friction, you'll want SQL. It's also more friendly to operational / repetitive tasks because you can often connect it to automations and workflows. It is more limited in terms of statistical firepower compared to...
R - an I/O or OB psychs (data scientist) best friend. They likely learned it during the course of their studies or on the job because of its advanced statistical capabilities. From a raw data manipulation standpoint, there are lots of overlaps with SQL functionality. It's less friendly to the operational tasks a data engineer needs which is why I tend to write more SQL in my day to day.
Python - the most sophisticated language on this list, it can be used by analysts to perform similar aggregations / manipulations as SQL / R. In fact, you can use SQL and R code through various integrations in Python if you are fancy. But it's also hardest to learn and requires the most overhead for simpler pulls. Should set you up for more technical roles in the future, though, if you desire that.
If you are just starting out in analytics, I would recommend getting very good at SQL or R and then becoming conversational in the other. If you aren't sure, learn whatever your teammates are learning. If you don't have teammates, learn SQL at www.sqlbolt.com and become your company's first full-fledged analyst OR have a very versatile data language on your resume for the job hunt.
This entire post was written while flying over the Atlantic Ocean, which really gives me appreciation for how damn big it is. I'll end here for now but if there is interest maybe someday I'll write parts 3 and 4 which should get me to my role today. If that never happens, I hope you found some value or humor in the words above.
Be well and best of luck, in whatever circumstance brings you here.
