Mentoring with one question

Day 29: Refuse to Answer. Mentoring with One Question

You've just been asked to mentor someone, and you plan to be the fastest answer in the room. Drop that plan. Your mentee already has an agent that hands them plausible, often correct answers in seconds, so a fast answer is the one thing they don't need from you. What they need is a way of thinking that keeps working after you've left the chat.

The 11pm stack trace

A junior pastes a stack trace into Slack at 11pm. I know the answer within about four seconds of reading it, and I could type the fix in ten. Instead I send one line: "What changed between the last time this worked and now?"

Then I watch the typing indicator start, stop, and start again, and I feel guilty every single time. This lesson covers why I keep doing it anyway and how you can do it without being a jerk.

The confession: I was the fastest answer in the company

For two years as a founder-CTO I was proud of how helpful I was. I rewrote PRs when I should have reviewed them. I answered questions within seconds. I fixed things overnight so the team would wake up to green builds. I called that generosity. Here's what it actually got me:

• Every hard question came to me, because I was the quickest way to an answer.
• Nobody else could debug payments. They'd never had to, because I always got there first.
• A holiday meant a slower release.
• The team's skill stopped where mine did, and our shipping speed depended on how much I could get through in a day.

Being generous with what I knew is exactly what turned me into the bottleneck. The generosity didn't sit awkwardly next to the bottleneck. It caused it.

The junior I answered vs. the junior I questioned

The junior who got that one-line question at 11pm struggled for three days, and it wasn't fun to watch. In those three days they traced the config, read through the deploy history, found that someone had changed the payment webhook handler, and worked out why the retry logic mattered. Six months later, people were asking them about that part of the system instead of me.

• Junior I answered: unblocked in minutes. Came back with the next question in the same area. Saw the system as a list of fixes Chi Cong knows.
• Junior I questioned: unblocked in days. Came back with harder questions, then with none. Built their own picture of how the system fits together.
• What carried over: the first junior learned how to fix one bug. The second learned how to find bugs in that system.

The name I found later: the orchestrator that does the subtasks

Years later my PhD work on multi-agent systems gave me a name for this. Imagine an orchestrator agent that keeps solving its sub-agents' subtasks itself because that's quicker. In the short term the results come fast. But the sub-agents never learn their domain, every request has to pass through one node, and that node becomes a single point of failure. A strong engineer who starts mentoring makes the same mistake with people, and the fix is the same for both: delegate the work, spend your effort on the handoff, and let the sub-agent build its own competence.

Why this matters more in 2026

Your mentee already has Claude, Copilot or Cursor. It answers faster than you, it's awake at 11pm, and it never sighs. If your mentoring is mostly answering questions, something faster has already replaced it.

Left to itself, though, an agent won't ask the question that changes how someone sees the problem. It answers the prompt it was given. A junior who doesn't yet know what to ask gets confident answers to the wrong question. The human contribution is the reframe: "you're asking why this function throws, but the real question is what changed in the data it receives." Answers cost almost nothing now. Knowing what to ask is still rare.

The habit: One question, no answer

Here's the rule. When someone asks you something you could answer, reply with the one question you'd ask yourself if you were in their seat. Send that and nothing else: no hint, no link, no second question. These are the five I use most:

• What changed? When something that used to work breaks, a recent change is usually the cause. This teaches them to diff before they debug.
• What did you expect to see? This gets them to say their mental model out loud. Once it's spoken, the gap between what they expected and what happened usually points straight at the bug.
• What's the smallest thing you could check? A big, scary problem turns into one cheap experiment.
• Who else has touched this? Git blame, PR history and teammates all hold context. This question teaches them to go and get it.
• What would you tell the agent if it were wrong? Use this one when they paste an AI answer that doesn't work. They have to state a hypothesis and the evidence for it, which is the skill behind debugging and behind good prompting.

Junior (23:04): getting NullPointerException in PaymentWebhookHandler, stack trace below...

Not this:
  Me: It's the new retry config, set webhook.retry.enabled=true in staging.yaml

Not this either (a quiz, not a question):
  Me: What changed? Did you check the config? What about the deploy at 6pm? Is retry on?

This:
  Me: What changed between the last time this worked and now?

Then, once they've found it:
  Me: Nice. What made you look there first? Write that down.

The debrief is what makes the lesson stick. When you ask how they found it, one fix becomes a method they can use again.

Common pitfalls

• Asking a chain of questions. Five in a row is an interrogation. Ask one, then wait.
• Asking leading questions that are really answers. "Have you checked line 42 of staging.yaml?" is the answer wearing a question mark. Your question should point at how to think, not where to look.
• Using the question to look clever. If they walk away feeling stupid, they'll stop asking you. They'll ask the agent and skip the thinking.
• Asking and then disappearing. Check back in. People learn when they struggle with someone nearby who can catch them. When they struggle alone, they've been abandoned.
• Skipping the debrief. Without "what made you look there?", they've fixed one bug and can't tell you how.

When NOT to do it

• Production is down. Fix it now and do the teaching later in the postmortem. Customers shouldn't pay for your teaching moment.
• The person is drowning or burnt out. When someone has nothing left, struggling doesn't teach them anything. It breaks them. Give them the answer and protect their energy.
• The question is about access, politics or history they had no way of knowing: who owns this service, why a decision was made in 2023, which credentials they need. Just tell them. Making someone work out context they can't reach is gatekeeping, not teaching.

Refusing to answer is a way to teach, not a way to find out how tough someone is. Say so up front. Tell them what you're doing and why on day one, before the first 11pm message arrives:

"When you ask me something, I'll often reply with a question instead of the answer.
It's not because I'm busy or testing you. It's because you can get answers from Claude,
and what I can give you is the question I'd ask myself. If you're stuck for real,
or prod is down, say 'just tell me' and I will."

What it costs you

• It's slower this week. Three days instead of three minutes, and your sprint may feel it.
• It feels unkind, especially while you watch that typing indicator start and stop.
• You don't get to be the hero. People thank you for a fix. Nobody thanks you for a question.

This is where the series turns a corner. So far your growth has mostly been measured by what you can do yourself. From now on it's measured more and more by what other people can do because of you. "Just one question" is the first habit where you trade your own output for theirs.

This week's exercise

The next three times someone asks you something you could answer in under ten seconds, reply with one question instead. Log each one and bring your notes to Day 30.

| # | Their question (short) | My one question | What they did next | Time to resolve | Debrief: what made them look there? |
|---|------------------------|-----------------|--------------------|-----------------|-------------------------------------|
| 1 |                        |                 |                    |                 |                                     |
| 2 |                        |                 |                    |                 |                                     |
| 3 |                        |                 |                    |                 |                                     |

Extend your knowledge

• Read 'The Coaching Habit' by Michael Bungay Stanier. The book is built around a short list of questions, and 'And what else?' works well alongside the five above.
• Read the mentoring chapters of 'The Manager's Path' by Camille Fournier. They cover how mentoring changes as you move from engineer to lead.
• Read Anthropic's 'Building effective agents' post, especially the orchestrator-workers pattern. Compare how a good orchestrator delegates with how you delegate to people.
• Before Day 30, go back through your last ten Slack replies to juniors. Mark each one as an answer or a question, then rewrite two of the answers as one-question replies.