“So much I wish I knew: challenges of navigating internally approved infrastructure tools, cost accrued by switching HR tech stack, etc. Would definitely encourage People Analytics teams to focus more on quick analyses and data consultations as a basis to understand what's needed before embarking on the build journey, even if that's the final destination. Time to value takes so much longer w/ build and teams need to keep delivering value in the meantime regardless!”

“The maintenance on the following are enough to make me pull my hair out... APIs, data models, role-based security, UX enhancements/preferences, stakeholder speed expectations, data augmentation... You can spend years getting that right, when there are already vendors that do all that. Spend your time doing the higher value analyses on initiatives that leaders need.”

“Some of these problems are probably obvious, but I didn't realize them at the time:

• Once you turn something on, you can't just walk away from it and expect it to run itself. Have a clear plan for maintenance and support that aligns to your user group(s). This means you'll have to earmark time/resources to maintenance/updates, which could slow you down on future builds.
• The culture of the organization you operate in is going to influence the level of rigidity/flexibility you can build into the tool; align ahead of time but plan for enhancements.
• Think critically if a tool is even the right way to do things. Sometimes you aren't in a position of readiness as an organization to turn something into a tool because you haven't actually settled on a process or way of working yet.
• If something doesn't work well, you'll get lots of feedback. If it does work well, you're more likely to hear a “thank you” or silence and have to pull for feedback. Build active feedback solicitation into your process up front.”

“What I wish I would have known?...So many things:

• Why didn't I know it would take so long?
• Why is our data so horrible?
• Why does a "build" require us to "buy" so much tech to get up to speed?
• Why does no one care how hard this is? I could go on...”

“Here are several thing that I’ve learned from the experience:

• People analytics products/tools are only 1/3 the value of people analytics yet tend to absorb 2/3rds the budget or more if you try and build in house.
• Your first product builds should be on use cases that save end users time. Give people time back and you are a hero.
• Don't build your own from scratch in house in 99% of cases, especially if you want to scale.
• Good data engineers are expensive and the ones that really know HR and want to stay there are unicorns. The list goes on.”

“I love building stuff and all our stuff is built on good data foundations so some of the common challenges around data quality don’t come up often for me, but I’d still say:

• Just because you (the person building the tool) think something is simple to use does not mean the user will find it simple (or that it is simple)
• You’ll start redesigning your tools within about 1 minute of publishing them into the user community
• You will want to try and incorporate every cool trick you’ve seen on a YouTube tutorial even if a simple single bar chart will work
• A simple data table is your best friend
• Read storytelling with data by Cole Nussbaumer Knaflic before you start doing anything!
• You aren’t a UX or design expert so don’t expect your work to be incredibly “pretty” straight away.”

“What you need to know:

1. Data engineering is key. Ensure that you have the necessary infrastructure and skills to design and maintain the data flow. Don't cut corners, you don't want to build something unmanageable. If it's not a skill you have internally in HR (and it may make sense not to have it), make sure the Data team has resources allocated to your project (in our case, we insisted on having 1 FTE fully allocated to our budget).
2. Managing access is harder than you think. Row level security is a necessity, so model the data with that in mind. You don't want to manage each person individually.
3. It will take more time. It may even cost the same, but it will definitely be a longer project.

Now, the advantages of building it vs buying:

• the project itself is a good way of upskilling people• you can fully customize the solution and define the KPIs to make sure the transition easier. They get the number they are used to, just better presented. You may also have some specific areas which aren't addressed at all if you buy a tool (this was the main factor for us to decide to build it)• if you have a company DW/Portal, it's easier to integrate HR data with other areas - Finance, Production/Operations, whatever is important to contextualize the work.”