"Today or Tomorrow" Is Not a Commitment

The call wasn't dramatic. No client blowup, no missed launch, no money on fire - at least not yet. It was a routine standup with a dev team I'd brought on to build something for one of my companies.

The developer walked me through where things stood. The code worked perfectly on his local machine. When he pushed it to the server, something unexpected broke. He'd pulled the logs, had a sense of what was wrong, and said he expected to fix it. Standard stuff. Happens all the time with deployments.

Then I asked the question almost every founder or manager asks in this exact situation:

"Are we expecting this today, right?"

He said: "Yeah. No, not of that."

Read that answer again. Yeah. No, not of that.

That's not a yes. That's not a no. That's a person who doesn't want to disappoint you, so he started with yes before reality caught up to him mid-sentence. And I moved on. Call ended. Next meeting scheduled.

The problem wasn't him. The problem was the question I asked.

The Closed Question Trap

There's a specific kind of question that feels like accountability but isn't. It sounds like you're checking on progress. It sounds like you're keeping things on track. But all it actually does is give the other person an invitation to say yes - and most people will take that invitation every single time.

"We're expecting this today, right?"

"You'll have that over to me by Friday, yeah?"

"We're still on track, correct?"

These are closed questions. Yes-or-no. And they have a social dynamic baked into them that almost always produces one answer: yes.

Think about what you're really asking when you say "we're expecting this today, right?" You're not asking a neutral question. You're expressing a preference - I want this today - and then tagging a question mark onto the end to make it look like you're open to the answer. But the person on the other end of that question isn't processing it as an open inquiry. They're processing it as: Alex wants this today. If I say no, I'm the person who failed him. If I say yes, this conversation ends and I don't have to deal with the discomfort right now.

So they say yes. Even when they mean no. Even when they're not sure. Even when the realistic answer is "maybe, if nothing else goes wrong, but there are two blockers I haven't mentioned yet because you didn't ask."

And then the deadline comes. And the thing isn't done. And now you're having the hard conversation anyway - just later, when you have less time to fix it.

Why "Today or Tomorrow" Tells You Nothing

The developer on my call had a real answer embedded in his non-answer. The code had been working locally. The server deployment surfaced something unexpected. He'd downloaded the logs and identified a potential fix. He had a theory, not a certainty.

That's an honest, reasonable place to be with a technical problem. Anyone who's ever shipped software knows that deployment issues are a different category of problem than development issues. What works locally can break on a server for reasons that have nothing to do with your code - environment variables, dependency versions, permissions, infrastructure configuration. The fix could take twenty minutes or two days.

When I asked "we're expecting this today, right?" - I got "yeah, no, not of that." Which roughly translates to: I want to say yes because you want to hear yes, but I'm not actually confident, so I'm hedging in real-time as the words come out of my mouth.

That answer contained the real information. The real information was: there is risk here and I don't know exactly how much.

But because I asked a closed question, I gave him the exit ramp. He didn't have to articulate the risk clearly. He just had to make it through a yes-or-no interaction without committing too hard in either direction. And we both moved on with a false sense that things were under control.

This is what I mean when I say "today or tomorrow" is not a commitment. It's a comfort ritual. You ask it to feel like you checked in. They answer it to avoid friction. Nothing meaningful was communicated. You both got to move on. And then the deadline gets missed.

The Only Question That Actually Surfaces Risk

I've been running teams for a long time. Agencies, SaaS companies, dev projects, sales teams. And I've asked enough closed timeline questions - and watched enough deadlines slip - to know that there's really only one question worth asking when you want to know if a deadline is real:

What would stop this from being done today?

Notice what this question does differently. It's open-ended. You can't answer it with a yes or a no. You have to actually think about the blockers, name them, and put them on the table. It forces the person to walk through the realistic path to completion instead of just pattern-matching to the answer you seem to want.

It also signals something important: I'm not just looking for reassurance. I actually want to know what could go wrong. That's a different conversation. That's one where a developer feels safe saying "actually, there's this one thing I'm not sure about yet" instead of just nodding along.

If I'd asked "what would stop this from being done today?" on that call, here's the kind of answer I might have gotten: "The main risk is that the server issue is more complex than the logs suggest. I think I know the fix, but if that doesn't work, I'll need to dig deeper and it could push to tomorrow."

That answer gives me something I can work with. I know there's a primary scenario and a fallback. I know there's a real chance this slips. I can plan around it - adjust client timelines, communicate ahead of time, have a contingency ready. Instead of sitting around waiting, confident that the thing is on track, and then getting blindsided.

"What would stop this?" is not a hostile question. It's not a gotcha. You're not trying to catch someone in a failure. You're trying to do the one thing that's actually hard in fast-moving companies: find out where the risk is before it blows up.

The Buyer Spiral for Managers

There's a pattern I see in founders and managers that's basically the management equivalent of the buyer spiral - that cycle where you buy a system, it doesn't work right away, and instead of digging in to find out why, you move on and buy something else. Always feels like momentum. Never actually is.

