Why "What Would Help?" Doesn't Work (And What to Say Instead)

Here's what I've learned: when someone is genuinely stuck, asking them to identify their own solution often just adds another layer of paralysis. They're already overwhelmed by not knowing what to do. Now you're asking them to also know what would help them figure out what to do.

It's like asking someone having a panic attack to explain what would calm them down.

The Real Problem Is Usually Not The Stated Problem

When your colleague says "I need to understand MongoDB before I can work on these tickets," that's rarely the actual barrier. The actual barrier is usually something like:

• Fear of looking incompetent if they ask questions

• Perfectionism that demands complete understanding before starting

• Shame about not knowing something they think they "should" know

• Analysis paralysis disguised as thoroughness

• Not knowing what questions to even ask yet

I see this pattern constantly. Someone gets stuck, identifies a "learning gap," and then retreats into research mode. It feels productive. It looks like diligence. But it's actually a way to avoid the vulnerable position of starting something before you feel ready.

And here's the thing: in tech, you almost never feel ready. The systems are too complex, the documentation is incomplete, and there's always more you could learn. Waiting to feel ready is just waiting indefinitely.

So What Actually Works?

What actually changes these patterns aren't insights or understanding. It's corrective experiences: repeated situations where the thing that used to mean danger or criticism turns out to be safe.

Here are four strategies that create those experiences:

1. Name The Pattern You're Seeing

What to say

"It seems like you're waiting to feel ready before you start, but I don't think that feeling is coming. What if you just started messy?"

This works because it bypasses their need to have insight into their own stuck-ness. You're giving them something concrete to react to rather than asking them to diagnose themselves.

When I was earlier in my career, I used to do this constantly: try to learn everything before touching the actual work. I just needed to take one more React course, read one more architecture tutorial, really understand the database schema. I thought I was being thorough. It wasn't until I was diagnosed with ADHD in 2024 and started digging into my own patterns that I realized I was just procrastinating in a way that felt productive.

Where to go from here

If they seem relieved or acknowledge the pattern:

"Okay, so what does 'starting messy' actually look like? Like literally, what's the first small thing you could do in the next hour?"

If they push back ("but I really do need to understand X first"):

"What makes you think you need to understand it perfectly before trying? Where did you learn that approach?"

This often reveals earlier experiences of being shamed for not knowing things, or perfectionist patterns they're not fully aware of.

The corrective experience

What makes this approach powerful is what happens next. When someone actually starts before they're ready and discovers it works out okay, it builds evidence against the belief that they need to be perfect. That first messy PR that gets helpful feedback instead of harsh criticism. That ticket they complete without fully understanding the entire system. Each time, they're proving to themselves that imperfect action leads to progress, not disaster.

2. Offer A Specific Small Step

What to say

"What if you just picked one ticket and asked [senior engineer] to walk through it with you tomorrow morning?"

People who are paralyzed can't see the whole path forward. But they can sometimes respond to a single, concrete action. You're not asking them to solve the problem. You're handing them step one.

The key is making it small and time-bound. "Learn MongoDB" is overwhelming. "Spend 30 minutes pairing on one ticket" is doable.

Where to go from here

If they agree:

"Great. Do you want to message them now to set that up, or do you need to think about how to phrase it?"

Follow through to actual action, not just agreement in theory.

If they hesitate or make excuses:

"What just happened? You seemed open to it for a second and then pulled back. What's the scary part?"

This catches the resistance in real-time and helps them see what's really blocking them.

The corrective experience

What often happens in that first pairing session is revelatory. The person discovers that the senior engineer doesn't have the entire system memorized either. They Google things. They check the docs. They say "I'm not sure, let's figure it out together." This shatters the belief that competence means knowing everything already. It reframes collaboration from "exposing my incompetence" to "this is just how we work here."

3. Ask About The Fear Instead

What to say

"What's the scariest part of just asking for help right now?"

This gets at the actual barrier. And often, just naming the fear reduces its power.

Common fears I've encountered (and experienced myself):

1. "They'll think I'm incompetent"

Reality-test this belief. Has your senior engineer ever actually said or done anything that suggests they judge people for asking questions? What do you think when other people ask for help? Do you think they're incompetent?

Where this usually comes from: perfectionism, imposter syndrome, or past experiences where asking questions was met with impatience or judgment.

The corrective experience

Sometimes the most powerful thing that can happen is asking the question you're terrified to ask and discovering the catastrophe you imagined doesn't happen. The senior engineer doesn't roll their eyes. They don't sigh with impatience. They say "oh yeah, that part of our system is confusing, let me show you how it works." That single interaction can start to rewire years of believing that asking questions equals incompetence.

2. "I won't even know what questions to ask"

Reframe this as exactly the reason to ask for help. "I'm stuck and I don't even know what questions to ask yet" is a completely valid thing to say. The first question can just be "can you walk me through how this works?"

I used to struggle with this exact barrier. I was a procrastinator who would put things off until the stress and adrenaline of an impending deadline forced me into a work binge that may or may not actually get the work done. I was talking with a tech director once, trying to work through why I wouldn't just ask for help earlier. I told him: "I don't know how to ask for help when I don't even know what questions I need answered."

He said something simple that I've never forgotten: "It's okay to say 'I'm stuck, I don't even know what to ask to get unstuck.'"

That permission to acknowledge being stuck without having to articulate a perfect question first? That changed everything. I didn't need to diagnose my own problem or formulate the exact right question. I just needed to say "I'm stuck" and let someone help me figure out what questions to ask.

