About the Organization
This mid-size engineering consulting firm operates across financial services, infrastructure, and digital transformation engagements. With approximately 600 engineers across four delivery units, they run 30–45 concurrent client projects at any given time, each with specific technical and domain requirements that change quarter to quarter.
The firm's business model depends entirely on accurate talent-to-project matching. An engineer placed on the wrong project — wrong skill level, wrong domain knowledge, wrong availability window — creates delivery risk from day one. At 600 engineers and 40+ projects, the matching problem is non-trivial.
The Staffing Problem
When a new project engagement was confirmed, the process for staffing it looked like this: the engagement lead sent a requirements document to four or five delivery unit leads via email. Each lead reviewed the requirements, checked their mental model of who was available and qualified, and responded within a few days with nominations. The engagement lead then ran informal conversations with the nominees, made a selection, and confirmed with HR.
From project confirmation to confirmed staffing, this process averaged 22 business days — nearly four and a half weeks. During that window, the engagement was committed to the client but the delivery team was unconfirmed. Engineers were informally "reserved" by delivery leads based on anticipated but unconfirmed need, which meant other projects couldn't request them, but they also weren't working on the new engagement yet.
The deeper problem was accuracy. "Who's available and qualified" was a question that individual delivery leads answered from memory and recent visibility. Engineers who had been less active in recent weeks were frequently overlooked, even when they had the strongest profile for a given requirement. Engineers who happened to be visible — presenting in team meetings, recently completing a high-profile project — were nominated ahead of less visible colleagues who were equally or better qualified.
What They Tried Before
Before deploying The Talent Factory, the firm had tried two approaches. First, a shared spreadsheet that delivery leads were expected to update with engineer availability and skills — it was abandoned within three months because maintaining it was a separate full-time job that no one had been assigned. Second, a Salesforce customization that tracked project assignments but not skills or availability — useful for billing, useless for staffing decisions.
The fundamental insight that neither approach addressed: staffing accuracy depends on the quality of the skills data, not just the availability data. Knowing who is free is necessary but not sufficient. Knowing who is free and has the specific skills the project requires — at the right proficiency level, with the right domain context — is what produces good matching.
Implementation
The firm deployed The Talent Factory in phases over 90 days. Phase 1 (Days 1–30) focused on building the Talent Roster and Skills Intelligence foundation: importing engineer profiles, establishing the skills taxonomy with delivery leads, and conducting baseline skills assessments across all 600 engineers. The taxonomy covered 180 technical skills across six clusters, calibrated to four proficiency levels.
Phase 2 (Days 31–60) activated the Engagements & Staffing module. When a new engagement was confirmed, the requirements were entered into the system and a ranked list of available, qualified engineers was generated automatically. Delivery leads reviewed the ranked list, adjusted for context the system didn't have (upcoming leave, client relationship preferences, development opportunities), and confirmed nominations within 48 hours.
Phase 3 (Days 61–90) integrated the Workforce Intelligence AI agent to provide natural-language queries across the talent database. Engagement leads could now ask "who in our Java practice has payment systems domain experience and is available in the first week of next month?" and receive a structured answer with ranked candidates, instead of routing the question through four delivery leads.
Results: 22 Days to 6
Within 60 days of activating the Engagements & Staffing module, average time from project confirmation to confirmed staffing dropped from 22 business days to 8. By day 90, it had dropped further to 6 business days — a 73% reduction.
The accuracy improvement was equally significant. In the 6 months following deployment, the firm recorded zero "staffing corrections" — cases where an engineer needed to be replaced on a project within the first 30 days because the initial match was wrong. In the 6 months before deployment, they had averaged four per quarter.
Bench rate — the percentage of engineers on active payroll but not assigned to billable projects — dropped from 14% to 9% within 90 days. The previously invisible pool of available, qualified engineers became queryable, and more of them were matched to projects more quickly.
"We used to run staffing through Slack threads and spreadsheet guesswork. Now it's a query. The decision that used to take three weeks takes an afternoon."
— Head of Delivery Operations
What Changed Day-to-Day
The most visible change was the elimination of the "staffing Slack message" — the informal broadcast that delivery leads sent to their networks when a project opened. This message had been the primary mechanism for surfacing candidates, and its elimination initially concerned delivery leads who worried about losing visibility into the candidate pool.
What they found instead was that the structured query produced a broader and more accurate candidate pool than the informal network had. Engineers who rarely appeared in staffing conversations — because they were heads-down on long-term projects rather than highly visible in team meetings — now appeared in every relevant query.
The second visible change was in calibration sessions. Monthly delivery reviews, previously spent arguing about who was available for what, shifted to forward-looking conversations about pipeline demand versus supply. The system provided the supply picture; the conversation focused on the gaps and how to address them.
Key Results Summary