He Recommended a Friend and Called It Hiring

The Problem Wasn't the Developer

I was on a team call recently with a founder I've been coaching - we'll call him V - and his backend developer. The developer was supposed to join the call an hour earlier to demo his work. He didn't show. No text, no Slack message, no heads up. Just silence.

When he finally joined, his excuse was that he'd been cycling home and got stuck in traffic.

Not the first time. Not the second time either. V had been chasing this guy for weeks - maybe longer. Delayed calls. Missing GitHub commits. Code that hadn't been pushed in over a month. A Slack integration that had been "almost done" for three months. A Zapier connection that looked finished in the dashboard but had never actually been integrated into the product.

Here's what made it worse: the developer - let's call him K - had been recommended by one of V's close friends.

And that is the real problem. Not K's code. Not the missed calls. Not the stale GitHub repo. The real problem is that V hired a friend-of-a-friend and then found himself unable to act on the obvious because the decision had stopped being a business decision the moment he made the hire.

You Didn't Reduce Your Risk. You Just Moved It.

Here's what founders tell themselves when they hire through referrals: I know where this person comes from. There's accountability. It's safer than a cold hire.

It's not safer. It's just a different kind of risk.

When you hire someone off the open market - Upwork, LinkedIn, a job board - and they don't perform, firing them is a business decision. It's uncomfortable, maybe. But it's clean. You make the call, you document the failure, you move on.

When you hire through a friend, you've converted that professional risk into social debt. Now firing the person means potentially damaging the friendship that produced them. Every week you delay the firing is another week you don't have to find out what that costs you socially. The threshold to act doubles. Triples. And in the meantime, your product stalls, your team wastes hours babysitting, and your runway disappears.

V knew K wasn't performing. He said it himself on the call: I feel he's been a bad hire. But then in the next breath, he was arguing for giving K more time to finish the Slack integration, because - and this is the key line - we already paid for it, and we need to get that work back.

That's the sunk cost fallacy fused with social obligation. It's one of the most expensive combinations in business.

What I Saw on That Call

When K finally joined the call, we walked him through his commitments in real time. Here's what the actual status looked like:

• The Slack integration: incomplete. The API was returning errors. He was still working on it - live, during the call, with us watching.
• The Zapier integration: described by K as done, but V's technical lead confirmed it had never been integrated into the product. It existed somewhere in the codebase but had never been wired up end-to-end. The definition of "done" had apparently been loose for months.
• GitHub commits: the last push was over a month old. V's team had no visibility into what K had actually been building. It was a black box. They could only see results - and the results weren't appearing.
• AWS and GitHub access: still not properly transferred. V had been listed as a collaborator, not an owner. If K disappeared tomorrow, V wouldn't have clean control over his own infrastructure.

We fixed most of this on the call itself - in real time, with K screen-sharing, us watching him type, and someone monitoring Slack on the side. The rich text link display issue: fixed. The source citation bug: fixed. The GitHub ownership transfer: done. The pseudo-ping to the OpenAI assistant: done.

Almost everything that had supposedly been pending for weeks got resolved in about two hours when someone was actually sitting on top of the work.

Which tells you everything.

The Real Math on Time

At one point during the call, I walked K through a number that I think about a lot.

V's technical lead - the guy who had actually been managing K - is worth somewhere in the range of $500 to $1,000 an hour when you factor in what his time produces. I'm worth $8,000 to $20,000 an hour. And we'd both been sitting on this call, waiting, for almost an hour before K showed up.

K's excuse was traffic on his bike ride home.

That's not a traffic problem. That's a respect problem. And the reason it had gone on this long - the reason K felt comfortable being late repeatedly, with no warning, with no accountability - is because the social dynamic made it nearly impossible for V to enforce consequences.

K knew, on some level, that V wasn't going to fire him easily. Because V's friend would find out. And V cared about that more than he was willing to admit.

Referral Hires Need a 30-Day Standard. Before the Social Debt Accumulates.

Here's the framework I use, and the one I should have told V before he ever made this hire:

Treat every referral hire to the same 30-day performance standard as a cold hire - before the social debt accumulates and the decision stops being yours to make.

That means: in the first 30 days, you are evaluating them exactly as you would someone you found on a job board. You are not giving them the benefit of the doubt because your friend vouched for them. You are not softening your feedback because you'll see their sponsor at dinner next month. You are running the same checklist:

• Are they committing code every day? (Or whatever the daily output metric is for their role.)
• Are they sending screenshots and Loom updates proactively, without being asked?
• Are they showing up to every call, on time, prepared to demo completed work - not work in progress?
• Are you able to see what they're doing, or is it a black box?

If they're failing these checks in week one or week two, you address it directly. If they're still failing in week three, you exit the relationship. You do not wait for month three. You do not wait until you've paid them for work that hasn't been delivered. You do not wait until the Slack integration is almost done.

Because here's what happens when you wait: the social debt compounds. Every week that passes is another week where firing them feels more like a betrayal. The conversation with your friend gets harder to imagine. The decision that should take ten minutes starts requiring a conference call and a therapist.

The Documentation Problem Is a Hiring Problem

One of the other things we uncovered on this call was that K had never documented anything. No API documentation. No handoff notes. No explanation of how the pieces fit together. The backend was, as V's technical lead put it, a black box - they could only see the results, not the work that produced them.

This is always a red flag, and it's one that referral hires get away with longer than cold hires because founders are slower to demand accountability from people who came through a trusted source.

