Marcus is the VP of Talent at a 1,400-person healthcare technology company. His team of 11 recruiters fills roughly 320 roles a year, and the CEO has just asked him a deceptively simple question: "What is our AI plan for hiring over the next three years?" Marcus has used a few AI tools already, a resume summarizer here, a job-description rewriter there, but he has no strategy, no budget line, and no governance. This project walks through exactly how he turns that one question into a written, phased 2-to-3-year strategy he can defend in front of the board, the works council, and his own skeptical recruiters. The deliverable is a document, not a slide. It states where AI gets deployed, in what order, what it costs, who governs it, and how he will know it is working.

Step One: Set an Honest Baseline

A strategy built on an inflated view of the current state collapses the moment it meets reality. Before Marcus writes a single roadmap line, he documents where his function actually stands today. He inventories every place AI already touches hiring, including the unofficial ones: two recruiters quietly paste job requisitions into a chatbot to draft postings, and one uses an AI note-taker in intake calls without anyone having reviewed the vendor's data handling. That shadow usage is itself a finding. It tells Marcus that governance is not a future project he is choosing to start; it is already overdue, and the strategy has to open by catching up rather than by getting ahead.

He captures four baseline numbers that will anchor every later claim of progress: average time to fill is 41 days, cost per hire is roughly $4,200, recruiter capacity sits at about 29 open requisitions each, and offer-accept rate is 71 percent. The reason for writing them down before anything else is not ceremony. In eighteen months, when someone asks whether the investment worked, the only defensible answer is a comparison against a number that existed before the work began. A baseline captured after a rollout has started is a number contaminated by the thing it is supposed to measure.

He also rates the things that are harder to quantify, and he does it in plain language rather than with a maturity score nobody will remember. Data readiness is weak: his applicant tracking system holds six years of inconsistent stage labels that no model could learn from cleanly, and that single fact will shape the sequencing of the entire roadmap. Team AI fluency is uneven, with two recruiters who are enthusiastic power users and the rest wary. Governance is effectively nonexistent, with no inventory of AI tools, no bias-testing requirement, and no named owner. Writing all of this down does two things. It gives the CEO an honest starting picture, and it gives Marcus a yardstick so that in eighteen months he can prove the strategy moved something real.

Step Two: Write a Vision Worth Funding

Marcus drafts a three-year vision in language a non-recruiter can repeat. His version: "In three years, our recruiters spend their time on judgment and relationships, not on copy-paste administration. AI handles the repeatable first drafts, we measure every automated step for fairness, and candidates experience a faster, more transparent process." Notice what the vision does not say. It does not promise to replace recruiters or to let a model make hiring decisions. A vision that overpromises automation invites both employee fear and regulatory scrutiny, and it sets a target the team will resent and quietly work against.

The vision is paired with three measurable objectives so it is more than a poster. First, reduce time to fill from 41 days to roughly 30 without lowering quality of hire. Second, give each recruiter back an estimated 5 to 7 hours a week of administrative time to reinvest in candidate relationships. Third, reach a state where every AI tool that touches a candidate decision has a documented owner, a bias audit on file, and a candidate-facing disclosure. The first two objectives win executive support; the third keeps Marcus out of trouble, and he treats it as non-negotiable rather than as a nice-to-have. Writing the third objective at the same altitude as the first two is a deliberate act, because an obligation listed under "risks and considerations" is an obligation that gets traded away when the timeline tightens.

Step Three: Build the Phased Roadmap With Real Numbers

The heart of the deliverable is a roadmap that sequences use cases by risk and readiness, not by hype. Marcus uses a simple ordering rule: start with use cases that are high in time savings and low in candidate-decision risk, and defer anything that scores or ranks people until governance is mature. The rule does real work, because the tools with the most impressive demonstrations are usually the ones that evaluate candidates, and they are exactly the ones that carry audit obligations, fairness exposure, and a need for monitoring infrastructure his function does not yet have. Sequencing is where a strategy either builds the capacity to hold its own later phases or commits to a deployment it cannot govern.

Two design choices in that table are worth making explicit in your own version. The first is that Phase 1 spends real money on things that produce no efficiency at all: an inventory, an intake form, a review group, a part-time governance lead. That is not overhead grudgingly tolerated, it is the load-bearing structure that makes Phase 2 legal and Phase 3 possible. Strategies that cut this line to improve the first-year business case are the ones that stall twelve months later, when a screening tool is ready to deploy and there is no body that can approve it and no audit anyone can point to.

