Tag(s), You’re It! Overhauling our Lever ATS Tags

Over the last several months, Viget’s recruiting team has been working to revamp our internal tools and processes. One of the tools we use daily is our Applicant Tracking System, or ATS. ATSes have an interesting reputation online as the tools that ‘decide,’ based on keywords and other black box criteria, whether your resume gets read by a human. But ATSes — at their core — do exactly what they proclaim to do: they track applicants. Lever is our current ATS. We create jobs in Lever, people apply through Lever, and the information they share in those apps is presented to us in a UI intended for application review and tracking candidates as they move through our evaluation process.

There are plenty of plug-ins and third party platforms that can help extend ATSes or achieve the keyword-y filtering that most folks associate with modern app review; but as it stands at Viget (where we hire intentionally and deliberately slowly), we don’t do any of that. We review candidates ourselves, manually, and just use the ATS to help keep us organized.

So, it’s even more important to ensure that the way we set up our ATS serves our recruiting team and our candidates. One big room for improvement in our ATS was how we leverage Tags. Tags are used to capture characteristics about the candidate to which they are attached. They can be used as search parameters and serve as quick identifiers when clicking into a candidate. Tags should not be used to capture information that can be stored elsewhere in a separate field (e.g., where they first heard of us, the date they applied), because redundancies make structuring searches difficult and it becomes hard to determine the ‘source of truth.’

Several years ago, the team migrated our data from another system to Lever. At that time, we were using a system that had limited out-of-the-box fields or properties within which you could store essential information about a candidate. So, the team turned to Tags. Before the migration, we also had to store info that couldn’t be easily migrated for whatever reason (like the date of application and why a candidate was rejected) in Tags. So, there was already some bloat that we had to bring into Lever.

When we initially made the switch, there wasn’t really a foolproof way to “lock down” tag creation. So, you’re left with a system that has some bloat in it… that also enables you to add unlimited open-text options… that, oh yeah, is case-sensitive.

Needless to say, things got a bit out of hand. We ended up with 1,481 tags in our system! But we were only consistently using a handful. We needed to clean this up.

So, I put on my UX hat and got to work.

Digging through these tags was actually pretty fun. Some of the recommendations and decisions were straightforward. For example, when redundancy was caused by capitalization issues, we’d merge them.

Some redundancy issues were due to lack of consistency:

And sometimes it was a matter of re-categorizing outdated terms to align with how we’re doing things now, like tags related to the now-PL/UI team.

There were other tags where I needed a Viget consultant with more historical context. After all, I’ve only been on the Recruiting team for a year and a half, and at Viget for a couple more years. But there’s over a decade and a half of data here.

Ultimately, we got to the bottom of it!

I made at least 1,481 CRUD MACK (Merge, Annihilate, Create, Keep) decisions, and kept track of those recommendations in a spreadsheet. I ran those decisions by some key stakeholders, then dove into Lever itself. After our first sweep, we were down to ~500 Tags. After the second iteration, we had less than 150. 🎉

To help make sure we maintain these Tags over time — creating new ones that serve our needs and systematically removing unhelpful ones — I put together some guiding principles and set periodic reminders to clean-up our tagging system.

The principles are:

• Applicability

  • Is it narrow enough that it’s identifying a discrete and helpful subset of candidates?

  • Is it broad enough that it’s a meaningful category? Will there be multiple people tagged this way?

• Usefulness

  • Will we search for it later?

  • Can/will we report on it?

• Distinctness

  • Is it distinct from existing Tags, Source Tags, and candidate fields?

  • If it is not distinct from an existing tag but still feels useful, are there ways to merge, rename, or recategorize to improve our categorization?

• Clarity

  • Is the proposed label itself unambiguous?

  • Would it make a reasonable amount of sense to someone without deep historical context / institutional knowledge (e.g., a new recruiter)?

  • Is it spelled right?

• Accuracy

  • Are there ways to automate or standardize how we set this Tag?

  • If there are past candidates who fit into this category, are there ways to quickly search or sort past candidates so that we can tag them appropriately?

This work will hopefully help ensure our ATS is clean, organized, and useful, which will in turn help make us better at our jobs.

For example, when we talk to people that are awesome but not quite the right fit for our current team needs, we can tag them with “Keep in Mind'' to indicate long-term potential. And, if we think we might be hiring someone with their skillset within the next year or so, we can also tag that candidate with a time period (e.g., “Q1 2024”). This effectively creates a list of high-potential candidates to reach out to in a few months.

As with any role or function, the systems we work within often dictate our workflows rather than the other way around; that’s not always helpful. I’m excited for our team to continue to level up how we mold our systems so that they serve our needs and the needs of our candidates.