On a cold hire, if you're two months in and you have no documentation, you ask for it. If they don't produce it, you start looking for a replacement. But on a referral hire, you tell yourself that they're good, they just work differently, it'll sort itself out.

It doesn't sort itself out. It becomes a dependency. And then when you finally need to replace them, you can't - because no one else can walk into the codebase and understand what was built, how it works, or what's left to do.

V's team estimated it would take a new developer six months just to get up to speed. That's the cost of tolerating undocumented work for too long. That's the invisible tax on every week you didn't enforce the standard.

The fix is simple, and it's the same fix for referral and cold hires alike: non-negotiable documentation from day one. Daily GitHub commits. Loom walkthroughs of completed tasks. A shared Notion document tracking what's been built, what's been tested, what's been integrated, and what's pending. Not because you don't trust the developer - because you need the option to act if you have to.

When You Can See It, It's Done. When You Can't, It Isn't.

One of the most useful things V's technical lead said on that call - and I'm going to borrow this line - was this: The backend is not visible. Whatever you're working on, the front end you can see and give feedback. The backend takes time to develop. So how you track that is commits to GitHub.

This is exactly right. And it applies to more than just developers.

If your hire's output is invisible, your accountability system has to be more rigorous, not less. You need daily commits. You need daily screenshots. You need a shared document where every task has a clear definition of done - not "I finished the Zapier integration" but "the Zapier integration is live, tested, and feeding leads into the following platforms: X, Y, Z."

Because "done" is a word that gets stretched when there's no one watching. K's version of done on the Zapier integration was apparently writing the code. V's version of done was having it integrated into the product and confirmed working. Those are not the same thing. And the gap between them cost weeks of runway.

The moment I see a contractor define "done" loosely, I tighten the definition in writing. I send a Slack message or an email: Just to confirm - by "done" we mean X. Deployed. Tested. Visible in the dashboard. Let me know if that's not aligned. Takes thirty seconds. Saves weeks.

The Conversation You're Avoiding Is the One You Need to Have

After K left the call, V's technical lead made a comment that stuck with me. He said something like: V should have onboarded someone to manage this properly from the start. A month or two earlier, or maybe from the very beginning.

He was right. But the reason V didn't is the same reason founders never do: it feels premature when things are going okay, and by the time things aren't going okay, the social dynamics have locked you in.

So here's what I want you to do differently.

The next time a friend recommends someone for a hire, say this: I appreciate the referral. I'm going to run them through the same 30-day evaluation I use for everyone. If they clear it, great. If they don't, I'll let you know - and I want you to know upfront that the decision will be mine to make either way.

Say it before you make the hire. Not after. Because after the hire, the social contract is already written. You're renegotiating from a position of debt. Before the hire, you're setting terms. That's the only time the terms are actually yours to set.

This protects your friendship, by the way. Because if you don't have this conversation upfront, and the hire fails, and you spend months avoiding the obvious, the friendship gets damaged anyway - just in a slower and more expensive way.

What Good Hiring Actually Looks Like

The best hire on V's team during this period wasn't K. It was the technical lead - the guy who had been doing the actual work of monitoring, documenting, and holding things together. He was the one on the call who could tell me, in real time, what the GitHub commits showed, what the Slack API error was, what tasks were genuinely complete versus just technically started.

That kind of visibility is what you're hiring for. Not someone who's good at coding in theory, or someone your friend can vouch for at dinner. Someone whose work is visible, documented, and verifiable every single day.

If you're building a team right now and you need to source developers or contractors outside of your personal network, I'd start with a proper B2B database to find relevant communities and platforms, use job boards like Upwork to run structured tests with multiple candidates at once, and verify output before you commit. Hire three people, give them all the same small test task, pay them all for it, and see who delivers clean work on time. That process costs you maybe a few hundred dollars and a week. It saves you the months V lost.

If your business relies on outbound and you need to build lead lists or scrape contact data as part of your operation, ScraperCity is worth looking at - it's what I use for my own prospecting. But the point is: whatever your hiring need, run it through a process. Not a referral chain. A process.

For a deeper look at building the systems that make outbound hiring work alongside outbound sales, grab the 7-Figure Agency Blueprint. The staffing section covers how I think about building teams at scale without getting trapped in the dependency loops that killed V's timeline.

The Hard Truth

V is a smart guy. He's building something real. The product - a chatbot platform with AI-powered sales conversations - has genuine potential. The technical problems we fixed on that call were fixable. The real problem was the three months of delay that accumulated because the social dynamics of a referral hire had made it nearly impossible to act.

That's not a technical problem. That's a founder problem. And it's one of the most common problems I see, because referral hiring feels like the responsible choice. It feels like you're lowering risk. It feels like you know what you're getting.

You don't. You're just moving the risk somewhere you can't see it - into your relationships, into your social calendar, into the friendship you'd rather not damage. And when the hire fails, and they often do, you find out that the risk was there the whole time. You just couldn't touch it.

Run the process. Set the 30-day standard. Have the upfront conversation. Make the decision yours to make before the social debt makes it someone else's.

Everything else is just a nice way of saying you hired a friend and called it a strategy.

If you want help building the outbound systems and team structures that actually scale - without getting trapped by bad hires or referral loops - Galadon Gold is where I work through this stuff live with founders every week. It's not theory. It's the exact call you just read about, applied to your business.