"Figure It Out" Is Not Coaching

I watched a junior engineer struggle for three days once.

He had been assigned a bug in a service he had never touched. His tech lead told him to "just dig into the code and figure it out."

That sounded reasonable.

By day two he was stuck.

By day three he wanted to ask for help but did not want to look incompetent.

I sat down with him for ten minutes. I did not fix the bug. I gave him a starting point: the file I would open first, why I would start there, and who originally knew the service well enough to explain the context.

He fixed the issue in two hours.

The problem was never his skill. The problem was that nobody gave him a map.

Autonomy Without Context Is Not Autonomy

Engineering leaders often confuse independence with abandonment.

They say:

"I do not want to spoon-feed."

"They need to learn how to navigate ambiguity."

"A senior engineer would figure this out."

There is truth in that. Engineers do need to build problem-solving muscle. They do need to learn how to handle incomplete information. They do need to become less dependent over time.

But context is not spoon-feeding.

Context is acceleration.

If someone is new to a system, a domain, a legacy decision, or an operational pattern, withholding context does not make them stronger. It makes them slower. Sometimes it makes them embarrassed. Often it teaches them that asking for help is unsafe.

That is a bad lesson.

Productive Struggle vs. Wasteful Struggle

Not all struggle is bad.

Some struggle builds muscle:

• Tracing a bug through a service boundary.
• Reading unfamiliar code and forming a hypothesis.
• Debugging a failing test with incomplete information.
• Writing a design and getting thoughtful pushback.
• Owning a small decision and learning from the result.

Some struggle just burns time:

• Searching for the right file when someone could have named it.
• Guessing the historical reason for an architecture decision.
• Rebuilding context that exists in someone else's head.
• Being afraid to ask for help because the team glorifies independence.
• Spending days on a problem where ten minutes of orientation would have changed everything.

Good mentors know the difference.

They do not remove all difficulty. They remove avoidable confusion so the engineer can spend energy on the part that actually teaches.

What a Starting Point Looks Like

A starting point is not the answer.

It is a way to make the first move less random.

Examples:

• "Start in this module. The naming is misleading, but this is where the behavior lives."
• "Before changing code, talk to Sarah. She handled the last incident in this area."
• "The bug probably crosses the billing and entitlement boundary. Trace the request there first."
• "There are two old paths in production. Make sure you know which one this customer uses."
• "This looks like a frontend issue, but the source of truth is the API response."

That kind of guidance preserves ownership. The engineer still has to investigate, reason, decide, implement, and verify.

But they are no longer wasting a day proving they can wander alone.

The Fear of Looking Incompetent

Junior engineers often do not ask for help at the right time.

That is not always their fault.

Teams teach people what questions are safe.

If senior engineers respond to questions with irritation, silence, or vague advice like "just read the code," people stop asking. They wait longer. They hide uncertainty. They present confidence before they have it.

That is dangerous.

The earlier someone surfaces confusion, the cheaper it is to fix. The later they surface it, the more likely it becomes rework, missed deadlines, or broken confidence.

A healthy team does not make asking for help feel like a confession. It makes it part of the work.

The Manager's Delegation Check

When you delegate work, ask yourself four questions:

1. Does this person understand the outcome?

Not just the task. The reason the work matters.

2. Do they know where to start?

If not, give them an entry point.

3. Do they know when to ask for help?

Set a timebox. "If you have no useful lead after two hours, bring me what you tried."

4. Do they know who has context?

Do not make them discover the informal ownership graph by accident.

These questions take minutes. They can save days.

A Better Phrase Than "Figure It Out"

Try this instead:

"Own the investigation. Here are the first two places I would look. If those are wrong, bring me what you find and we will update the map."

This gives ownership without abandonment.

It communicates trust without pretending context does not matter.

It also teaches a better debugging process: start with a hypothesis, inspect evidence, update the model, and escalate with useful information.

That is how engineers actually grow.

Senior Engineers Need This Too

This is not only about juniors.

Senior engineers also need context when entering a new domain.

The difference is that senior engineers are usually better at extracting it. They know who to ask. They know when the code is lying. They know how to distinguish local weirdness from systemic weirdness.

But even senior engineers are slower when context is hidden.

If your organization relies on "smart people will figure it out" as the default operating model, you will waste senior capacity too.

Documentation, ownership maps, decision records, and clear onboarding are not bureaucracy. They are leverage.

Coaching Is Designing Better Learning Loops

Good coaching does not mean giving answers.

It means designing the learning loop so the person gets stronger from the work.

That may mean asking questions instead of solving. It may mean giving a starting point. It may mean letting someone make a reversible mistake. It may mean stepping in before a mistake becomes expensive.

The skill is judgment.

Too much help creates dependency.

Too little help creates waste.

The right amount of help creates growth.

"Figure it out" is rarely that.

Most of the time, it is laziness dressed up as leadership.

Give people enough context to learn the right thing.

---

If you are trying to move from strong individual contributor to visible technical leader, your leverage is not only what you solve. It is how much better others become around you. The Engineering Visibility Score assessment can help you see whether that leverage is visible enough.