"He Is Very Responsible"

I was on a coaching call a few weeks ago. Three people on the line - me, a founder I'll call V, and his business partner who was calling in from Bangalore, about to move back to Mumbai.

We were supposed to be talking about their developer. The developer had gone quiet. He wasn't pushing code. He wasn't showing up to calls. He had exposed production API keys in a public GitHub repo - database URL, passwords, everything. The team had booked nine meetings in three days with real companies, 100+ employees, ready to commit at serious budget levels. The product worked well enough to sell. But the software wasn't ready because the guy who was supposed to finish it had disappeared.

I said something like: He's working for you. He needs to be.

And V said - and I want you to hear this exactly - "He is very responsible."

That's when I knew the real problem on this call had nothing to do with the developer.

That Sentence Is a Eulogy

I've heard that sentence - or a version of it - probably hundreds of times on coaching calls. The words change but the structure is identical:

• "She's going through a lot right now."
• "He just needs a little more time."
• "To be fair, he's always delivered before."
• "He is very responsible."

What all of these have in common is this: the founder is defending the person's character in response to a failure of output. And those are two completely different conversations.

Nobody asked whether the developer was a good person. Nobody asked about his track record, his values, his intentions. We asked: where is the code? Why haven't the bugs been fixed? Why is he not on this call right now?

When someone responds to an output question with a character answer, they're not managing anymore. They're grieving. They've already processed the loss emotionally and they're trying to reconcile it. The relationship, at some level they already understand, is over. But they haven't let themselves say it out loud yet.

So they say he is very responsible instead.

What Was Happening on This Call

Let me give you the full picture, because the specifics matter.

The developer had been given changes to push. Simple changes. Things that should have taken 112 hours total, stretched across weeks. The team had moved away from a structured daily schedule - there used to be a set time every day, and he always showed up. Once that structure disappeared, so did he.

His GitHub commits had stopped. One of the repos had been made public, exposing live credentials. When the team tried to reach him: no response. They were chasing him down across time zones with no answer.

And meanwhile, the product was actively being sold. Nine meetings in three days. Real buyers. Real budgets. The gap between "we can sell this" and "the software is ready" was the developer. And the developer was nowhere.

V and his partner weren't wrong to be frustrated. They weren't even wrong about the developer's character - for all I know, the guy is a responsible person in other contexts. That's not the point. The point is that on this project, at this moment, the behavior wasn't matching the label. And V was holding onto the label instead of addressing the behavior.

That's the trap.

Liking Someone Is Not a Management Strategy

First-time founders almost always confuse these two things: liking someone and being accountable to someone.

They're not the same. You can like someone and still let them go. You can respect someone's past work and still hold them to a deadline. You can believe someone is responsible and still say: this situation is not working, and I need it to change now.

But when you're early in building something and you've gone through the pain of finding a developer, onboarding them, explaining the vision, watching them build pieces of it - there's a relationship there. It feels personal. And when it starts to break down, it triggers something that looks a lot like grief: denial, bargaining, rationalizing.

He is very responsible is bargaining. It's the founder saying: I'm not ready to accept that this is over, so I'm going to invoke his character as evidence that the behavior will change.

It won't. Not without a direct conversation. Not without clear expectations and consequences. And definitely not if the founder is still in the stage of defending the person instead of confronting the situation.

The Structure Problem Nobody Mentioned

There was something interesting buried in this conversation that almost got lost. One of the guys on the call said it almost as an aside: "Before, we had a set time every day, and he always showed up."

That matters. A lot.

When there was structure - a daily standup, a fixed time, a rhythm - the developer showed up. He was, presumably, responsible. Then the structure went away. They moved to unstructured calls. And suddenly the guy who always showed up... stopped showing up.

This is not a character problem. This is a systems problem.

I'm not saying that fixes everything, or that the developer is blameless. When your credentials get pushed to a public repo and you go silent while your team chases you down for days, that's a serious breach of trust regardless of the circumstances. But if you're a founder and you're reading this, pay attention to that detail: the structure existed, it worked, and then someone decided to remove it.

The lesson isn't "your developer is bad." The lesson is: people perform at the level the system demands. Remove the daily accountability and you've made it easy for someone to drift. That's on you as much as it's on them.

Fix the system first. Evaluate the person second. In that order.

What I Said on the Call

I didn't spend a lot of time analyzing V's emotional relationship with his developer. That's not how these calls go. When I said he's working for you, he needs to be, I meant it practically: responsible is the baseline requirement of employment, not a distinguishing virtue. You don't get credit for being responsible. Responsible is the floor.

What I pushed toward was: figure out what you have. Can you get hold of him? Get on the call. If not - and this is what it came down to - make sure you have the code. Make sure everything is backed up and accessible. Make sure you own what's been built so far. And then move on to finding someone who can fill the gap.

V and his partner already had a few developer candidates lined up. They'd been doing interviews. The instinct was right. Where they were slowing themselves down was emotionally - holding on to the label of "responsible" as if saying it enough times would make the situation change.

