You Nodded Through an Explanation You Didn't Understand

I was on a coaching call the other day. The person I was working with - let's call him a non-technical operator building a SaaS product - was doing a live walkthrough with his developer. The dev was screensharing. Things were mostly working. There was a chatbot. There were AI usage counters. The UI colors looked right.

And then the developer started explaining a bug.

He walked through four iterations of a file upload plugin. He described how the fourth iteration introduced a URL dependency that broke the parameter initialization. He explained how the model couldn't initialize because of the way the saved file reference was structured. He talked about removing a specific parameter and how that fixed the AI usage tracking. He gave a live example. He showed the counter incrementing. He said it was a simple fix once he found it.

This explanation took about 90 seconds.

Nobody said anything. The operator said nothing. I said nothing. The developer finished, moved on to the next item on the QA list, and we all just kept going.

Here's what I want to ask you directly: how much of that did you understand just now? Because I'll tell you how much I understood in the moment - maybe 40%. And I've built and sold multiple software companies. I've been on hundreds of dev calls. I've managed engineers for years.

And I still nodded. We both did. And that's the problem.

The Nod Is the Most Expensive Move You Make

When you nod through a technical explanation you don't understand, you're not being polite. You're not saving time. You're deferring a cost into the future - and it always comes due at the worst possible moment.

Here's how it plays out. Your dev explains something. You don't follow it. You nod. The meeting ends. The dev builds based on his understanding of the problem and his solution. Two weeks later, something breaks in a way you didn't expect. Or a feature doesn't work the way you thought it would. Or you're demoing the product to a client and you realize you can't actually explain what you're showing them.

You go back to the dev. He explains it again. You still don't fully follow it. You nod again. The cycle repeats.

Multiply that by six months of weekly dev calls. Multiply it by every standup where you half-understood the status update. Multiply it by every Slack message where you saw a technical block and thought "he'll figure it out." What you get is a product built with a 40% information gap baked into every decision you made. Features that solve problems slightly differently than you intended. Architecture that made sense to the developer but not to you. A gap between what you thought you were building and what you actually built.

And you can't point to any single moment where it went wrong. Because it didn't go wrong in one meeting. It went wrong across a hundred 90-second nodding moments.

What Was Actually Being Explained

Let me go back to that bug explanation, because I think it's worth unpacking - not technically, but structurally.

The developer had gone through four iterations of a file upload plugin. Each time, there were issues. By the fourth plugin, he added a constraint to display a saved file reference. That constraint created a URL dependency - meaning the system needed a valid URL tied to the file to function. When a new initialization happened without that URL present, the model failed. The AI usage tracker stopped working. The fix was removing that URL parameter requirement so initialization could happen cleanly.

Now - did you follow that? More importantly: would you have followed it at 11am on a Zoom call while also half-reading a Slack message from someone else?

Probably not fully. And that's okay. The question is what you do about it.

The operator on my call didn't ask a single clarifying question. He moved straight to: "Okay, so it's working now?" And the developer confirmed it was working. And they moved on.

But here's what the operator didn't understand: why it had broken in the first place. He didn't understand what the URL dependency was doing in the architecture. He didn't understand whether removing that parameter might create a different problem downstream. He didn't understand whether this same class of bug might appear elsewhere in the codebase because of how the file upload had been refactored four times.

He didn't know what he didn't know. Because he nodded.

Why Non-Technical Founders Don't Ask

I get why it happens. When you're not technical, asking for clarification feels like admitting weakness in front of your own developer. You hired this person. You're paying this person. You're supposed to be running this project. Stopping to say "I don't understand what you just said" feels like it exposes you.

So instead you nod. You say "got it" or "okay, makes sense" or "cool, let's keep going." You signal competence you don't have, in a room where the other person knows you don't have it and is probably expecting you to ask.

Developers - good ones, at least - want you to ask questions. They want to know that what they're building matches what you actually need. The worst thing for a developer is to spend two weeks building something based on a miscommunication that could have been cleared up in 30 seconds. They would rather explain the bug three times than refactor a feature twice.

The awkwardness is entirely in your head. I promise you, no developer has ever thought less of a founder for saying "walk me through that again, I want to make sure I understand the dependency before we move on."

What developers do think less of is when you nod, they build, and then three weeks later you say "this isn't what I wanted" - and it turns out the gap traces back to a conversation they thought you understood.

The Sentence That Saves Projects

There is one sentence that can functionally eliminate most of the silent failure modes in non-technical product development. It's not a framework. It's not a process. It's seven words:

"I don't understand what you just said."

That's it. That's the whole technique.

Not "can you simplify that?" - which sounds condescending and puts the pressure on the developer to dumb themselves down. Not "interesting, let me think about that" - which is just a slower nod. Not silence followed by a vague follow-up question that dances around your confusion.

Just: I don't understand what you just said. Can you walk me through it again?

What happens next is almost always useful. The developer has to reconstruct the explanation. In doing that reconstruction, they often find better language. They use an analogy. They draw something. They pull up the code. And you either understand it the second time - which means the first explanation was unclear, not you - or you get to a specific point of confusion you can name: "Okay, I'm with you up to the URL dependency. Why does the model need a URL to initialize?"

