By Courtney Mcgowan, Director at Tides Digital

I think one of the biggest mistakes businesses are making with AI hiring is focusing too heavily on the technology and not enough on what they actually need someone to achieve.

When I speak to hiring managers, the brief often starts with a list of technical requirements. Python, LLMs, cloud infrastructure, model deployment, agent frameworks. The list is understandable. AI is moving quickly, the tools are changing constantly, and businesses want people who can keep up.

The problem is that a strong technical skill set doesn't automatically mean someone can take an AI project from an interesting idea to something that works reliably inside a business.

That gap is becoming increasingly important, and I don't think enough companies are considering it when they hire.

The difficult part often starts after the prototype

Imagine a business building an AI tool to automate part of its customer support operation. The team has selected a model, connected the relevant data and built something that performs well in testing. The initial results are promising, and everyone is keen to get it into production.

Then the harder questions start. What happens when the model gets something wrong? How does it handle an unusual request? Who decides which actions it can take without human approval? How will the business measure whether it is actually improving the customer experience?

These questions involve engineering, product, operations, security and the people who understand the business problem in the first place. They require technical knowledge, but they also require judgement, communication and an ability to work through ambiguity.

I've become increasingly interested in how businesses account for those capabilities when they hire. A company can have excellent engineers and still struggle to get an AI product into production if the team lacks the experience to connect the technical work with the wider business objective.

In my view, that is one of the more important hiring challenges emerging as AI adoption matures.

The job description might be part of the problem

I regularly see how easy it is for a hiring brief to become a long list of technologies. It can feel like the safest way to recruit in a market moving as quickly as AI. If a candidate has experience with the right frameworks, models and infrastructure, surely they have the right background.

Those skills matter, of course. But the list tells you relatively little about how someone approaches a difficult decision, deals with competing priorities or works with stakeholders who have different ideas about what a successful outcome looks like.

Two candidates can have almost identical technical backgrounds and perform very differently in the same role. One might be excellent at building a solution when the requirements are clear. The other might be equally strong technically, but also know how to challenge an unclear brief, identify a risk early and help a product team decide what is worth building.

Depending on the business and the role, that second set of capabilities can make a significant difference to delivery.

I don't believe every AI engineer needs to be a product manager or an expert communicator. There will always be roles where deep technical specialism is the priority. The important thing is understanding what the individual will be responsible for and assessing them against the reality of the job, rather than an idealised list of requirements.

AI is changing the value of experience

As AI coding tools become more capable, I think we need to be more thoughtful about what experience actually means.

A candidate's ability to write code remains valuable, particularly when working on complex systems. But if AI tools can accelerate parts of implementation, the ability to understand the problem, make sound architectural decisions, evaluate generated work and take ownership of the result becomes increasingly relevant.

For me, this makes practical experience more important, not less. I want to understand what a candidate has actually delivered, what went wrong along the way and how they responded. I want to know where they used AI, how they checked the output and which decisions they made themselves.

Those conversations tell you more than asking someone to list the tools they have used. They also help distinguish between someone who has experimented with AI and someone who understands how to use it responsibly in a real engineering environment.

The same applies to senior hires. A Head of Engineering or AI lead needs to understand the technology, but they also need to make decisions about priorities, risk, team structure and investment. Technical credibility is essential. So is the ability to bring people together around a clear direction.

Before opening another vacancy, look at the team you already have

One piece of advice I'd give any CTO or hiring manager is to spend time understanding where delivery is actually getting stuck before deciding who to recruit.

If your team can build impressive prototypes but struggles to deploy them, you may need stronger production engineering or infrastructure capability. If projects stall because nobody can agree on requirements, another specialist engineer might not solve the problem. If AI systems are reaching production but the business is uncertain about reliability, evaluation and governance experience could be more valuable than another person focused on model development.

These are different problems, and they need different hiring decisions.

I would also encourage hiring managers to make interviews more closely reflect the work people will do. Discuss a real project. Explore a technical trade-off. Ask how a candidate would handle an unclear requirement or explain a difficult decision to a non-technical stakeholder. Look at the way they reason through the problem, not only whether they arrive at the expected answer.

This gives both sides a better understanding of the role and makes it easier to assess whether the candidate's experience matches what the team needs.

My view: hire for the outcome, not the technology list

I expect technical requirements to keep changing as AI develops. New tools will emerge, existing workflows will evolve and businesses will continue to experiment with different ways of building and deploying systems.

That makes it difficult to predict precisely which technical skills will be most valuable several years from now. What businesses can do is become much clearer about the outcomes they need their teams to deliver and the capabilities required to achieve them.

For me, that starts with better conversations between hiring managers and their recruitment partners. What is the business trying to build? Where is progress slowing down? What does this person need to own? What expertise already exists in the team, and where are the genuine gaps?

Those questions lead to better briefs, more focused interviews and a stronger chance of hiring someone who makes a lasting difference.

At Tides, we work with businesses hiring across AI, data and engineering, and this is an area I think deserves much more attention. The strongest hiring decisions come from understanding the work behind the vacancy and the impact the person needs to have.

If you're building an AI team, I'd start with one question: what do you need this hire to make possible that your team cannot do today?

The answer should shape everything that follows.