Reducing Early-Tenure Attrition
The problem: Nearly half of new hires in a high-volume hourly population were gone within 90 days. The recruiting funnel looked healthy — classes filled, offers accepted — so the failure was invisible in the metrics leadership watched. Attrition was treated as an operations problem, not a hiring problem.
What I built: Four interventions running at once, each aimed at a different point where the process was setting people up to leave. Revamped job descriptions to set honest expectations about the actual day-to-day. Redesigned prescreen forms to qualify deeper instead of confirming interest. Partnered with Operations to rebuild manager interview guides. Instituted weekly 1:1s with every recruiter reviewing submitted candidates, attrited candidates, and the trends connecting them.
Approach: The 1:1 review is the part that mattered. Attrition data is useless to a recruiter as a monthly aggregate — it becomes useful when you sit with the specific people who left and ask what the process missed. Recruiters started recognizing their own patterns before I had to point them out.
Outcome: Cut 90-day attrition by nearly twenty points, sustained across the following year. Fill rates rose over the same period rather than falling, which was the real test — quality improvements that cost you volume do not survive contact with the business.
Lesson learned: Early attrition is almost always a hiring problem wearing an operations costume. The candidates were qualified. The process was telling them the wrong story about the job.
Multi-State Class Hiring at Volume
The problem: Hiring against fixed operational start dates across five states, with classes that had to fill completely or the training cohort ran under capacity. Open-requisition thinking does not work here — a class that is 80% full on day one is a failure, not partial credit.
What I built: Predictive offer models built from historical attrition data, calculating how many offers a class of 20 required to account for before-start drop-off. Operational trackers covering requisition velocity, background check status, interview availability, and candidate quality. A centralized knowledge library and two role guidebooks so new hires and contractors could reach productivity without relying on tribal knowledge.
Approach: Everything was built to be run by non-technical operators. Excel and Power BI backends with form integrations, delivered in formats the team already used. A tracker nobody opens is worse than no tracker, because leadership believes it is being maintained.
Outcome: Roughly a thousand hires in the peak year with fill rates improving from the mid-70s to the low-90s, then 100% fill on every class the following year. When the business committed to a large fourth-quarter hiring push in a state with no operating footprint, we delivered 350+ hires in a single quarter by building outbound relationships with every Chamber of Commerce and Department of Labor office statewide.
Lesson learned: Volume hiring is a capacity problem before it is a sourcing problem. Most of the wins came from knowing how many offers we needed, not from finding more candidates.
Compliance Audit Automation — the audit machine, demonstrated
The problem: Manual compliance reviews couldn't keep up with posting volume. Non-compliant postings were reaching candidates before anyone caught them, and leadership had no visibility into the pattern.
What I built: A working MVP of the same machine my audits run on: extraction, rules engine, dashboard, receipts. Python scripts pull the data, a JSON rules engine flags violations by category, and an HTML dashboard gives leadership a live read with correction guidance for recruiters.
Approach: Built as a demo / MVP in a morning. In a regulated security environment, production builds are handed to engineering by design, and I know why.
Outcome: Projected to replace 10+ hours of weekly manual spot-checking. Gave leadership compliance visibility they didn't have.
Lesson learned: Sometimes the best solution isn't elegant. It's the one you can ship same-day and hand off without a developer.
Phenom CRM Implementation — making the workflow testable
The problem: The tool was being configured before the recruiting process was fully settled. Teams did similar work in different ways, and some of the people who would use the system every day were not close enough to the early design conversations. That matters because a CRM does not just store activity. It shapes how recruiters communicate, campaign, track, and report.
What I built: I turned open-ended workflow questions into things the project could test. I wrote and refined 124 test scripts, set up a way for global testers to submit issues, reviewed the feedback, documented defects, and built recruiter training around the places where the system would change day-to-day work.
Approach: I kept bringing the work back to ordinary recruiter behavior. If a recruiter sends a campaign, follows up by SMS, runs an event, checks analytics, or fixes a candidate record, what should happen next? What should the system capture? What would confuse the user? What would break reporting later? Those questions were more useful than asking whether the screen technically worked.
Outcome: The implementation had a clearer testing path before go-live. Issues moved from scattered tester reactions into documented findings, defects, and training needs. It also made the risk visible: if the real workflow is not written down, the tool will enforce whatever version of the process happens to make it into configuration.
Lesson learned: Before a recruiting CRM can work, the team has to define the process it is supposed to make easier.
LinkedIn Recruiter Utilization Analysis — finding the leak without guessing
The problem: A large enterprise LinkedIn Recruiter footprint was being treated like a fixed cost. Seats and job slots were available, but the real question was sharper: which capacity was actually supporting hiring, and which capacity was just sitting in the stack?
What I built: A month-by-month utilization model using reporting from the tool itself. I read recruiter-level activity, seat usage, job-slot use, and workflow demand together instead of treating one export as the answer.
Approach: I separated three questions that usually get blurred together: who is using the tool, where capacity is idle, and whether low usage points to training, redistribution, ownership, or reduction. The goal was not to punish low adoption. It was to understand what the tool was actually doing for the hiring process.
Outcome: Created a defensible path to resize or redeploy underused capacity while preserving the parts recruiters actually relied on. The recommendation was not "cut the tool." It was: recover the spend or recover the capability.
Lesson learned: Spend leaks do not show up in totals. They show up when seat capacity, job-slot demand, and workflow reality are read together.
AI Adoption Framework
The problem: Job descriptions were inconsistent across headers, tone, benefits language, and role detail. Recruiters often gave candidates a list of requirements, but not enough about the day-to-day work.
What I built: Using an internal LLM platform, I built recruiting personas for job descriptions, sourcing plans, screening questionnaires, and manager interview questions. Each one used conversational discovery instead of a blank prompt.
Approach: The job description persona helped recruiters draft in the right format, with clearer role context and company information. The sourcing persona built sourcing plans through discovery. The screening persona used the job description and intake notes to develop screening questionnaires. The manager interview persona used the job description, recruiter notes, and screening questions so managers could build interview questions without duplicating the recruiter screen.
Trained in smaller groups so the examples could match the roles each team worked on. Recruiting nuance matters. A customer service role, a technical role, and a leadership role do not need the same prompt.
Outcome: The output moved closer to the format and level of detail recruiters were supposed to use.
What made it work: The tool fit the workflow recruiters already had. It gave structure without asking them to become prompt engineers.