This year, I used AI to help me fill two roles I had never hired for before: a senior marketing specialist to consult with each of our four regional offices on local marketing needs, and a marketing operations lead to build automations that compress the time it takes to run our marketing engine. The approach that made both searches work was one I borrowed, without fully realizing it at first, from my developer colleagues: spec-driven development.
The Talent Profile Is a Spec
A few years ago I wrote about talent profiles, a tool we use at Atomic Object to go deeper than a job description before we ever start recruiting. A talent profile answers the questions a job posting glosses over:
- What does success look like at 30, 90, and 180 days?
- What are the biggest challenges the person will face and how would they get through them?
- Which requirements are non-negotiable and which are merely preferred?
- What does the team dynamic actually look like day to day?
This year, working on these two searches, I realized a talent profile is functionally the same thing as a software feature spec my developer colleagues write before starting a story. It is the contextual basis for every decision that follows.
What Goes In One
Both profiles I wrote this year follow the same skeleton:
- Milestones at 30, 90, and 180 days and at one year, written as things I could observe rather than qualities I hoped for.
- A short list of the handful of outcomes that matter most in the first year, separate from the long list of everything I will eventually measure.
- The biggest challenges the person will face, each paired with how someone might get through them.
- Required experience: years in the work, plus specific things the person has already done.
- Competencies, each with a definition of what it looks like in practice.
- Technical requirements, split into required and strongly preferred.
- Who they report to, who they work with daily, and what the environment feels like.
Stress Testing the Spec
I spent a disproportionate amount of time in the definition phase, and that was the point. My colleague Drew Colthorp argues in Agentic Engineering for Teams that building software has gotten cheap and fast while defining the work has not, so the expensive part of the job moves upstream. Hiring works the same way. I used Claude to stress test the talent profile for each role, attacking it and beating it up from every angle I could think of, until I was confident it represented an accurate picture of who I was actually looking for. That work happened before I wrote a single word of a job posting.
The concern I kept circling was resourcing. Both roles rearranged responsibilities that other people used to hold, and I did not want to write two profiles that could not fit inside two real jobs. So I pulled our time tracking data and estimated how long each task took before any automation existed, which let me test the split against real numbers instead of guessing at it. The division held up, and where the load was heaviest I named the challenge in the profile rather than leaving it unsaid.
One Spec, Every Downstream Decision
Once the talent profile was locked in, it became the reference point for everything: sourcing, the job description itself, interview questions, and evaluation rubrics. Every one of those artifacts traced back to the same document, the same way a developer’s code traces back to a spec.
Sourcing was the most powerful example of the advantage I got in using the talent profile. I fed the talent profile into Claude and asked it what LinkedIn keywords, Boolean searches, and other parameters I should use to find the right candidates. I followed its recommendations and came away with a ranked list of people to reach out to. One of them became our first Marketing Operations Lead.
Less Second-Guessing
The efficiency improvements were real, but the bigger win was psychological. Because I had done the hard work of becoming opinionated during the spec-writing phase, I spent far less time second-guessing myself. Lauren Davaloz, our Senior Technical Recruiter, held me accountable to that spec throughout, pushing me to either stick to the decisions I had made or to consciously revise the talent profile if I had a new realization about what I valued. What she did not let me do was drift from it without noticing. Drew calls that failure mode drift, and prescribes the same fix: change the spec first, then bring everything downstream into alignment.
That discipline carried into the interviews. Lauren and I built the rubric for each portion of the interview and then checked the whole set for coverage, so that every variable in the talent profile had to be proven somewhere, either through conversation or through demonstrated ability. By the time I made each offer, I did not have to wonder whether the person matched the profile. They had already proven every part of it.
Of everything I tried this year, this is the process I am most grateful for. It gave me a north star, and Lauren made sure I kept looking at it.
Where I Did Not Use AI
I graded the take home assignments and the interviews by hand. That was the line I chose to hold. AI helped me define what I was looking for, but it did not get to decide who met the bar. The spec is what let me do that grading at a distance, because I was scoring against criteria I had set weeks earlier, when I was thinking clearly rather than in the middle of a hard call.
Afterward, out of curiosity, I ran the same assessments through AI to see what it would have said. It had a curious tendency to overindex on some features while glossing over things I had marked as red flags. I am glad I had my own scores first.
Try It Yourself
If you hire, you already have something like a talent profile, even if it lives in your head instead of on paper. Write it down. Stress test it with AI before you rely on it. Then treat it the way a developer treats a spec: the source of truth you return to for every decision downstream, and something you revise on purpose when it needs to change.