The second is that the budget lines are attached to phases rather than to a single total. Marcus presents a three-year investment of roughly $300,000 as his headline, and the discipline he owes the board is that the headline must reconcile to the sum of the phase lines, including the recurring audit cost that persists after Phase 3 ends. An executive who funds a rounded total and later discovers a recurring line that was never in it will not fund the next thing you ask for. Show the phases, show the recurring costs separately from the one-time ones, and let the headline be whatever the arithmetic produces.

Step Four: Plan the Capability, Not Just the Tools

The roadmap buys software; the strategy has to buy the ability to use it. Marcus's baseline told him that team fluency is uneven, so Phase 1 sends three recruiters to structured AI training and designates one as the team's AI champion, a named person whose job is to answer the small practical questions that otherwise become reasons not to use a tool. This is deliberately narrow. Training everyone at once, before there is a tool in daily use, produces a room full of people who will have forgotten it by the time it matters; training a few early and letting them support the rest matches the pace at which the tools actually arrive.

Capability is also what makes the later phases safe rather than merely possible. The Phase 2 half-headcount for a talent-analytics partner exists because someone has to run the quarterly fairness reviews, and a review that nobody has the skill or the time to perform is a commitment that will be missed and then quietly dropped. When you draft your own roadmap, check each governance commitment against a named person with the capacity to honor it. A strategy that promises monitoring without funding the monitor is making a promise on someone else's behalf.

Step Five: Define What Success Looks Like

A roadmap without metrics is a wish list, so Marcus defines success on four axes and ties each back to his baseline. Efficiency: time to fill trending from 41 toward 30 days, and 5 to 7 hours per recruiter per week freed up. Quality: offer-accept rate holding at or above 71 percent and hiring-manager satisfaction steady or improving, so that speed never comes at the cost of fit. Fairness: pass-through rates across demographic groups staying within agreed tolerances, with any drift triggering a review. Adoption: at least 9 of 11 recruiters actively using the core tools by the end of Phase 2.

The quality axis is doing something specific that is easy to miss. Efficiency metrics improve almost automatically when you remove steps, so a strategy measured on speed alone will look successful while it is degrading. Pairing each efficiency target with a guardrail metric that must not move is what turns the dashboard into an honest instrument. Marcus also tracks two softer signals over the three years: candidate-facing brand sentiment, since a faster process that feels impersonal costs him in ways time-to-fill will never show, and recruiter proficiency rather than raw usage, because a tool that everyone opens and nobody uses well is an adoption number hiding a capability problem.

Step Six: Give Governance Real Authority

Governance is the part most strategies fumble, because policies without enforcement become theater. Marcus gives his governance actual authority: the cross-functional review group can block a tool from launch, not merely comment on it. Every candidate-facing tool needs a named owner, a bias audit on file, and a documented escalation path for when monitoring flags a problem. He also writes a rule he can enforce rather than an aspirational one. Instead of "all AI must be fair," the standard is "no tool that affects who advances goes live without a completed bias audit and a named owner," which is a condition someone can check before a launch date and either meet or fail.

Where relevant law applies, he names it explicitly in the document: the EEOC's position that anti-discrimination obligations extend to algorithmic tools, New York City's Local Law 144 requirement that automated employment decision tools used on NYC candidates undergo an independent bias audit with results published, and GDPR data-minimization and transparency duties for any candidates in the EU. Naming the law turns governance from bureaucracy into a defensible compliance posture, and it does something practical inside the roadmap too: a named obligation can be given an owner, a budget line, and a phase, which is why the independent bias audit appears in Phase 2 as a $25,000 item rather than as a risk paragraph.

Step Seven: Communicate the Strategy to Each Audience

The same strategy lands differently with different audiences, so Marcus writes a short message track for each rather than distributing one deck and hoping.

Tailoring the message is not spin. The core story stays identical and only the emphasis shifts, which is a distinction worth holding to, because the moment the recruiter version and the board version contain different facts you have created a problem that will surface at the worst time. The fastest way to stall an AI strategy is to give every group the same deck and let each one fixate on the part that worries them most.

