Probably not yet, and if you do it too early you will hire the wrong person for a job nobody has defined. Most engineering firms under a few hundred people do not need an AI lead. They need one existing engineer given real time, a small budget, and the authority to decide. The title becomes worth creating later, when there is more work than one person's spare capacity can hold.
I say this as someone whose business would benefit from telling you otherwise. The firms that hire first and think second usually end up with an expensive person producing decks.
What the role actually is at each stage
Before adoption. The work is evaluation and policy: which tools, which data, what the rules are, what to try first. It is perhaps a day a week for a quarter. It requires someone who understands your workflows deeply and can hold a vendor to an honest answer. Domain knowledge matters far more than technical depth here, and you already have this person.
During adoption. The work becomes enablement: training, answering questions, watching what people actually do, fixing the things that break, and keeping the pilot honest. This is where the time requirement grows past a side project, usually to two or three days a week. It is also where firms most often stall, because the person doing it still has a full project load and the project load always wins.
After adoption. Now it is governance and integration: which tools stay, how they connect to your existing systems, what gets measured, what the next workflow is. This is a real job, and by the time you get here you will know exactly what it is because you will have been doing it.
The sequencing point is that the job description writes itself if you wait. Firms that hire at stage one are guessing at a role they have not experienced, and the guess is usually wrong in a predictable direction: they hire for technology and discover the hard part was people.
Who this should be
If you take one thing from this: pick an engineer your people already trust, not your most technically curious person and not someone from outside.
The obstacle in AEC adoption is almost never technical. It is a senior engineer who has watched three software rollouts fail and has decided in advance that this is the fourth. That person is not persuaded by someone who cannot read a set of drawings. They are persuaded by a colleague whose judgment they already respect saying they tried it on a real project and it held up.
The specific traits that matter: they understand at least two of your workflows end to end, they have credibility with the skeptics rather than just the enthusiasts, they are comfortable saying a tool is not good enough, and they will actually use the thing daily. That last one sounds obvious and is the most commonly missed. Somebody who does not use it cannot lead it.
What matters much less: prior AI experience, a data science background, or fluency with the vocabulary. Those are learnable in weeks. Twenty years of knowing how your firm actually delivers a project is not.
The person who can say "I tried it on my own project and here is where it failed" moves a skeptical room. Nobody else does.
The mistake I see most
Naming someone the AI lead, adding it to their title, and changing nothing about their utilization target.
This is the single most common way this goes wrong, and it is entirely predictable. The person is now accountable for adoption while still carrying full project responsibility. Project deadlines are hard and adoption deadlines are soft, so adoption loses every week. Six months later the firm concludes there was no appetite for it, when what actually happened is that nobody was given the hours.
If you name someone, take the time out of their utilization explicitly and tell the partner group you did. A day a week is roughly twenty percent, and if that number makes people uncomfortable, that discomfort is the actual conversation. Better to have it at the start than to discover it in a review, which is one of the failure patterns behind why AI pilots fail.
When an outside hire does make sense
There are cases. If you are large enough that this is genuinely a full-time job with a team, if you are building software rather than adopting it, or if you have tried twice internally and stalled both times, an outside hire is reasonable.
Even then I would pair them with a respected internal engineer rather than expecting them to earn credibility on their own. An outsider with a mandate and no relationships will be politely ignored by exactly the people whose behavior needs to change. The decision between building this capability internally and bringing it in is the same trade I work through in build or buy, and the answer is usually a mix.
The honest cost comparison
An outside AI lead in this market is a meaningful salary plus recruiting time plus a ramp of several months learning how your firm delivers work. Against that, one of your existing engineers at twenty percent time is a fraction of the cost, starts on day one with full context, and if it does not work out you have lost far less.
Firms reach for the hire because it feels decisive and because it converts an ambiguous problem into a line item. It also lets everyone else off the hook, which is the part that quietly undermines it. Adoption is a change in how a lot of people work. A title does not do that. A trusted colleague with protected time and the authority to make a call does.
Start there. If the work outgrows one person at twenty percent, you will know, and you will be able to write a job description grounded in something real.
Figuring out who that person should be, and what they should be pointed at first, is part of what our team enablement engagement covers. Start a conversation.
← Back to insights