Our Developer Referral Program Produced Almost Nothing for 9 Months — the 7 Steps That Fixed It

Almost every Singapore engineering team I work with has a referral program, and most of them are dormant. The policy exists, the bonus is on the intranet, and the number of referrals per quarter rounds to zero. The instinctive fix is to raise the bonus and send another all-hands reminder. That fix does not work, and the reason it does not work tells you exactly how to build a program that does. Here is the method, step by step.

Why Your Program Is Silent (It Is One of Three Things)

Dormant referral programs fail for three distinct reasons, and they need different fixes. Diagnosing which one you have is step one, because applying the wrong remedy is why most relaunches fail twice.

Cause one: they do not know who to refer. “Do you know a good backend engineer?” is a genuinely hard question to answer on the spot. It requires searching an unindexed memory for people who are both suitable and plausibly available. Most people draw a blank, feel mildly unhelpful, and move on.

Cause two: the social cost is too high. Referring a friend means staking a relationship on a process the referrer does not control. If the friend is treated badly, ghosted, or rejected in a way that feels arbitrary, the referrer absorbs the damage. Against that risk, a bonus is a weak incentive.

Cause three: they referred once and nothing came back. This is the most common and the most self-inflicted. Someone gave a name, the candidate vanished into the process, and the referrer eventually learned the outcome from their friend rather than from the company. Participation ends there, permanently.

Step 1 — Diagnose Before You Relaunch

Ask five engineers individually, not in a group and not in a survey: “Have you ever referred someone here? What happened?” The answers map cleanly onto the three causes. If they have never referred, you have cause one or two. If they referred and trail off when describing the outcome, you have cause three.

Do not skip this. A company with cause three that relaunches with a bigger bonus is asking people who were already let down to take the same risk again for slightly more money. That relaunch fails and, worse, it burns the credibility you need for the next attempt.

Step 2 — Ask for Names, Not Referrals

This is the single highest-leverage change available and it costs nothing. Replace the open-ended request with a specific one.

Build a list of eight to twelve companies in Singapore whose engineers would plausibly fit the role — similar stack, similar scale, similar problem domain. Put the list in front of your team and ask: “Who did you work with at any of these that you rated?”

The cognitive difference is enormous. The first question asks for open recall from an unstructured memory. The second asks for recognition against a prompt, which human memory is far better at. In practice we see a several-fold increase in names produced from the same group of people in the same meeting, purely from the reframing.

A useful second prompt: “Who is the best engineer you have ever worked with who is not at a company on this list?” People almost always have an immediate answer to that one, and it is frequently someone they would never have thought to raise.

Step 3 — Remove the Social Risk Before You Raise the Bonus

Make three commitments, in writing, to everyone who refers:

• A guaranteed first response within five working days, to both the referrer and the candidate. Not a decision — a response.
• Rejections are delivered by the recruiter, never left to the referrer. The referrer should never be the one to tell their friend it did not work out.
• An explicit rule that a rejected referral carries no reflection on the referrer. Say it out loud, because people assume the opposite by default.

These cost nothing and they address the actual constraint. An engineer with a strong network is usually well paid; a few hundred or a few thousand dollars does not change their life, but a damaged friendship is felt immediately and personally.

Step 4 — Pay for the Behaviour You Want Repeated

Most programs pay the entire bonus on a completed hire, usually after a probation period. That structure rewards an outcome the referrer cannot control: whether the candidate was interested, interviewed well, accepted the offer and stayed.

Split it. Pay a modest amount for a quality introduction — defined as a candidate who takes a conversation and is judged plausible for the role — and the larger portion on the hire. The first payment is small enough not to attract gaming, especially with a plausibility gate, and it converts referring from a lottery ticket into a reliably rewarded behaviour.

On the headline figure: benchmark it against comparable local companies and then stop optimising it. If you are also weighing what agency fees cost by comparison, our guide to negotiating recruitment agency fees for developer hires puts the numbers side by side.

Step 5 — Close the Loop Within Five Working Days, Every Time

If you implement only one step from this article, implement this one. The strongest predictor of whether an engineer refers a second time is whether they were told what happened to the first one.

The mechanics are mundane: a named owner for every referral, a status update to the referrer at every stage change, and an explicit close-out message even — especially — when the answer is no. The close-out should say what stage the candidate reached and thank them specifically. It does not need to disclose confidential assessment detail, and it should not.

What makes this hard is not difficulty but priority. Referral follow-up is nobody’s urgent task, so it slips, and each slip silently removes a future referrer. Put it on a named person with a service-level commitment, the same way you would treat a candidate at final stage.

Step 6 — Run Sprints, Not a Standing Program

A permanently open referral program becomes part of the furniture. Nobody acts on a policy that has been true for two years.

Run two-week referral sprints tied to specific open roles instead. Announce the role, share the target-company list from step two, run one short session where people scan the list together, and close the sprint with a public summary of what came in and what happened to it. The time limit creates the urgency that a standing policy structurally cannot, and the closing summary is itself the loop-closing mechanism from step five.

Sprints also make the program measurable. You can attribute names, conversations and hires to a defined two-week window and a defined role, which is impossible with an always-on policy where referrals arrive at random.

Step 7 — Measure Network Narrowing and Correct for It

Here is the uncomfortable part, and the reason a successful referral program needs a counterweight. People refer from their own networks, and networks are shaped by where someone studied, which companies they worked at and which communities they belong to. A referral program that works pulls repeatedly from a small number of sources.

In Singapore this compounds quickly, because the pool of companies your engineers are likely to have worked at is relatively concentrated. Left unmeasured, a high-performing referral channel will gradually narrow your team’s composition — not through anyone’s intent, but as an arithmetic consequence of how networks work.

So instrument it. Track which companies, schools and communities your referrals originate from, and review the distribution quarterly. When concentration becomes visible, do not shut the referral channel down — it remains one of the highest-quality sources you have. Balance it deliberately with channels that reach different networks. A structured, skills-first process is the most reliable counterweight, and our skills-based hiring pipeline guide sets out how to run one. Teams applying the same correction in a different labour market have documented their version in building a developer referral program in Dubai.

Three Mistakes to Avoid

Letting referrals skip the technical assessment. Skip the recruiter screen — a trusted referral already establishes what that call is for. Never skip the evaluation. Waiving it costs you your only calibrated signal and creates a visible two-tier process that damages trust with everyone who arrived another way.

Announcing the program to the whole company at once. Broad announcements produce volume without fit, and the resulting triage burden is what causes the follow-up to slip. Start with the engineering team closest to the role.

Treating a referral as a completed search. Referrals are a channel, not a strategy. They are excellent at surfacing people who are not looking and useless at reaching networks your team does not belong to. Run them alongside your other sourcing, not instead of it — our guide to sourcing developers on GitHub covers the channel that reaches the people referrals systematically miss.

FAQ — Developer Referral Programs in Singapore