How Soundcloud’s Team Drives Decisions with Data - HR Open Source
SoundCloud has the largest catalogue of audio on the web - over 135 million tracks and reaches 175 million unique users monthly. It’s not hard to imagine how much data we have and the insights our Data Team are able to glean from this. Data is at the heart of our decision-making process as an organisation and that sentiment is also core to how we work in the People Team.
What better way of putting data at the heart of our decision making than to also put the data and insight needed to have an impact at the businesses fingertips - a company-wide People Dashboard. The nice thing about this story is that this wasn’t our intention back then. Back then we had much more modest ambitions: just a simple report on recruiting activity. The good thing is that we didn’t just stop there. We didn’t stop at the first hurdle, or the second, or third (when the enormity of the data privacy requirements became apparent). For us, this story is very much about the journey as it is about the outcome (which still isn’t finished and I doubt it ever will be as there’s always more iterating that can be done).
WHY WE DID IT
The journey of the dashboard is a long one. It was led by SoundCloud's Head of People Analytics & Technology, Chris Brown.
Back when I started as a recruiter in 2012 there was nobody who took ownership of people data, in the recruiting team at least, and the focus was more on the traditional ‘bums on seats as quickly as possible’ approach.
It became pretty clear that we needed to do a better job of surfacing people data to the wider organisation with the approach of data-informed decision making which was based on facts, not just gut feeling. The goal back then was to bring more visibility of recruiting and, in turn, we could reinforce the need for better data quality from the recruiting team.
When we started, I spent more than 90% of my time recruiting. It was important that we built out a self-serve approach to access all levels of ‘People’ related data to reduce the number of requests I received and set us off on our journey of People Analytics (although the idea of this wasn’t even on our radar back then!). After doing some research on companies who were also doing interesting work in this space, I ended up speaking with Derek Isley from Hootsuite who had recently published a case study for HROS (back in the very early days) on the work they were doing on recruiting reporting and metrics. These conversations played a big part in shaping the direction of the dashboard and other projects, like candidate experience, we had in the pipeline. This is really a testament to the power of the HROS network, and the member’s openness and willingness to share their insights and learnings. This worked well to help us get the basics in place to help us start from a good foundation.
WHAT WE DID
Riding the momentum of the recruiting activity report, our goal was to bring our People data to life to be able to shape acquisition, development and retention efforts across the business.
We launched an ‘always-on’ People Dashboard which could be accessed by anyone in the company (who had access to our VPN). We also wanted to make this as dynamic as possible with regards to the level of information that could be filtered to really bring the Dashboard to life, provide a transparent window into recruiting, and drastically reduce the number of requests we were receiving.
HOW WE DID IT
Kicking it off
The early stages of the dashboard were only focused on talent acquisition data. It was only later that we had the ability to merge two data sets, from our ATS and HRIS, together to form the data architecture of People Data under one umbrella. To do this we changed the organisation structure (in the People Team to form the People Analytics and Technology Team) to bring together a team which had the overarching ownership on the data. This made things much easier when it came to ownership and accountability.
As we already had a pretty solid idea of the use case for the dashboard. The steps we mapped out for this were:
Understand the audience/customer needs
Mock out the design (whiteboard session)
Lock in the plan & timeline
Involving the other internal stakeholder/decision makers (Legal, Security & IT Teams)
Soft launch (internally with team)
Iterate and Evolve
#1 Understanding the Audience
We already had a report (which we classed as a dashboard) running at the start of this project. This has been a steady evolution over time, from....
This (in 2013) using Excel and PDF
To this (in 2015) which was built just using Google Sheets
The common problem with this approach though was the amount of work that it took to produce the report and how prone it was to (human) error. The process usually went something like this: download data from ATS in Excel, produce some pivot tables, check everything looked ok, speak with the recruiting team to make sure everything looked ok, double check the numbers again, prep the email to send out to the stakeholders, attach relevant files/links, triple check the numbers, re-read the email, hit send then break into a mild panic that that there would be something wrong with the data.
We knew there was a desire to have People data easily available to the organisation and we felt we had a pretty good understanding of where we could start from. We still needed to test our theory with the key audience - initially, this was only focused on the Talent Acquisition data. To do this we sent out a Google Survey.
An early example of how we approached our stakeholders to assess their needs for Recruiting Data (below)
This made sense for us at the time as we were still operating more in the Recruiting Operations space. However, we had been discussing options of working with the People Operations Team and bringing together more of their data into the dashboard. We left things with them to manage their side of the project so that we could fully dive into moving things forward with Talent Acquisition data and planned to revisit their progress at regular intervals so we could find a time which made sense to incorporate their data. Unfortunately, at the time we didn’t push this sooner. In hindsight, this was a mistake.
With more formal feedback completed, and less formal feedback received, we felt we were ready for the next step: the design.
#2 Mock out the design
We had a good idea of the content of the dashboard. The focus now was on making this shine. We only really had one tool in mind to do this: Tableau. It made a lot of sense as our Data Team were heavy users of this already and it was a tool which was familiar with the broader company. This also helped us check off our need of having an easily accessible, always-on dashboard.
Using a visualisation tool like Tableau allowed us to move towards more automation of the data, by connecting the various data sources, and, providing the information had been entered correctly the first time, reduce the risk of incorrect data.
At this stage, it also made sense to revisit the progress that the People Operations team were planning and look at how we could incorporate their data into the dashboard.
What was important was the focus on blending the two sets of data together in a coherent manner and flow which would instantly make sense to the audience.
The basic flow of the dashboard, therefore, focused on acquisition, development, and retention.
We had one initial session where we mocked up the design on a whiteboard. This was a quick and easy way of us fleshing out the look, feel and user experience flow without the need for over-complicated programs or tools.
While our primary focus was on the aesthetics of the dashboard, we also needed to understand how the flow of data between the different systems would work. As we didn’t have the technical expertise within the team (myself and the intern) we had to rely on the expertise of our Data Team for guidance.
#3 Locking in the Plan & Timeline
Up until this point, we’d been quite relaxed about locking in exact dates for the roll out of the Dashboard due to the complexities involved. Having completed more of the research and mock up stages we felt better about being able to put together more of a robust timeline for rolling out the project, with the caveat that we were always going to be at the mercy of the other team’s priorities who needed to support us technically - the Data Team being a prime example of this.
The official launch was set for October 2016.
#4 Involving the Other Internal Stakeholder/Decision Makers (Legal, Security & IT Teams)
Once we had a good idea of how the dashboard would work and the data it would contain we had the necessary discussions with our Legal Team regarding the data we would be disclosing. Sharing the dashboard with them there were no immediate issues which they flagged with this as it was all going to be for internal use only and we were only displaying aggregated data as opposed to specific employee data.
What we failed to do at this stage, which we missed, was submitting a Privacy Impact Assessment for the storage of this type of data on Redshift with our Security Team. This came back to haunt us after launching the dashboard.
#5 Soft Launch
We wanted to make sure that the Dashboard was as watertight as possible before we released it to the wider organisation.
So, two weeks before we planned to unveil the dashboard we invited members from our Workplace, Internal Comms, and People Team to access the Dashboard. We felt this was a safe, but robust, environment for the soft launch.
We then had time to receive feedback on any bugs, typos or general confusion (mainly on wording) which helped draw our attention back to the details which became easy to overlook having been so immersed in the project for such a long period of time.
#6 Hard Launch
Picking the channel which would create the most awareness on the Dash’, we decided to launch this at the company's bi-weekly, Demo, which is held in our Berlin HQ and streamed to all of our other offices (and available to watch again). This provided us with the best opportunity to reach a large audience to drive home the significance and impact the dashboard would have on our organisation. This happened at the end of October 2016.
We also followed up with an email to the whole company which then linked to a blog post on our internal wiki page providing context on the Dashboard and how it could be accessed. This also served as a great reference resource and help guide people through the process of accessing and making sense of the insights.
#7 Iterate and Evolve
Before officially launching the Dashboard we were aware that we would be doing so with something that was still a work in progress. However, at the risk of being too perfect, we felt okay with the approach of rapid iteration and feedback sessions to tighten this up.
Even now upon reflection, we feel this was the best decision to make, as producing a piece of work as complex as this throws up so many challenges that there has to be a line drawn somewhere with regards to a minimal viable product (MVP) versus striving for first-time perfection.
Post-Launch & Offline
Momentum was good after we launched the dashboard. We received a ton of positive feedback on this. All parts of the organisation who were impressed with the quality of the dashboard and breadth of information now available to them which they previously didn’t have access to - particularly for our Diversity & Resource Groups, Senior Managers, and Hiring Teams. Usage of the dash was good.
Things were going great; well, almost.
Just over a month after launching the Dashboard we ran into an issue with privacy concerns with our data storage process which left us with no alternative other than switching it off until we resolved the issue.
As we’d missed the impact of submitting the Privacy Impact Assessment there was no other option but to take the Dashboard offline until we resolved the issue of how we could store, process, and access the personal data in a more secure way - access restricted to only our team.
This was actually a blessing in disguise - although it felt a long way away from it at the time.
It actually gave Dries, our Engineer, the opportunity to make the backend more robust, localised, and a little more future proof for the team’s needs without being so dependent on our Data Team.
Moving to this new setup also made allowed for us to be able to access both data sets (from our HRIS and ATS) to perform ad-hoc queries in one place using SQL queries.
The People Dashboard (The output of all this work)
Diversity & Inclusion
Recruiting (baseline metrics)
The Dashboard is still relatively new but we’re already seeing an improvement in the following areas:
Reduced ad-hoc request for reports and insights for our team by over 90%.
Established baseline numbers for recruiting - for the first time we now have the data at hand for intake meetings with hiring teams to manage and plan expectations and timelines for hiring key roles.
Visibility on headcount numbers across all locations allowing greater visibility for our Workplace team to plan for, and adapt to, needs for additional space.
Making hiring a team sport - with the dashboard visible to the whole organisation our teams are now challenging the recruiting funnels to ensure that we have a diverse pipeline of candidates.
Using the data from the dashboard our recruiters were able to take action on an initiative to increase female Engineers in the organisation to increase this by ~70%
Provided our Senior Management Collective with a forward-looking plan of attrition development which enables us to track and plan headcount needs across the business
Hired the first Engineer outside of the Engineering organisation for our People Team and highlighted the impact having such an in-house talent can have on Operational Teams.
WHAT WE MISSED
Data privacy - for us, based in Germany, this proved to be one of the major hurdles to overcome. We were able to overcome this eventually by scaling down our database and having this based locally, rather than with a 3rd party provider. Given the size of our data set, compared with our Data Team, this makes much more sense.
Pushing harder earlier on in the process to bring the whole People Data together sooner would have saved us a lot of time in the long run.
Being tighter on deadlines - in particular, with other teams and holding others accountable.
Trying for perfection too early on with the dashboard. We eventually learned this wasn’t the right approach and it was more important to go with an MVP and build on this incrementally.
On reflection of this project, it was a massive piece of work. While we’re super happy with the end result and the data foundations and capabilities we have, it was a big stretch for us and doesn’t necessarily need to be this approach for others. The main thing is to not be intimidated in this area. Start small, but start something.
Don’t focus too much on what others are doing (but still take inspiration) - with so many great initiatives going on in our space it can be easy to become a little disheartened if you focus too much on other’s work.
Take the time to celebrate - the pace at which we ship initiatives and the scale at which we operate often makes it easier to forget just how impactful/impressive our work has been.
Having dedicated technical resources in the team helps - massively. If you have the opportunity to hire for such roles, do so. The earlier the better.
Be patient - our project has taken a long time. We had to deal with many setbacks and complicated legal requirements. These things take time.
Set expectations early - when working with key stakeholders, who can also become ‘blocker’s, it’s imperative to have the tough conversation early on in the process and to keep the communication flowing as you go along.
This was a big team effort and the work involved couldn't have been possible without the extra mile that people went to support us - which reinforces how important close relationships are with other teams / need to have the technical know-how in-house (in the team).
Documentation - This is as important as the work itself. Clear, easy to read (by technical and non-technical people) and replicate.
Lastly, without a supportive management team who believe in the mission, this would have been a much more complicated process for us to get to this stage having gone through so many learning curves. This support has been invaluable.
Trello - for managing the high-level visibility of the project. We were able to share this with stakeholders who could gain access to check on progress of the project and provide feedback or requests where needed
Jira - later in the project for all engineering focused work
Google Sheets - great for collaboration with docs, spreadsheets
Google Survey - for gathering initial feedback from the key stakeholders of the project.
Skitch - the screen grab tool was invaluable for providing feedback on the iterations to the design of the dashboard as I was able to pinpoint changes to make directly on the screenshot of the dash saving a ton of time compared with the old method of emailing screen shots and feedback
Tableau - for the Dashboard (visualisation)
(Amazon) Redshift - for data storage > Mac mini - for data storage and MySQL data (for internal queries)