Hire the engineer after you have evidence that engineering capacity is the constraint. When ten customer accounts go quiet, the urgent job is to learn why before adding payroll.
At 8:40 on Monday morning, I had an offer letter open in one tab and the account list in another.
The letter was nearly ready. The candidate had the kind of profile that makes a founder feel temporarily less exposed: product experience, enough range to work across a small codebase, and the ability to take some decisions without turning each one into a meeting. I could picture the backlog moving again.
Then I counted the accounts that had gone quiet.
Ten customers had started with enough intent to get through setup. None had given us a clean reason to believe that another engineer would bring them back. There were no repeated support requests waiting for a faster fix. No queue of committed buyers blocked by a missing feature. No pattern that said, “You are losing demand because the product team cannot keep up.”
There was only silence.
I deleted the draft.
The constraint was customer learning
A technical hire can feel like progress because the cost is visible and the work is legible. You can name the features that will ship. You can turn the plan into a roadmap and tell yourself the delay is temporary.
Quiet accounts create a more awkward problem. They leave too much room for a founder to supply their own explanation.
Maybe onboarding was unclear. Maybe the first useful outcome arrived too late. Maybe the customer had a real need but no budget. Maybe they liked the demo and had no reason to return. Maybe the person who signed up was never the person who could approve payment.
Those are different problems. More engineering only solves some of them.
Before I made the hire, I needed to treat the ten accounts as the work. I wrote down who had reached what point, what they had been trying to do, and the last moment each account had shown intent. Then I could ask a narrower question: what would have to be true for this engineer to pay for themselves?
The answer could not be “we need to move faster.” It had to be something closer to: committed customers are waiting for a capability we can identify, and we have enough confidence that shipping it will change use or revenue.
Intel’s harder decision came before the turnaround
In 1985, Intel was under pressure in its memory-chip business as Japanese manufacturers gained ground. Andy Grove and Gordon Moore were deciding what Intel should do while the company’s identity was tied to memory.
Grove recounts the moment in Only the Paranoid Survive. He asked Moore to imagine that the board had replaced them and brought in new management. What would the new team do? Moore’s answer was that they would get Intel out of memories.
Intel did exit the memory business and put its focus behind microprocessors. The outcome is familiar now, which makes the decision sound inevitable. It was not inevitable from inside the company that had built its name on memory.
The useful part of that story is the question, not the scale. Grove and Moore were forced to separate the company they had been from the constraint they actually faced.
A founder with a nearly signed engineering offer has a smaller version of the same problem. The hire may fit the company you imagined building. The quiet accounts may be telling you what company you actually have today.
A hire needs a causal case
I did not need certainty before hiring. Early-stage teams rarely get that luxury. I needed a causal case strong enough to justify adding a fixed monthly commitment.
That meant looking for one of three signals.
First, customers repeatedly ask for the same missing capability, and that capability sits directly between them and a paid outcome.
Second, customers are already using the product enough that reliability, speed, or integrations are holding back expansion.
Third, the founder’s own time has become the bottleneck in a demand loop that already works: selling, onboarding, shipping a verified request, and seeing customers return.
If the evidence points elsewhere, the better short-term investment may be conversations, a narrower onboarding flow, manual service, or a small experiment that tests why accounts disappear. That can feel slower than recruiting. It often produces the information a new engineer would otherwise spend months building around.
This is close to the decision in “AI Model Costs: Why Kojo Tested Routing Before Making a Full-Time Hire”. A full-time cost should follow a tested constraint, not stand in for one.
Keep the offer honest
Deleting the letter was not a verdict on the candidate. It was a refusal to ask them to solve a problem I had not defined.
The offer can return when the customer evidence does. Until then, I would rather know which account went quiet after which moment than carry an expensive assumption into the next quarter.
Intel’s management did not save the memory business by hiring harder into it. They changed direction after naming the constraint plainly. Ten quiet accounts do not require a grand pivot. They do require the same discipline: pause, look at the evidence, and make the next commitment fit the problem in front of you.
Comments
No comments yet.