Two job postings, same title
Say you need a project coordinator. You write a job posting. It lists software, years of experience, maybe a degree preference. Fifty resumes come in. You interview the five that look best on paper.
That process feels careful. It is also often wrong, because it hires for a title instead of a gap.
A role is what a job description says someone should do. A gap is the actual hole in your operation right now: the specific thing that keeps slipping because nobody owns it. Those are not always the same thing, and mixing them up is one of the more expensive mistakes a growing contractor makes.
What “hiring for the role” actually gets you
When you hire for the role, you get someone who can do the job in the abstract. They know how to schedule, track costs, run inspections. They will probably do fine.
But “fine” is not always what the business needs. If your real problem is that field crews and the office never talk until something is already wrong, a competent generalist coordinator will not fix that. They will do the job as written, and the same breakdown will keep happening, just with a new name attached to it.
I have made this mistake. I hired based on resume strength more than once early on, and ended up with people who were qualified and still not useful, because the qualification did not match the actual hole in the company.
What hiring for the gap looks like instead
Before I post anything now, I ask a plainer question: what specifically is not happening that needs to happen? Not “we need a project manager.” More like: “nobody is catching material delays before they hit the schedule” or “field updates aren’t reaching the office until end of day, which is too late.”
That question changes the interview. Instead of asking someone to describe their experience, I ask how they would have handled a specific situation we actually had. Someone who has genuinely solved that kind of problem before answers differently than someone who has just read about it.
It also changes what I’m willing to trade off. A person who is a little rough on the software but has clearly closed communication gaps before is often a better hire than a polished operator who has never had to build a process from nothing. Software you can teach. Judgment under a real gap is harder to install after the fact.
The interview question that tells you the most
I ask candidates to walk me through a time something went wrong on their watch and what they changed afterward, not what they did to fix that one instance, but what they changed so it stopped being a pattern.
People who are used to owning outcomes have an answer immediately. People who are used to doing tasks tend to describe the fix to the single problem and stop there. Neither answer is disqualifying by itself, but it tells you which kind of hire you are looking at, and which kind of gap they will actually close.
Where this gets harder
The honest complication is that gap-based hiring takes more of your own time up front. You have to actually know what the gap is, which means being specific about your own operation’s weak points before you ever open a job posting. That is uncomfortable. It is easier to write a generic description and let the applicant pool sort itself.
It is also harder to defend in the moment when a strong-looking resume is sitting in front of you and the person who nailed your actual gap has a thinner one. I have talked myself into the safer-looking resume before and regretted it inside of six months.
What I check before I post a role now
I write down the gap in one sentence before I write the job posting. If I cannot state it in one sentence, I am not ready to hire for it yet, because I do not actually know what I am solving.
Then I build at least one interview question directly out of that sentence. If a candidate cannot engage with it specifically, no amount of general experience makes up for that.
It is a small change to how I hire. It has made a bigger difference than any other single adjustment I have made to bringing people into the company.