Take the obvious discount before you read any of this. I am an outside firm with hours to sell.
I would still rather tell a company to hire than take on an engagement that should have been a job advert. That kind of work ends badly and everybody remembers who sold it to them.
When hiring is the right answer
Continuous work is the first condition. If you can name the second and third project and the fourth is obvious, an employee is cheaper than any firm and it is not close. Consultancies are priced for temporary work, and paying that rate permanently is something organisations do by accident, one extension at a time.
The second is knowledge that only exists inside your business. If it takes a year to understand how your operation really works, you do not want to teach that year to a new supplier every time. Where the domain is deep and awkward, an average engineer who has been in the building two years will beat a very good one who arrived in March.
The third is retention, and it is the one people wave through. Is there interesting work after the first project, or does it become maintenance by month seven. Is there somebody who can tell whether they are doing well. Can you match what they will be offered in Dubai in eighteen months, because they will be offered it. If the answer to any of those is no, you are paying to train somebody for a competitor.
When it goes wrong
One project is the clearest case against. If there is one thing to build and no obvious second, hiring for it is slow and expensive. Recruiting takes three to six months, the person arrives without having done it before, and when it is finished they have nothing to do.
Unclear scope is the next. A capable person hired into a vague brief will produce a year of work nobody asked for, and it will not be their fault. Somebody has to decide what is worth building, and if that decision is the thing you are missing, extra hands make it worse rather than better.
Then there is nobody senior to manage them, which is the failure I meet most often. Two good people are hired, put under a manager who has never shipped software, and given no way to tell whether they are on track. Nothing reaches production, because reaching production is mostly the unglamorous part: access, a security review, monitoring, and somebody in operations agreeing to be responsible for it at two in the morning.
The related trap is the single hire. One person cannot cover the strategy, the building, the security and the running of it, and they take leave. A team of one is a plan with a single point of failure written in.
The hire you cannot make yet
You cannot interview well for a skill nobody in the building has, and that is the trap in the first hire. The candidate who talks fluently about AI is not necessarily the one who has put a system in front of real users, and across a table the two look identical.
Two things help. Get somebody independent, who is not selling you a team, into the technical part of the interview. And set a small piece of real work on your own data instead of asking questions, then look at how the candidate explains the parts that did not work. The explanation tells you more than the result.
The middle path, which is how we prefer to work
Bring somebody in to build the first system, with the training and the handover written into the contract on day one rather than added in the last month. Hire your own person in parallel, early enough that they are in the room while it is built rather than inheriting it as a finished object nobody explains. When it goes live the outside team drops back to a support window and your person runs it.
You get the first one built by people who have done it before, and an employee who learned on a real system instead of on a course. Whether it worked is settled by one question: can your own person change it, retrain it and fix it without ringing us.
I am obviously in favour of this, so weigh it accordingly. What I would say for it is that it is the one arrangement where the outside firm is paid to make itself unnecessary, and you can check that in the contract before signing.
Which case are you in
Write down the work you expect over the next two years rather than the project in front of you. Then name the person who would manage the hires and ask honestly whether they could tell good work from bad. The second answer settles it more often than the first.
Send me those two things and I will tell you which case I think you are in, including when the answer is a job advert rather than a contract with us.
Working through this on a live programme?
A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.