The shape of the talent databases an organization uses can dramatically change its ability to hire the best.
From the late 2000s, cloud-based technologies entered the talent space and HR started to question where they should store talent data. Despite the ongoing move to the cloud, the impact hasn’t matched their expectations of better employee experiences and workforce insights, and more real-time data and innovation. There are likely many reasons for this: the organizational structure, technology stack, company culture, and expertise are not sufficient to facilitate the change; not enough care has been put into the integration, implementation and adoption of solutions built on the cloud; or expectations are conflated.
But Talent organizations need to ask another question to realise value: how they should store data. This is a hefty topic on relational and non-relational databases, and below you’ll find an overview to get started. Before we get into it, keep in mind that “relational” comes from relational algebra, not relationships, which is what a graph—counterintuitively, a type of non-relational database—prioritizes.
If you’re short on time, here's the takeaway
Current talent database technologies aren’t built for the future of talent acquisition. Systems of record built on tables or documents alone cannot keep up with evolving organizational models, the growth in structured and unstructured data, and technologies such as machine learning, to deliver the rich insights, intelligent workflows and personalized experiences necessary today to stay ahead.
We need to model the data to reflect the real world of talent, in networks rather than tables or documents. Using graphs, we can do just that. We can:
- identify multifaceted connections between data points, where the data is not just a string of text or numbers, but a thing with meaning, to understand talent more deeply;
- determine the strength of each connection, including ones we didn’t know existed, to make more insightful judgements;
- find these connections in milliseconds instead of minutes, to act faster than ever before;
- remove data silos to view talent in totality;
- extend the database to account for vast amounts of new structured and unstructured data as the business or market changes, and in doing so be ready for the future.
This doesn’t mean you should rip and replace your existing databases with graphs. But it does mean it’s worth considering graph databases alongside them.
At Beamery, we store data in three main ways: tables, documents and graphs. Below you’ll find overviews of each.
Tables, or relational databases
This is the most prevalent way to store talent data—in tables, or “relational databases”. This works well with a predictable amount of well-formatted data, so it’s fine for a system of record as they are essentially giant spreadsheets. Imagine three tables, one for employee names, one for department names, and one for locations. To find out which employee works in which department and location, you would need to connect or “join” the information across the three tables. This isn’t a problem, and is a good format for reports, which is what we use it for.
The problem is it can be rigid and not easily scalable. If not organized properly, tables can get out of sync, and data that’s not in the same format, e.g. phone numbers or addresses, can be rejected from the table. Also, as data and the relationships between data increase, it gets harder and slower to maintain, extend and join tables. Tables don’t handle unstructured data well either, like job descriptions and resumes. The end result for modern talent teams and candidates using software built purely on relational databases is limited functionality and insights.
Document-oriented, a type of non-relational databases
You guessed it, information here is stored in documents. Imagine the same information from above, of employees, departments, and locations. But rather than store it across three tables that need joining, we can now have a document per employee, which holds information about their department and location via unique IDs. This is what we use to create our candidate-centric view in Beamery.
Unlike tables, documents can also hold unstructured information, such as portfolios, resumes, and interview videos. These databases also give us flexibility to augment candidate profiles with new types of information that we hadn’t planned for at the very beginning, without worrying about a rigid tabular structure rejecting the data.
But there’s still a limitation here. Documents don’t focus on the relationships between the data points and documents are stored in a hierarchical structure. E.g. we don’t yet explicitly know the strength of connections between any employee and another, or how essential a skill is to a job, or how similar one target company is to another. This is why we also store data in a graph.
In a graph, entities such as candidates, organizations, skills, locations, are held as “nodes”. Connections between these nodes are called “edges”, representing a relationship between each node. E.g. An employee Sarah would be a node, connected to the Marketing department node with the relationship of “is in department”, and connected to the London location node with the relationship “lives in”.
So why is this way of storing information better? Graphs inherently prioritize the relationships between data points, which allows us to find patterns and connections much faster and more easily than other databases. For instance, we can infer that Sarah and Hassan are colleagues. Graphs can also store multi-dimensional relationships, extend those relationships with new data without compromising the performance of the graph, and fill in blanks where data is missing when combined with AI. It is well-suited for generating personalized recommendations using machine learning, again because of the connectivity between data points.
We can use the graph to predict in real-time which candidates are the ideal fit for which roles due to the strength of connections between them, across both internal and external talent, for all roles. E.g. For each candidate, we can compare and weigh up: the relationships between their current and desired skill sets to the role’s required skill set; their ability to learn new and relevant skills given the skills they already have; if internal, how the role fits into their career path; any links they have to employees in the organization; the companies they’ve worked at to find ones with similar challenges; and the relevance of any training and education.
Each type of database has their use. However, graph databases offer a significant opportunity to level up the talent organization with intelligence that’s previously been out of reach. So next time you’re considering technology partners, ask them not only where they store their data, but also how.