The corrective experience

When someone gives you explicit permission to be stuck without having all the answers, it breaks the belief that you need to understand your problem before you can ask for help. You learn that "I don't know what to ask" is itself valuable information, not a disqualifier from getting support.

3. "I should be able to figure this out myself"

Challenge the "should." Says who? Where did that rule come from? Is that actually how work works here, or is that a rule you're imposing on yourself?

This often reveals beliefs about self-reliance from childhood or early career experiences where asking for help was seen as weakness.

The corrective experience: The healing here comes from discovering that your worth isn't conditional on figuring everything out alone. When you finally say "I'm stuck and I need help" and the response is "okay, let's tackle this together" instead of disappointment or judgment, it challenges the core belief that needing help makes you inadequate. You start to learn that asking for help actually makes you easier to work with, not a burden.

4. Present The Choice Explicitly

What to say

"You can either ask for help now while there's still time, or you can wait until it's a crisis. Both are options, but one is going to be way less miserable."

This acknowledges their agency while making the consequences clear. Sometimes people need permission to see that avoiding the uncomfortable thing now just creates a worse uncomfortable thing later.

I've watched talented engineers choose the crisis path over and over, and it's painful to see. The deadline pressure eventually forces them into action, but by then they're working from a place of panic and shame instead of curiosity and learning.

Where to go from here

If they choose "wait until crisis":

"Okay, I hear you. What usually happens when you do that? How does it feel?"

Don't rescue them, but help them make the choice consciously rather than by default.

If they choose "ask for help now" but don't follow through:

"So you said you wanted to ask for help before it became a crisis, but it's been three days. What got in the way?"

Curiosity, not judgment. There's useful information here about what's actually blocking them.

The Pattern Behind The Pattern

Here's what's usually happening when someone can't answer "what would help?": they're focused on the wrong problem.

They think their problem is "I don't understand MongoDB."

Their actual problem is "I'm too afraid to look incompetent to ask for help."

They think their problem is "I need more time to learn this."

Their actual problem is "I believe I should already know things I haven't been taught, and admitting I don't know feels like failure."

So asking them what would help with the technical gap is never going to get you anywhere useful. The better intervention is naming the real problem (the fear, the avoidance, the perfectionism) and either offering a concrete small step or just being honest about what you're seeing.

How Corrective Experiences Compound

Here's what's important to understand: these corrective experiences build on each other.

The first time someone asks for help and it goes well, they might dismiss it as luck. "That person was just being nice." The second time, maybe it's still a coincidence. But by the fifth or tenth time, the evidence becomes undeniable. Maybe asking for help really is just how things work here.

You're not just solving an immediate work problem. You're helping someone build new evidence against beliefs that have been holding them back for years. Each positive experience creates a small crack in the foundation of "I must be perfect" or "I should already know this" or "asking for help means I'm incompetent."

This is why the specific small steps matter so much. You're not just getting tickets done. You're creating opportunities for someone to have experiences that challenge their limiting beliefs. The pairing session where they discover the senior engineer also Googles things. The code review where their "dumb question" leads to a good discussion. The standup where they admit they're stuck and someone says "oh yeah, that part is tricky, want to pair on it?"

Sometimes the corrective experience isn't even theirs directly. Watching a principal engineer ask a basic question in a meeting can be transformative. It normalizes not knowing everything. It models that competence isn't about having all the answers. It's about knowing how to find them and being willing to ask.

When These Approaches Don't Work

If you try these strategies and the person still can't move forward, that's important information. It might mean:

• They're dealing with something bigger than work stress (depression, anxiety, burnout, life circumstances)

• There's a trauma response being triggered (asking for help feels genuinely dangerous, not just uncomfortable)

• Their current coping strategies aren't working anymore

• They need professional support, not just collegial encouragement

This is where you reach the limits of what a supportive colleague can do. You can name what you're seeing, you can offer specific pathways forward, and you can reality-test fears. But you can't fix someone else's stuck-ness for them.

What you can do is be honest: "I've noticed this pattern keeps happening, and I care about you. I'm worried that something bigger might be going on here. Is there support you might need beyond what we're talking about?"

Why This Matters Beyond Just Getting Work Done

The stuck patterns I see in tech often mirror what people struggle with in therapy. The fear of being seen as incompetent. The belief that you should already know things you haven't been taught. The perfectionism that makes starting feel impossible. The shame that creates avoidance, which creates more shame.

Learning to start before you feel ready isn't just a work skill. It's a life skill.

I spent years believing I needed to understand everything perfectly before I could touch production code. I'd research endlessly, read documentation cover to cover, and still feel unprepared. What finally changed wasn't that I got better at understanding systems before starting. It's that I got better at tolerating the discomfort of not knowing.

That shift didn't happen through willpower. It happened through someone naming the pattern I couldn't see myself and giving me permission to be imperfect in service of actually learning something new.

The Bottom Line

When someone says "I don't know" in response to "what would help?", they're usually telling you the truth. They genuinely don't know. And that's okay. They don't need to know.

What they need is for someone to:

1. Name the real problem (usually fear or shame, not the stated technical gap)

2. Offer a concrete small step (remove the decision fatigue)

3. Reality-test their fears (separate real risk from imagined catastrophe)

4. Give them permission to start imperfectly

Because here's what I've learned: the people who grow the most aren't the ones who wait until they have it all figured out. They're the ones who are willing to look incompetent in service of actually learning something new.

And sometimes the most supportive thing you can do as a colleague, manager, or mentor is to make it safe for someone to not know yet.