Step Eight: Say How the Strategy Will Be Adjusted

A three-year plan written in a landscape that changes every quarter needs a stated revision mechanism, or it will be silently abandoned rather than deliberately updated. Marcus writes the rhythm into the document itself: a quarterly checkpoint against the four success axes, a formal review at each phase boundary, and a short list of conditions that would trigger an off-cycle rethink, such as a fairness metric moving outside tolerance, a regulatory change in a jurisdiction he hires in, or a Phase 1 use case failing to produce the time savings it was funded on.

Each checkpoint has to be able to produce three outcomes, not one: continue, adjust, or stop. A review that can only conclude "on track" is a status meeting, and it will keep a failing use case alive because nobody was authorized to end it. Naming stop as a legitimate result in advance is what gives Marcus permission to retire something in month fourteen without it reading as a failure of the strategy. It is the strategy working.

Your Deliverable

You should finish with a written document of a few pages containing: the baseline, both the four numbers and the honest qualitative ratings; a vision paired with three measurable objectives; the phased roadmap with use cases, capability and governance investments, and budget per phase; the capability plan with named people; the success metrics tied to baseline values, with guardrails; the governance standard, its authority, and the named legal obligations; the audience message tracks; and the review rhythm with its trigger conditions. Then apply one test before you circulate it. Hand it to the most skeptical recruiter on your team and ask what they think will actually change about their week. If they cannot tell you, the document is a position paper rather than a strategy, and the gap they cannot fill is the part your executives will ask about first.

Anti-Patterns

Planning from an aspirational baseline. This is writing the roadmap from how the function is supposed to work rather than how it does, with the shadow usage left out because it is embarrassing and the data quality described as adequate because nobody has checked. It happens because the baseline section is written last, under time pressure, by someone who already knows what the roadmap says. What goes wrong is that the sequencing rests on capabilities that do not exist, and eighteen months later there is no defensible way to show the investment changed anything, because there is no uncontaminated number to compare against. The counter is to write the baseline first, include the unofficial tools, and record the qualitative weaknesses in plain language.

Sequencing by demo quality instead of by risk. This is ordering the roadmap around whichever tool impressed the leadership team most recently, which is reliably the one that scores or ranks candidates. It happens because the highest-risk category is also the most visibly transformative, and because a sequencing rule feels like an obstacle in the room where the demo just happened. What goes wrong is that the first deployment is the one requiring an audit, a monitoring capability, and an approval body, none of which exist yet, so the launch either slips badly or proceeds ungoverned. The counter is a written ordering rule, high time savings and low candidate-decision risk first, applied before anyone sees a demonstration.

Funding the tools and not the scaffolding. Here the roadmap carries license costs and nothing for the inventory, the review group, the analytics half-headcount, or the audit line, because those items improve no metric in year one. It happens under pressure to show a clean business case. What goes wrong is that every governance commitment in the document becomes a promise made on someone else's unfunded time, and the first phase boundary arrives with the monitoring undone. The counter is to attach each governance commitment to a named person and a budget line in the same table as the tooling, so cutting it is a visible decision rather than a silent one.

Objectives with no guardrail. This is a strategy measured only on speed and cost, so time to fill improves, cost per hire drops, and nobody notices the offer-accept rate sliding or the fairness metrics drifting. It happens because efficiency metrics move first and move most, and they are the ones the CEO asked about. What goes wrong is that the strategy reports success throughout the period in which it is degrading quality, and the correction arrives only when a hiring manager escalates. The counter is to pair every efficiency target with a metric that must not move, and to review both at the same checkpoint rather than in different forums.

A three-year plan with no way to change it. The document is approved, filed, and treated as fixed, so when a Phase 1 use case underdelivers or a regulation shifts, the strategy is not revised, it is quietly ignored while people improvise. It happens because a plan that names its own revision triggers can feel like a plan that lacks confidence. What goes wrong is that the organization loses the distinction between a deliberate change of course and a drift, and the next strategy document is trusted less because the last one was abandoned without explanation. The counter is a written review rhythm where continue, adjust, and stop are all legitimate outcomes, with the trigger conditions named in advance.

Practice