My job on calls like that is to get the founder to see that they've already made the decision. They just haven't said it out loud. When you're out there interviewing replacement candidates while simultaneously saying your current developer is "very responsible" - you already know. You've known for a while. The interview process is your subconscious protecting the business while your conscious mind is still negotiating with hope.

The Nine Meetings Problem

I want to come back to this because it's the part that should scare any founder in a similar situation.

Nine meetings in three days. Real companies. 100+ employees. Ready to commit. That's not a pipeline problem. That's not a sales problem. That's not a cold email problem. The outbound was working. The offer was resonating. The deals were there.

The only thing standing between this team and revenue was software that wasn't ready. And the software wasn't ready because of an accountability breakdown that had been developing for weeks while the founder told himself the developer was very responsible.

This is the compounding cost of avoiding hard conversations. It's not just the day you lose. It's the nine meetings that go sideways. It's the buyers who came in hot and will have cooled off by the time the product is ready. It's the momentum that you spent weeks building through outbound - the emails, the follow-ups, the calls - that evaporates because the back-end couldn't keep up with the front-end.

If you're running outbound and it's working, but your delivery or product side can't keep pace, you don't have a sales problem. You have an operations problem. And operations problems don't fix themselves while you're busy defending someone's character.

If you want to see what a working outbound system looks like before you scale into that wall, take a look at the 7-Figure Agency Blueprint - it covers the operational side of growing without the delivery falling apart.

How to Know If You're in This Pattern

If you're not sure whether you're doing this with someone on your team right now, here's how to check. Ask yourself the following:

• When someone asks why deliverable X isn't done, do you explain the person's situation or do you explain the delay?
• Have you said something like "they're usually great" in the last month?
• Are you giving extra time because you believe it'll result in a different outcome - or because you don't want to have the conversation?
• Are you interviewing replacements?

If you answered yes to that last one, you're already past the point of "managing someone through a rough patch." You're in exit mode and pretending you're not.

That's okay. Recognizing it is the first step. The second step is to stop saying the character words - responsible, talented, committed, passionate - and start saying the output words: what exactly needs to happen, by when, and what changes if it doesn't?

Give that conversation. Have it directly. If the outcome changes, great. If it doesn't, you've now got a documented reason to move on instead of a vague sense of guilt and a developer who's still not committing code.

The Bigger Pattern I See With Early-Stage Founders

What happened on this call is extremely common with founders who are building for the first time. And it shows up in more places than just developer relationships. I see it with co-founders. With first salespeople. With early agency hires. With contractors who did great work six months ago and have since checked out.

The first time you hire someone and it doesn't work out, it feels like a personal failure. Like maybe you weren't a good enough leader. Like maybe you didn't explain things clearly. Like maybe they would have performed if you'd just done something differently. And some of that might even be true - but none of it is a reason to keep someone in a role they're not performing in.

The kindest thing you can do - for them and for you - is to be direct. Tell them what's not working. Give them a chance to fix it with specific expectations attached. And if it doesn't change, let them go cleanly so they can find something that fits them and you can find someone who will show up.

That's not harsh. That's respect. The disrespectful thing is what most founders do: keep the person on, stop trusting them with real work, route around them, complain about them in calls - while telling yourself they're very responsible.

What Happened Next

On the call, we made a practical decision: V's partner would make sure all three GitHub repos were secured and accessible. They'd download what they needed. They'd add V to the accounts. And they'd move forward with interviewing the candidates they already had lined up, with me willing to jump on a quick call to help vet the technical fit.

Simple. Clean. Forward-moving.

The hardest part wasn't figuring out what to do. It was saying out loud that the current situation wasn't working and wasn't going to fix itself. Once V's partner said that - once the he is very responsible energy got replaced by we need someone who can fill this gap - the rest of the call took about ten minutes.

That's always how it goes. The clarity is instant once the grief is done.

The Line That Changes Everything

If you take one thing from this post, make it this:

Character is not a deliverable.

When you're managing someone - a developer, a salesperson, a contractor, a co-founder - you are not assessing who they are as a human being. You are assessing whether this working relationship is producing the results that both parties agreed to. That's it.

Someone can be a great person and still be the wrong fit for your team at this stage of your business. Someone can have been incredibly valuable six months ago and not be the right person for where you're going now. Someone can be, by all accounts, very responsible - and still be letting your nine booked meetings slip through the cracks because the software isn't finished.

When you hear yourself saying the character words in response to an output question, pause. Notice it. Ask yourself: am I managing, or am I grieving?

If you're grieving - if you already know the relationship isn't working and you're just not ready to say it - say it anyway. Say it to yourself first. Then say it to them.

The business can't wait for you to finish processing. You've got meetings to close.

If you're at a stage where you're building your outbound, getting meetings, and want to make sure the back-end of your operation is solid before you scale - the Discovery Call Framework is a good place to start on the sales side. And if you want to work through the operational and hiring stuff live, with people who are in the same growth stage, that's what Galadon Gold is built for.