How to Pick Which Employee Becomes Your AI Guy

Pick the person who is already asking about AI — the one playing with Claude on their lunch break — and check them against four traits: process knowledge, curiosity, your trust, and a track record of finishing things. Job title and seniority are nearly irrelevant; the right pick is usually your ops lead, your executive assistant, or the unofficial "tech person" everyone already asks about software.

This decision matters more than most founders give it credit for. The training turns whoever you pick into a builder — but the leverage of what they build is set by how well they know your business and how much rope you're willing to give them. Pick right and you get an internal AI champion who compounds for years. Pick wrong and you get a certificate on someone's LinkedIn.

What traits actually predict a good AI guy?

Four things, in order:

1. Process knowledge. They know where work actually gets stuck — not the org-chart version, the real version. Automation value lives in that knowledge. Someone who knows every broken process has a pre-loaded backlog of high-ROI targets from day one.
2. Native curiosity. You're looking for the person who already experiments without being told. The ones teaching themselves through YouTube right now. Curiosity can't be installed by a training program; building skill can.
3. Your trust. The champion will touch systems that matter — CRM, billing, client communication. If you'd hesitate to hand them the keys, they're the wrong pick regardless of talent.
4. Follow-through. Automations that are 90% finished are 0% useful. You want the person whose projects ship, not the one with the most enthusiasm in meetings.

Now the traits that don't matter, despite feeling like they should: a computer science degree, a technical job title, and seniority. Modern AI tools respond to plain language. The person doesn't need to code — they need to think in systems and finish what they start.

Why is it usually the ops lead, the EA, or the "tech person"?

Because those three roles sit at the intersection of the four traits:

• Your ops lead already knows every broken process in the company. They don't need discovery interviews — they've been quietly maintaining a mental list for years. Give them building skills and that list starts shrinking.
• Your executive assistant already keeps the wheels on and touches every system in the stack. They know exactly which work needs human judgment and which doesn't — which is precisely the line an automation architect needs to see.
• Your "tech person" — every team has one — is the self-selected candidate. People already route their software questions to them, which means the internal-trainer half of the champion role is pre-installed.

Who should you NOT pick?

Three tempting-but-wrong candidates:

• The most senior person, picked for optics. Seniority predicts a full calendar, and champions need building hours. Sponsorship should come from the top; the building shouldn't.
• The skeptic, picked to convert them. Training is not therapy. Send someone who wants to be there; the skeptic converts later, when the intake automation saves them four hours a week.
• Yourself. Founders make tempting champions — you have the context and the motivation. But you're the architect of the business, and every hour you spend wiring automations is an hour the actual architecture goes unattended. Delegate the building. Keep the deciding.

How do you make the ask?

Frame it as the investment it is, not extra homework. Something like: "I want to invest in you becoming our AI person. Thirty days of real training, on work time, building on our actual priorities. You come out of it as the person who builds our systems." Said to the right person — the curious one — this lands as a promotion in everything but title. The single most common response from the lunch-break-Claude crowd is some version of finally.

One caveat baked into that framing: on our actual priorities. An untrained curious employee drifts toward hobby projects, because nobody pointed them at the bottlenecks that matter. The mandate you grant should name the first two or three targets. What they learn, in what order, is covered in what your AI guy should learn first.

What if nobody on the team fits?

Be honest about which trait is missing. If it's building skill — that's what training is for; that's the fixable one. If it's curiosity or follow-through across the entire roster, you have a hiring-bar problem that predates AI, and your next hire should be screened for exactly those traits. What you should almost never do is respond by hiring a dedicated "AI specialist" from outside — the trade-offs of that route are laid out in should you hire an AI guy or train one.

FAQ

Should my AI guy be the most senior person on the team?

No. Seniority predicts calendar load, not building ability. The best champion is the person with the deepest process knowledge and the strongest curiosity — often mid-level. Senior sponsorship matters; senior selection usually backfires.

Should the AI champion come from IT?

Not necessarily. IT skill helps but business context matters more, because modern AI tools respond to plain language. An ops lead who knows every broken process typically ships more valuable automations than a sysadmin who doesn't touch the revenue workflows.

What if my AI guy quits after we train them?

The systems they built stay, the documentation stays, and the team they trained stays. That's the advantage of build-in-house over rent-a-consultant: attrition costs you a person, not the capability. And in practice, giving a curious employee a real mandate is a retention move, not a flight risk.

Can the founder be the AI guy?

You can, but you shouldn't. Your job is architecture — deciding what the business builds — not personally wiring every automation. Founders who become the AI guy become the bottleneck. Pick someone whose calendar can absorb the building.