When hiring feels chaotic, buying a system feels like progress. There is a demo, a setup call and a new dashboard. For a few weeks, things look more organised.
Then the old problems come back, now inside the software.
Earlier we argued that you should draw the process before you choose a tool. This article picks up at the next moment: setup. It is where an undefined process gets locked in, and where most of the damage is done.
What software does well
It is worth being fair to the technology first. A good hiring system can centralise applications, automate reminders, show where every candidate stands and keep a record of who decided what. For a small team juggling inboxes and spreadsheets, those are real gains.
What a system cannot do is decide what your organisation means by a strong candidate. If the team has never agreed, the software will not agree for them.
How confusion gets configured
Setup asks a lot of questions. Which stages does a candidate move through? What does an interviewer fill in? Who gets notified, and when? If the team has not settled those answers, someone guesses, and the guesses become rules.
Three things tend to happen.
Vague criteria become fields. "Good culture fit" turns into a dropdown with five options nobody defined. It now looks like data. It is still a feeling.
Unnecessary stages become workflow rules. A step that existed because one manager liked it is now a required stage. Candidates cannot move forward until someone clicks it.
Inconsistent decisions are stored more neatly. Two interviewers still judge candidates on different things. The difference is that their notes now sit in tidy boxes, which makes the inconsistency harder to spot.
The result is confusion that is faster and more permanent than before. It is also harder to change, because changing it now means changing the configuration.
Designed for an imagined organisation
There is also a practical limit. Small teams abandon useful systems when the setup feels too complex for the way people actually work.
This usually happens when the process was designed for an imagined organisation rather than the real one. Twelve stages, four approval levels and a mandatory scorecard for every phone call might suit a company with a recruitment team. For a team of fifteen where one manager does most of the hiring, it is a reason to go back to email.
The UK government's guidance for building digital services makes the same point in a different setting. Its Service Standard tells teams to design around the needs of users, not around technologies or pre-selected solutions. Its section on understanding users and their needs warns that the real problem might not be the one you originally thought needed solving, and says that testing assumptions early reduces the risk of building the wrong thing. A hiring workflow is a small service whose users are your own team and your candidates. The same rule applies.
The sequence that works
The order of decisions matters more than the choice of product.
1. Define the work. Agree why the role exists and what the person will do in the first six months.
2. Agree the minimum evidence. Decide the three to five things you need to see to make a decision, and how each will be judged.
3. Assign ownership. Name who owns each stage, who makes the final call and who keeps the candidate informed.
4. Simplify the stages. Remove any step that does not help someone decide better. We covered how to tell the difference in Hiring needs structure, not bureaucracy.
5. Then configure the system. Now the setup questions have answers. Stages match real steps. Fields match agreed evidence. Notifications go to named owners.
Automation raises the stakes
The more a system does on its own, the more this matters. When a tool screens or ranks candidates automatically, any unclear criteria are applied to every applicant, at speed.
In 2022 the US Equal Employment Opportunity Commission and the Department of Justice warned employers that without proper safeguards, workers with disabilities may be screened out by algorithmic decision tools, and that employers should have a process for providing reasonable accommodations when they use them. The employer, not the software, is the one who has to be able to explain the decision.
A quick before and after
Here is the same interview stage set up two ways.
Before: the team adds a stage called "Second interview" with a single notes box and a five star rating. Each interviewer rates on whatever they think matters. Three months later, nobody can say why one candidate with four stars was rejected and another with three was hired.
After: the team first agrees that the second interview tests two things, how the candidate plans a project and how they handle a difficult client. The stage gets two fields with a short scale for each, and one named person makes the decision. The software is the same. The decisions it records can now be compared and explained.
A quick test before you configure anything
Before you open the setup screen, check whether your team can answer each of these in a sentence:
- What does a strong candidate for this role look like?
- What evidence will each interviewer record?
- Who makes the final decision?
- What happens to a candidate after each stage, and who tells them?
If the answers come quickly and match, you are ready. If they do not, the software will not answer them for you. It will just make the disagreement look official.
The bottom line
A new system cannot rescue an undefined process. Software should carry a good process: centralise it, remind people, show progress and keep the record. It should not be asked to invent one. Define the work, agree the evidence, assign the owners, simplify the stages, and only then configure the tool around those decisions.