• Write your baseline in one page, shadow usage included. Capture your equivalents of time to fill, cost per hire, recruiter capacity, and offer-accept rate, then list every AI tool touching hiring, including the ones nobody approved. Rate data readiness, team fluency, and governance in plain sentences rather than scores. Notice which of the four numbers you had to estimate; that is your first data-infrastructure task.
• Draft the vision in one sentence a non-recruiter can repeat. Then check it against two tests: does it promise anything about replacing people or automating decisions, and could someone tell whether it had been achieved? Rewrite until it fails the first test and passes the second.
• Sort your candidate use cases on two axes. Place each on time saved and candidate-decision risk. Everything low-risk and high-saving is Phase 1 material; anything that scores, ranks, or filters people goes no earlier than the phase in which your audit and monitoring capability exists. Write down what has to be true before each deferred use case becomes eligible.
• Cost one phase honestly, separating one-time from recurring. Include tooling, training, governance time, and any audit. Then check that the sum of your phase lines equals the headline number you plan to present, and that the recurring lines are visible as recurring.
• Attach a name to every governance commitment. For each monitoring, review, or audit obligation in your roadmap, write who performs it and what portion of their time it consumes. Any commitment without a name is a commitment that will be missed.
• Write the four audience messages on one page each. Draft what you would say to executives, to your recruiters, to candidates, and to legal, data, and IT. Then read them side by side and confirm that no two of them assert different facts.

Reflection

• If your CEO asked today what your AI plan for hiring is, what would you actually say, and how much of it exists in writing?
• Which numbers in your baseline could you not produce this week, and what does that tell you about the sequencing of your roadmap?
• Which use case do you most want to deploy, and does your governance capability currently support it?
• What would have to happen for you to stop a use case you had already announced, and would anyone in your organization feel authorized to say so?

Glossary

• Baseline. The documented current state, both quantitative and qualitative, captured before any rollout begins. It is the only thing later progress claims can honestly be measured against.
• Shadow usage. AI tools already in use without approval, inventory, or data-handling review. Its presence in the baseline is a governance finding in its own right.
• Phased roadmap. A sequence of use-case deployments ordered by risk and readiness, each phase carrying its own capability, governance, and budget commitments.
• Sequencing rule. The written ordering principle, high time savings and low candidate-decision risk first, applied before any tool is evaluated so that enthusiasm cannot reorder the roadmap.
• Candidate-decision risk. The degree to which a use case influences who advances or is rejected. It is the axis that determines audit obligations, monitoring needs, and phase placement.
• Assistive, non-scoring use case. A deployment that drafts, summarizes, or supports without ranking or filtering people, which is why it can safely precede mature governance.
• Guardrail metric. A quality or fairness measure that must not deteriorate while an efficiency target improves, reviewed in the same forum as the target it constrains.
• Adoption versus proficiency. The distinction between how many people open a tool and how well they use it. High adoption with low proficiency is a capability problem wearing a success metric.
• AI champion. A named team member whose role is to answer the small practical questions that would otherwise become reasons not to use a tool.
• Enforceable standard. A governance rule stated as a checkable condition before a launch date, such as a completed bias audit and a named owner, rather than as an aspiration.
• Independent bias audit. An external assessment of a candidate-evaluating tool's selection outcomes, budgeted as a line item in the phase where such a tool first appears and recurring annually thereafter.
• Local Law 144. The New York City requirement that automated employment decision tools used on NYC candidates undergo an independent bias audit with the results published.
• Review rhythm. The scheduled checkpoints and named trigger conditions at which a strategy is continued, adjusted, or stopped, written into the document so that stopping is a legitimate outcome.

Related Lessons

• Strategic Assessment: Where Is AI Most Valuable? develops the opportunity analysis that feeds the use-case list this roadmap sequences.
• Roadmapping: Phased Adoption, Capability Building, and Culture Shift goes deeper on phase design and the culture work that runs alongside deployment.
• Governance Structures: Committees, Roles, and Decision Authority details the review group that this strategy gives authority to block a launch.
• Measuring Adoption: Tracking Usage, Proficiency, and Impact supplies the distinction between usage and proficiency behind the adoption metric.
• Building the Case: Efficiency, Quality, Fairness, Brand, and Risk is the argument structure behind the executive message track.
• Hands-On Project: Draft Governance Framework and Policies produces the framework this strategy funds in Phase 1 and depends on from Phase 2 onward.

Closing

