Don't Tell Me You Can't Do It Unless You Can Tell Me Why

Early in my career, I had a mentor who changed the way I think about problems. He was my manager, a friend, and the person who gave me my first real shot in programming. One piece of advice he gave me has stuck with me ever since:

"Don't tell me you can't do it unless you can tell me why you can't do it."

At the time, it felt simple. Almost obvious. But over the years, I've realized how powerful that mindset really is — not just as a problem-solving technique, but as a way of leading.

Every engineering leader hears it. "This can't be done." "This won't work." Sometimes it's true. Most of the time, it's an instinctive reaction — a conclusion arrived at before the reasoning has caught up.

The problem isn't that people say it. The problem is that conversations stop there. The statement gets accepted or overruled, and either way the actual obstacle never gets examined.

That gap — between "I can't" and "here's why" — is where most solutions live. Forcing yourself across it changes the question entirely. "I can't" becomes: What specifically is blocking this? Is it a technical limitation, a knowledge gap, or an assumption? What would need to be true for this to work?

More often than not, the act of explaining why exposes the path forward. The blocker turns out to be narrower than it felt. The assumption turns out to be wrong. The limitation has a workaround that was invisible until the problem was spoken out loud.

And even when the answer really is no — the explanation creates clarity. Clarity about constraints. Clarity about tradeoffs. Clarity the rest of the team can build on instead of guessing around.

That clarity is where real collaboration begins.

The way you ask matters. "Why can't you do it?" delivered as a challenge shuts people down. Delivered as genuine curiosity — help me understand what's in the way — it opens a door.

When someone on my team says "this won't work," my first question is always: why? Not to prove them wrong. Not to pressure them into saying yes. But to help them think past the first reaction and into the actual obstacle. Nine times out of ten, they talk themselves into a solution I never would have seen. The breakthrough was already in their head — it just needed a reason to come out.

That's the thing about this habit. It's not about being the person with the answer. It's about creating the space where the answer surfaces.

When I'm mentoring someone earlier in their career, this is the single most valuable instinct I try to build. Not "never say can't" — that's toxic positivity. But never stop at can't. Go one step further. Explain the why. That's where the thinking actually happens.

The most surprising thing about this principle is how far it extends past engineering.

When I was running my own business without a technical sounding board, I'd talk problems through with anyone willing to listen — including my wife. She didn't need to understand the technical details. The act of articulating the problem out loud was enough. More often than not, the answer showed up mid-sentence.

That's when it clicked for me: communication isn't just how we share solutions. It's how we discover them.

The discipline of explaining why something won't work is really the discipline of understanding your own problem well enough to see past it. Whether that's in a sprint planning meeting, a 1:1, or a conversation at the kitchen table — the mechanism is the same. Clarity doesn't come from thinking harder. It comes from making the invisible visible — and the fastest way to do that is to say it out loud.

If you're early in your career, or decades into it, this is a habit worth building: don't stop at "it can't be done." Figure out why.

You might be closer to a solution than you think.