Alfred AnyanInsights
← All insights

Should I Hire a Senior Engineer or Spend Six Months Proving Demand?

A young entrepreneur gives a presentation on startup strategies indoors with a flip chart.

Photo by RDNE Stock project on Pexels

A senior engineer should earn the hire by removing a constraint that customer discovery has already exposed. If the product problem is still unclear, six months of runway usually buys better evidence than six months of code.

In 1985, Intel’s memory business was losing ground to Japanese manufacturers. The company had been built around memory chips, and leaving that market meant giving up part of its identity. Staying meant continuing to direct scarce people and capital toward a business whose economics had turned against it.

Andrew Grove later described the decision in Only the Paranoid Survive. He asked Intel co-founder Gordon Moore what new leaders would do if the board replaced them. Moore said they would get out of memory. Grove’s response was simple: why not walk out, come back in, and do it themselves?

The question cut through years of attachment. Intel shifted its focus toward microprocessors.

Friday’s decision is about evidence

The Johannesburg founder has reached a smaller version of Grove’s question.

There is enough cash for one senior engineer or six more months of customer discovery. Choosing the engineer creates visible progress: a stronger architecture, faster releases, fewer technical compromises. Choosing discovery produces less impressive artefacts. It buys interviews, rejected proposals, revised workflows, and a clearer account of who will pay.

Both paths can look responsible. Only one matches the company’s current constraint.

The useful question is not whether a senior engineer could improve the product. A good engineer almost certainly could. The question is whether better engineering would change the reason customers have not committed.

If prospects already want the product but cannot rely on it, the hire may protect revenue. If prospects keep changing the subject during demos, asking for a different workflow, or agreeing politely without discussing procurement, the company has a demand problem. More code can make that problem expensive enough to defend.

I would write down the last ten customer conversations before approving the offer. For each one, I would record the decision the customer was trying to make, what stopped them from buying, and whether an engineering change would remove that obstacle. General enthusiasm does not count.

A hire changes the company’s questions

A senior hire adds more than salary. The founder must recruit, onboard, set technical direction, review decisions, and create enough work to justify the role. Once the engineer starts, cancelling a weak feature feels harder because another person has invested time in it.

That is commitment and consistency at work. We prefer to continue along a path after making a visible commitment, even when the evidence changes. The hire can quietly turn “Should we build this?” into “How should we build this?”

I have seen the same pressure around AI products. A working model makes a roadmap feel concrete, while uncertain demand feels like a temporary marketing issue. Then the team spends months improving retrieval, latency, permissions, and evaluation before learning that the buyer needed a narrower workflow.

The decision resembles the payroll tension in Should I Run Friday Payroll or Hire an AI Engineer Before Testing Demand?. The technical opportunity may be real. Runway still sets the order in which the company can pursue it.

Six months of discovery also needs discipline. It cannot mean another half-year of broad conversations ending with “keep me posted.” The founder needs a fixed learning agenda: one buyer type, one painful workflow, a price conversation, and a commitment stronger than praise. Paid pilots, access to operational data, procurement steps, or repeated use provide better signals than feature requests.

Set a hiring threshold before the offer

I would define the evidence that must exist before hiring.

Three conditions would be enough to start:

  • Several prospects describe the same costly problem without being led toward it.
  • At least one customer has made a meaningful commitment, such as paying, beginning procurement, or providing the data required for a pilot.
  • The current team can name the technical constraint blocking delivery and explain why a senior hire is the right way to remove it.

These conditions do not guarantee success. They prevent the company from using recruitment to avoid an uncomfortable market answer.

There is also a reversible middle path. The founder can contract for a narrow technical task, reduce the product to the smallest testable workflow, or ask an experienced engineer to review the architecture before opening a permanent role. The point is to purchase the missing evidence without committing six months of runway at once.

This is the same principle behind AI Startup Runway Planning: Why Kabelo Kept Customer Insight Over Compute. Compute, engineering time, and runway become valuable in different sequences. Spending them in the wrong order can leave a capable team with a product nobody has chosen.

Make the decision on Monday’s evidence

Intel’s choice worked because Grove and Moore stopped asking how to preserve the business Intel had been. They asked what decision the available evidence required.

The Johannesburg founder can do the same on Friday. Remove the candidate’s résumé from the table for an hour. Ignore the relief of finally having someone senior to own the code. Read the customer record.

If those conversations point to a specific technical barrier between demand and payment, make the hire and give the engineer that constraint. If the conversations still disagree about the buyer, problem, and urgency, protect the six months.

On Monday, schedule the next customer conversation before reopening the job description.

Comments

No comments yet.