The management version works like this: you run a standup, ask the comfortable questions, get comfortable answers, and feel like you're on top of things. Then the deadline misses. Then you have a harder conversation. Then you hire someone different, or buy a different tool, or restructure the team. But the root cause - that you were never actually getting real information about risk - never gets addressed.

The fix isn't a new team member or a new process. The fix is a better question. Specifically, replacing closed timeline questions with forward-blocker questions. It's one of the cheapest process improvements you can make and it changes everything about how teams communicate.

Ask "what would stop this?" instead of "this is happening today, right?" - and you'll start getting actual answers. Some of them will be uncomfortable. Good. Uncomfortable answers on Monday are a thousand times better than missed deadlines on Friday.

This Isn't Just a Dev Team Problem

I want to be clear: this isn't a developer problem or a technical project problem. This is a universal human behavior problem. People say yes to closed questions because saying no creates friction, disappointment, and social discomfort. So they defer. They hedge. They give you the answer that ends the conversation most painlessly.

It happens in sales too. You've probably seen it. You get a prospect on the phone, walk them through your offer, and ask: "Does this sound like something you'd want to move forward with?" And they say yes. And then they ghost you.

They weren't lying, necessarily. They were deferring. "Yes" in that moment meant "yes, I want to stop feeling the pressure of this question." Not "yes, I'm making a buying decision."

The better question is forward-blocker: "What would need to be true for this to make sense for you right now?" Now they have to articulate the actual objection - budget, timing, internal approval, competing priorities. You get the real information instead of the socially convenient answer.

Same with hiring. "Can you have this done by the end of the week?" versus "What's your realistic timeline if everything goes smoothly, and what would push it past that?" First question gets you a yes. Second question gets you a project plan.

Same with closing deals. "We'll get the contract over today, right?" versus "What needs to happen on your end before you're ready to sign?" First question gets you a head nod. Second question surfaces the actual blockers - legal review, stakeholder sign-off, budget approval - so you can move those things instead of just waiting.

The pattern is always the same. Closed question → social compliance → false confidence → missed expectation → damage control. Open forward-blocker question → real information → actual risk management → fewer surprises.

What Actually Happened on the Call

The developer and I wrapped up by shifting the daily standup format. The call had been a daily check-in, but since we weren't actively scoping new features, the daily all-hands wasn't the highest-value use of everyone's time. The developer suggested moving to a tighter loop between him and the project lead, then surfacing updates to me separately. That made sense.

It was a reasonable conversation. The deployment issue was real but manageable. The team was communicating on Slack, working through the problem, and had a clear path forward.

But the thing that stuck with me wasn't the deployment issue. It was the moment when I asked "we're expecting this today, right?" and got "yeah, no, not of that" - and we both just moved on like that answered the question.

That's the thing about comfort rituals in business. They feel productive in the moment. You asked the question. They gave an answer. Everyone can move on. But if you're building something - a product, a company, a sales system - that false comfort compounds. Every standup where you asked the comfortable question and got a soft yes instead of a real answer is a small piece of risk you didn't see until it showed up as a problem.

I'm not trying to make you paranoid about every team interaction. Most deadlines don't miss. Most developers fix most problems without drama. But the ones that do blow up? They almost always gave you the signal early. You just asked the wrong question, so they gave you the answer that got them off the hook instead of the answer that would have let you help.

Implement This Before Your Next Standup

If you're running a team right now - dev team, sales team, agency delivery team, doesn't matter - go into your next standup with one question replaced.

Every time you'd normally ask a closed timeline question - "this is done today, right?" / "we're still on track?" / "we're hitting Friday, correct?" - replace it with:

What would stop this from being done by [date]?

Or a variation:

• What's the biggest risk between now and the deadline?
• If this slips, what's the most likely reason?
• Walk me through the path to done - what has to happen between now and then?

These questions do something closed questions can't: they invite honesty instead of compliance. They tell the person you're talking to that you can handle real information, and that you'd rather have it now than find out by missing a deadline.

The other thing you'll notice is that people who are actually on track have no problem answering these questions. If there are no real blockers, they'll just tell you that. "Nothing should stop it - the main work is done, just need to test and push." Great. You got confirmation that actually means something. If there are blockers, they'll tell you those too, because you gave them an opening to.

Either way, you're making decisions based on real information instead of socially manufactured reassurance.

That's the whole game. Not just in standups - in sales calls, in proposals, in client check-ins, in hiring. The people who consistently get real information make better decisions faster. The people who keep asking "this is still on track, right?" keep getting surprised.

If you want to get better at the conversation structure that actually converts - both on sales calls and internal team calls - the Discovery Call Framework breaks down how to ask questions that surface real information instead of social compliance. A lot of the same principles apply whether you're closing a deal or running a project standup.

And if you want more of this kind of coaching - real calls, real situations, real problems worked through in real time - that's what Galadon Gold is built for.

But start with the question. "What would stop this from being done today?" Ask it in your next call. See what you learn that you wouldn't have heard otherwise.

The answer might be nothing. Or the answer might be the thing you needed to know three days ago.