Asking Questions Takes Less Time Than Doing the Wrong Thing

The tree swing cartoon is widely known and frequently remixed for good reason. It captures something almost everyone in the software industry has experienced: you thought you were clear when writing requirements or asking for something, but the other person interpreted it differently. Everyone knows this happens. The interesting question is why it keeps happening.

What Unclear Looks Like

When someone in a position of authority mentions "We should really support Y" in the middle of a project, teams often interpret that as an immediate directive. But is it? Does that person want to expand scope and push the timeline, or are they mentioning something to consider for the roadmap? Without asking "Do you want us to include this in the current scope, or should we add it to the backlog for later?" you risk either derailing the project to build something that wasn't urgent, or missing something that actually needed to happen.

Or consider "Can you look into why this is slow?" Slow for whom? Which part of the system? Slow compared to what baseline? Is this a recent regression or a long-standing issue? Better to ask "Are you seeing this in production for all users, or is this about a specific workflow?" than to spend half a day profiling the wrong part of the system.

The pattern I've noticed is that the more familiar you are with someone's communication style, the better you get at guessing what they mean. But that familiarity can work against you when the request is outside the usual pattern. You fill in gaps with context from past interactions that don't always apply.

The Upfront Time Investment

Asking clarifying questions and restating understanding to confirm alignment takes more time upfront, but in my experience, it consistently reduces overall time spent. The problem is that the upfront time is visible and feels like an interruption. Someone sends you a request, you have a few clarifying questions, and now you're worried you're slowing them down or looking like you don't understand something. So you make your best guess about what they meant and start working.

Then you deliver something that isn't what they expected. Now you're in a feedback loop that takes longer than those questions would have taken. Worse, you've spent time building something that won't get used.

I've seen this pattern play out in both directions. When I've asked someone to do something and gotten back work that missed the mark, it's usually because my request was ambiguous in ways I didn't notice. As a result, I've learned to be intentional about asking clarifying questions when I receive unclear requests, even when I think I understand. The social cost of asking is always lower than the cost of building the wrong thing.

Why This Is Hard

People know they should ask clarifying questions. The problem is that asking questions carries social cost. You're interrupting someone's flow. You might look like you're not paying attention or don't have the context you should have. The incentive structure pushes toward making your best guess and moving forward.

Async communication amplifies this. When someone asks you something in Slack and you have clarifying questions, the round-trip cost becomes visible. You're blocked until they respond, which could be hours or a full day. That makes "just start working and assume I understand" feel more productive than waiting for answers. But the tradeoff is backwards. Spending a day waiting for clarity is almost always cheaper than spending a day building the wrong thing and then waiting for feedback.

From the other side, writing requests that anticipate every possible question takes time and effort. When you're in the middle of something and need help, the path of least resistance is to fire off a quick message and assume the other person will ask if they need more detail. You're externalizing the cost of disambiguation. But if you're consistently getting back work that isn't what you expected, the issue might not be that your team isn't asking enough questions. Your requests might assume context or clarity that isn't actually shared. The time you spend writing a clear request upfront is often less than the time spent in feedback loops when you don't.

I've found that teams that explicitly talk about this tension and agree that clarifying questions are expected and valued tend to have fewer misalignment issues. But it requires active effort to counteract the default incentives. One of the most effective things I've seen is senior people modeling the behavior publicly. Ask clarifying questions in shared channels and on calls. Make it visible that asking questions is what good work looks like, not an interruption or a sign that someone doesn't understand. When you model this consistently, it shifts the culture. People start to see clarifying questions as diligence rather than friction.