The CEO's question was one sentence long, and the honest answer three years out is not a tool list. It is a document that says where the function stands, where it is going, in what order, at what cost, under whose authority, and by what evidence anyone will know. Marcus's version fits in a handful of pages, and its most valuable sections are the ones least likely to impress anyone in the room: the baseline that makes later claims checkable, the sequencing rule that keeps enthusiasm from reordering the plan, the governance line item that produces nothing in year one, and the review rhythm that permits a use case to be stopped.

What separates a strategy from a wish is that a strategy can be wrong in a way you would notice. Every element above exists to make some part of the plan falsifiable: a number that could fail to move, a guardrail that could deteriorate, an obligation that could go unmet, a checkpoint that could conclude stop. Write the document so that it can tell you it is not working, and you will have something worth defending in front of a board.

Key Takeaways

• Baseline before roadmap. Document real numbers, time to fill, cost per hire, capacity, and offer-accept rate, alongside honest ratings of data readiness, team fluency, and governance. Include shadow usage. A strategy without a baseline cannot show it worked.
• Write a vision that does not overpromise automation. Pair it with measurable objectives, and put the fairness and governance objective at the same altitude as the efficiency ones, or it will be traded away when the timeline tightens.
• Sequence by risk and readiness, not hype. Deploy assistive, non-scoring use cases while governance is built, and defer anything that influences who advances until audit and monitoring capability exists.
• Put real, phased numbers in the roadmap. Illustrative budgets of roughly $75,000, $115,000, and $145,000 across three phases turn a vision into something an executive can fund, and the headline total must reconcile to the sum of the lines, recurring costs included.
• Fund the scaffolding, not only the tools. The inventory, review group, training, analytics half-headcount, and audit line produce no year-one efficiency and are what make the later phases possible and legal.
• Pair every efficiency target with a guardrail. Offer-accept rate, hiring-manager satisfaction, and fairness pass-through rates must hold while speed improves, and proficiency matters more than raw usage.
• Give governance authority and name the law. A review group that can block a launch, an enforceable pre-launch standard, a named owner per tool, and explicit reference to EEOC obligations on algorithmic tools, Local Law 144 bias audits, and GDPR transparency duties.
• Tailor the message and schedule the revision. Executives hear ROI and risk, recruiters hear reassurance, candidates hear transparency, partners hear control, and the same facts underlie all four. Then write the review rhythm in which continue, adjust, and stop are all legitimate outcomes.

Frequently Asked Questions

Three years feels impossibly long to plan for when the tools change every quarter. Why not plan for one? Because the things that take longest are not the tools. Data quality, governance structures, team capability, and monitoring infrastructure are multi-year builds, and they are what determine which tools you can safely adopt when they appear. The horizon is not a commitment to specific products in month thirty; it is a commitment to a sequence of capabilities, with the use cases in later phases named provisionally and expected to change. That is exactly why the review rhythm and its trigger conditions belong in the document. A three-year plan with quarterly checkpoints and a stated way to be adjusted survives a changing landscape far better than a one-year plan that has to be rewritten from scratch every twelve months.

My executives want the efficiency gains but keep cutting the governance line. How do I defend it? Move it out of the risk narrative and into the roadmap arithmetic, where it is visible as a dependency rather than as caution. The Phase 2 screening use case cannot launch without a completed bias audit and a named owner, so the audit line and the analytics half-headcount are not overhead attached to Phase 1, they are the cost of the Phase 2 benefit everyone wants. Name the legal obligations explicitly, since an EEOC exposure or a Local Law 144 audit and publication requirement is a concrete cost of proceeding without them rather than an abstract principle. If the governance line is cut anyway, write down which later use cases become unavailable as a result, and get that acknowledged in the same forum.

What if our data is too messy to support any of this? That is a finding to build the roadmap around, not a reason to postpone one. Marcus's six years of inconsistent stage labels is exactly why his early phases contain assistive, non-scoring use cases: drafting and summarization do not depend on clean historical data, while anything that learns from or reports on your funnel does. Put the data remediation into the phase where it becomes a prerequisite, fund it there, and treat the ability to compute pass-through rates by stage and group as a capability milestone in its own right. A strategy that sequences around a real data weakness is more credible than one that assumes the weakness away, and it gives you something concrete to show at the first checkpoint.