Founders ask me this question in two ways. Some ask whether they can justify the cost yet. Others ask whether they have a problem they cannot see.
The second group is usually closer to the real question, and AI has made it harder to answer. A company can now produce a great deal of working software with very few people, which removes the symptom founders used to rely on. Things are not visibly slow. The backlog is moving. The demo is good.
Thresholds are the wrong instrument
The advice in circulation tends to attach a number to the answer. Hire one once you pass a certain headcount. Once you raise a particular round. Once revenue clears some line.
I would not decide this way, because the number describes the company's size rather than its exposure. I have seen a team of five where nobody could say which of their dependencies would fail under load, and a team of forty running perfectly well on a founder's instincts and a good lead engineer.
Size tells you how much technology work is happening. It does not tell you how many consequential decisions are going unmade.
AI has broken that link further. Team size no longer predicts output, and output no longer predicts progress. A small team can now generate the code volume of a much larger one, which means the old signal — things are slowing down, we must need more senior help — arrives later and sometimes never arrives at all.
More engineers is the cheapest wrong answer
When writing software was the expensive part, adding capacity was a serious decision, and making it forced a conversation about priorities. It is not a serious decision any more. Capacity is cheap, whether it arrives as people or as agents, which makes it the obvious response to almost any pressure.
The trouble is that the bottleneck moved. What is scarce in an AI-native company is not the ability to build things. It is deciding what deserves to exist, deciding where a machine may act without a person, and being able to tell whether any of it is working.
None of those is a capacity problem, and none of them improves when you add capacity. A company that answers a judgment problem with more delivery gets more of what it already had, faster.
Six signals that the moment has arrived
None of these is fatal on its own. Two together usually mean the conversation is overdue.
Nobody can say whether the AI is working. The clearest signal, and the newest. If the honest answer to "how do you know it is good?" is a demonstration, a customer anecdote or a benchmark from the model provider, the company has no instrument for its own core product. Everything downstream — pricing, roadmap, the claim in the next deck — is being decided on impressions.
The founder is still the default CTO, and it is costing the company the work only they can do. This is the most common and the most expensive. A technical founder is often perfectly capable of leading the technology function, and AI has made them faster at it, which hides the cost for longer. The question is still whether that is the best use of the one person who can raise the next round, close the strategic customer and decide what the company is for.
A strong engineering team has no executive technology leadership above it. Capable engineers with no senior technology voice will optimise for what they can see. They will build well and they will build the wrong things, because nobody is connecting their work to where the business is going. With AI in their hands they will do it considerably faster, and the quiet compounding gets louder.
Velocity is exposing gaps that slowness used to hide. Not outages — outages are obvious. The softer signals: generated code arriving faster than anyone can review it, estimates drifting, the same component appearing in every incident, a release process everyone works around, new joiners taking a quarter to understand a system nobody fully wrote.
The board is asking questions the company cannot answer well. If technology reporting is a status update, or a demonstration, rather than a view of performance, cost and risk, the board is making investment decisions on partial information. The AI questions are the sharp ones now: what does it actually do, what does it cost per customer, and what happens if the model provider changes the terms.
Something large is coming. Fundraising, market expansion, a platform change, a first enterprise customer with a security questionnaire. Each audits your technology function whether you are ready or not, and diligence now tests the AI claim hardest of all. The time to find the gaps is before someone else does.
When it is genuinely too early
I turn down more of these conversations than founders expect, because bringing in senior technology leadership at the wrong moment wastes money and, worse, slows a team down.
It is too early when you have not found the shape of the product yet. Before that point, the right technology strategy is usually to build the cheapest thing that answers the question in front of you, and senior architectural judgment applied to a product that is about to change completely is judgment spent on nothing.
It is too early when the founder is technical, has the time, and is enjoying it. That arrangement works, and it works for longer than most advice admits. Replace it when it stops working, not when a blog post says you should.
It is too early when the real problem is capacity. Leadership does not substitute for delivery. This reason has weakened, though: capacity is cheaper than it used to be, so a company reaching for it repeatedly should check whether the thing it keeps running out of is really hands.
And it is the wrong arrangement entirely if the situation is a crisis rather than a gap. A company whose delivery has broken, whose platform is unstable, or whose technology leadership has just left needs someone holding the role, not advising it.
What the first ninety days should look like
If you do bring someone in, it is worth knowing what good looks like, so you can tell early whether it is working.
The first weeks should be spent establishing the truth rather than proposing solutions. Anyone arriving with a strategy in month one is selling you a strategy they had before they met you. What they should be doing is reading the code, the incidents, the roadmap and the contracts, and talking to the engineers who have stopped expecting anyone to ask.
Where the product depends on a model, one more thing belongs in that first month: an evaluation baseline, taken before anything is improved. Without it, every later claim of progress is measured against itself.
By the end of the first month, you should have an honest account of where you actually stand, including the parts you suspected and the parts you did not.
By the end of the second, that should have narrowed to the few decisions that will materially change the outcome. Not a list of everything wrong. A short list of what matters.
By the third, those decisions should be turning into sequenced work with owners and measures, and the team should be able to describe the plan without help.
If month three still looks like month one, the arrangement is not working, and you should say so.
The question behind the question
Almost every founder who asks me this is really asking something else: whether the technology decisions being made right now are good ones, and whether they would know if they were not.
That is a reasonable thing to be uncertain about, and it has become harder to resolve alone. The role itself has changed. What a technology leader is accountable for looks different once intelligence is part of the product, the platform and the workforce — and hiring against the old description is its own kind of delay.