Now you're having a real conversation. Now you're building shared understanding instead of one person broadcasting and the other pretending to receive.

There Are Still Bugs in This Product

At the end of that call, there was still at least one unresolved bug - a delete functionality issue that the developer needed to follow up on with another member of the team. The operator knew it was there. He'd flagged it. But he also wasn't entirely sure what was causing it, how significant it was, or how long it would take to fix - because the explanation of the bug involved another layer of technical context he'd half-followed.

His plan was to post a message on WhatsApp and wait for an update. Which is a fine workflow. But it also means his next data point on that bug is going to be "it's fixed" or "it's not fixed yet" - with no real understanding of what "fixing it" involves or what could go wrong.

That's the operating mode most non-technical founders are stuck in. Binary status updates - done or not done - with no visibility into the actual work. And that's a consequence of the nodding habit. When you never ask what you don't understand, you train yourself and your team into a workflow where you only ever get surface-level information.

You don't know what's hard until it's late. You don't know what the dependencies are until something breaks. You don't know what decisions were made on your behalf until you're looking at a finished product that isn't quite what you needed.

How to Actually Run a Dev Meeting if You're Non-Technical

This is the part people usually want - the tactical piece. So let me give it to you straight.

First: slow down the explanations that matter. When a developer starts explaining a bug, a fix, or an architectural decision, treat it as a transfer of important information - because it is. Don't let it pass by in 90 seconds. If it took them two days to find the fix, it probably warrants two minutes of shared understanding.

Second: repeat back what you heard. This is the single most powerful thing you can do in a technical meeting. After the developer explains something, say: "Let me make sure I've got this right - the problem was X, the fix was Y, and the reason Y works is Z. Is that right?" You will be wrong at least 30% of the time. That's the whole point. The correction is where the understanding happens.

Third: ask about the category, not just the instance. When a bug gets explained, ask: "Is this a one-time thing, or could this same class of issue appear elsewhere?" You don't need to understand the technical details of why. But you need to know whether you're patching a hole or patching a symptom. Your developer knows the difference. They just won't always volunteer it unless you ask.

Fourth: when you're lost, say so immediately. Don't wait until the end of the explanation to raise your hand. The moment you lose the thread, stop: "Hold on - you said the parameter initialization - what's getting initialized? Walk me back one step." Getting lost and asking early is a 30-second detour. Getting lost and not asking is a three-week detour.

Fifth: record everything. Not for surveillance - for your own comprehension. When you can replay a technical explanation at half speed, with the ability to pause and look things up, your understanding goes from 40% to 80% without any extra effort from your developer. Use Loom. Use Zoom recordings. Use whatever. Just record it.

This Isn't a Technical Problem

I want to be precise about this, because I think non-technical founders sometimes use their non-technical status as a fixed identity rather than a current limitation. "I'm not a developer" becomes "I can't understand developer explanations" - and that's not true.

You don't need to understand code to understand logic. You don't need to know what a parameter is at a code level to understand that a dependency existed, that it was removed, and that removing it fixed the problem. Those are just cause-and-effect relationships. Your brain does cause-and-effect all day long.

What you need is the willingness to ask. And the confidence to be confused out loud instead of silently.

The developers who've worked on my products - on ScraperCity, on Galadon, on other projects - have always been better partners when I've asked dumb questions than when I've pretended to follow something I didn't. Every time I've said "wait, say that again" or "I'm not tracking - why would that cause the model to fail?", I've gotten better information, made better decisions, and shipped fewer things that needed to be redone.

Competence in running a software project isn't knowing what your developer knows. It's making sure you and your developer have the same understanding of what's being built and why.

The Compounding Cost Nobody Talks About

Here's the thing nobody in the "how to manage developers" content world really addresses: the cost of nodding doesn't show up on a timeline. It doesn't show up in a project management tool. It doesn't show up anywhere you can point to.

It shows up in the feeling you get three months into a build when you realize the product is technically functional but slightly, persistently wrong - in ways that are hard to articulate because you never fully understood the decisions that got you here.

It shows up when you're pitching the product and someone asks you a specific question about how something works and you have to say "let me check with the dev."

It shows up when you're trying to plan the next sprint and you don't really know what's possible because you've never had a clear enough understanding of the architecture to have an informed conversation about scope.

All of that traces back to 90-second explanations that passed without a single clarifying question.

The operator I was coaching is close to shipping. The product looks good. Most of the QA is done. But there are two or three things he doesn't fully understand about how it works - and those gaps are going to surface the moment a real user does something unexpected. That's not a development problem at that point. That's an operator problem. And it has a clear origin story: a habit of nodding.

If you're building a product right now and you've been doing this - and you have, we all have - start the next meeting differently. Pick one thing your developer says that you don't fully follow. Stop them. Say the seven words. Make them explain it again.

It will feel uncomfortable the first time. It won't feel uncomfortable the second time. And by the tenth time, you'll have a fundamentally different product - not because your developer got better, but because you did.

If you want to go deeper on building and running outbound systems alongside your product development - so you're not just building in silence but actually filling your pipeline while you build - check out the 7-Figure Agency Blueprint. And if you want to work through this kind of thing directly, come find me at Galadon Gold.

Stop nodding. Start asking. The project you save is the one you're building right now.