The first engineering requisition decides what the company will learn next. A role built to polish a demo can make early traction look stronger than it is; a role built around customer evidence can preserve the runway needed to hear why buyers hesitate.
Consider Ama, an illustrative founder in Accra, on the Monday after her seed round landed. Her tea had gone cold beside a laptop full of candidate profiles. A prospect had loved her AI workflow demo on Friday, then asked a question that had stopped the call: “Who checks the answer before my team acts on it?”
Ama had two open documents. One was a requisition for a senior machine-learning engineer to improve the demo before the next investor update. The other was for a product-minded engineer who could sit in customer calls, trace where the workflow broke, and build only after seeing the same problem recur.
The first hire promised a better-looking answer within weeks. The second risked exposing that the product’s real problem sat somewhere less flattering, in onboarding, permissions, or a task customers would not hand to AI at all. If Ama chose badly, the round could fund months of building toward a buyer who never intended to pay.
The title predicts the conversation you will have
“AI engineer” sounds like a clear request. Often it means several conflicting requests have been compressed into one title: improve the model, build integrations, fix the interface, support sales calls, and make the company appear technically serious.
That compression is expensive because the person who joins will take cues from the job. Give them a brief shaped around a demo and they will reasonably work toward a demo. Give them a brief shaped around a customer decision and they will ask different questions before they write code.
Ama’s prospect was not asking for a more impressive model. They were asking who owned the consequence when the model was wrong. A faster prototype would have left that question intact.
This is the difficult part after funding. Money creates an understandable urge to make the product look finished. But a convincing demo can conceal the exact uncertainty the company needs to reduce. The first requisition should name that uncertainty plainly.
For example: “We need to learn whether operations managers will trust AI recommendations when they can see the source and override the result.” That sentence gives a candidate a real job. It also gives the founder a way to decide what belongs in the first build.
Buy a faster learning loop before buying a polished surface
A small team needs an engineer who can turn a customer conversation into a narrow product test. That may be a product engineer, a full-stack engineer comfortable with AI tools, or someone with experience shipping internal workflows. The title matters less than the operating expectation.
The useful early engineer can hear a customer say, “I cannot put this into our process yet,” and ask what “this” means. Is the output unreliable? Is the approval path unclear? Does the customer lack the data needed to start? Are they interested in the demo but unwilling to change how their team works?
Those answers shape a product far more than another round of interface polish.
This does not mean every first hire must be a generalist. Some products genuinely depend on difficult technical work. A founder building a system where accuracy is the core value may need deep machine-learning experience early. The test is still the same: can the founder state the customer risk that technical work will reduce?
A requisition that says “improve our AI” hides the decision. A requisition that says “reduce the review time that prevents a customer from using AI output in a live workflow” gives the work a boundary.
The distinction resembles the tension in AI product demos: What Nia’s real workload taught us about customer trust. Buyers often react to the work around the model, not only the model itself.
Put the hard customer answer in the hiring brief
Before publishing the role, write down three things the hire must help the company learn within the first stretch of work. Keep them tied to actual customer choices.
Ama rewrote her requisition after replaying the Friday call. She wanted someone who could build a small review flow, instrument where people overrode the AI, and join customer sessions without treating them as a distraction from “real” engineering.
That changed the interviews. Instead of asking candidates to describe the largest system they had built, she asked how they would decide whether an AI suggestion deserved to become part of a customer’s daily process. Strong candidates talked about observing work, reducing scope, and creating a path to inspect mistakes. A few candidates immediately proposed expanding the demo.
Neither answer made someone a bad engineer. They were offers to build different companies.
The hiring brief should also state what the person will not own yet. If the first engineer is expected to build a production platform, lead infrastructure decisions, support bespoke sales promises, and discover product-market fit alone, the founder has avoided prioritising. The requisition has become a list of fears.
The first month should end with evidence, not more confidence
Ama chose the second brief. Her new engineer spent the first month close to the customer workflow, with enough room to build and enough restraint to leave unproven requests alone.
The work produced an uncomfortable result: the original AI output was useful, but the review step was where the prospect lost confidence. That was harder to present in a deck than a sharper demo. It was also a product decision they could act on.
By the next customer session, Ama was holding a smaller prototype and a clearer question. The prospect could see the source behind each suggestion, flag a wrong one, and explain why. The room changed. They were no longer praising an AI demo from a distance. They were showing the team where it would fail.
That is a better use of the first engineering hire: make the next customer answer harder to avoid.
Comments
No comments yet.