Skip to content
Institute of Technical Leadership
All blog posts

Leading People

Mentoring Is Not Answering Questions. It's Refusing To.

Principal Architect · 2 June 2026 · 5 min read

The single most useful thing I've ever done as a mentor was say "I don't know, what would you do?" while knowing full well what I'd do. It felt like cheating. It was the only time that year I actually taught anybody anything.

Answering is the fun bit, which is exactly why it's suspicious

Somebody comes to you with a problem you solved four years ago. You know the answer. You can hear yourself giving it, and you sound good, and they write it down, and everyone leaves the conversation feeling that a useful thing just happened.

Check who that conversation served. You got fifteen minutes of being the person who knows. They got an instruction they can't defend, because they don't hold the reasoning behind it. Next time a similar problem turns up with slightly different edges, they can't adapt it. So they come back. And the fact that they keep coming back feels like evidence you're a good mentor, when it's the opposite.

There's a harsher version of this that I've been guilty of. Answering fast is how you get out of a conversation. It's efficient. You've got a deployment window at four and a meeting you're already late for, so you give them the answer, feel briefly generous, and move on. That's not mentoring. That's dispatch.

Hand the question back, but hand it back with scaffolding

Refusing to answer is only useful if you replace the answer with something. "What do you think?" on its own is lazy, and when it's your only move people learn to stop asking you things.

What works is narrowing the question until they can get a grip on it.

Someone asks whether they should rebuild the reporting service or patch it again. Instead of telling them, ask: what breaks if you patch it and it's still here in two years? Who pays for the rebuild, and what do they lose while it's happening? What would you need to see to be confident either way, and how would you go and get it this week?

Now they've got a shape. They'll come back with an answer, and it might not be the one you'd have given, and this is the part where you have to be honest with yourself. If their answer is defensible and merely different from yours, let it run. Overruling a reasonable decision because it isn't your reasonable decision is the fastest way to teach someone that asking you is just a slower route to being told.

I usually add a deadline to the handback, because a question without a date attached drifts. "Come back to me Thursday with what you'd do and why." Thursday matters. It turns a conversation into a piece of work.

When you should just answer, quickly, with no Socratic nonsense

There's a version of this advice that turns people into infuriating coaches who answer every question with a question while the building burns. Don't be that.

Answer straight when the cost of a wrong turn is real and irreversible. Answer straight in an incident, every time, because two in the morning is not a development opportunity and you can do the teaching in the review. Answer straight when it's information rather than judgement: which team owns that service, where the runbook lives, who signs off spend over a certain amount. Making someone hunt down a phone number through pure enquiry just wastes their afternoon and yours.

And answer straight when they've already done the work. If someone has thought it through, weighed it up, and just wants a sanity check from someone who's been there, give them your view. Withholding it at that point is a performance.

The line I use: if they're stuck on what to think, hand it back. If they're stuck on what's true, tell them.

The mentors you need are not in your discipline

Most technical leaders collect mentors who look like a slightly older version of themselves. Another infrastructure person, another delivery lead, someone two rungs up the same ladder. It's comfortable and it's mostly useless, because they'll validate the way you already think. You'll come away from every session feeling reassured and not one bit different.

The conversations that moved me most were with people from nowhere near my field. A commercial manager who asked me, about six minutes into my explanation of a technically elegant proposal, who was actually going to pay for it and out of which budget. I didn't have an answer. I'd spent three weeks on the design and roughly zero minutes on that question, and the proposal died for exactly that reason two months later.

A GP once told me how she runs a ten minute consultation when the patient's real problem isn't the one they opened with. That reframed how I run difficult one to ones more than any leadership book has.

Go and find two people outside your lane. Someone commercial, someone who manages people at a scale you don't, someone in a regulated corner of the business who thinks about risk for a living. Ask for forty minutes a quarter. Most people say yes, because almost nobody asks them.

Monday morning

Take the next question that lands in your inbox from someone you're mentoring, the kind you could answer in one line. Don't answer it.

Reply with two things: the narrower version of the question they should actually be answering, and a day this week when you want their recommendation. Then keep that slot free, and when they bring it, ask what they'd need to change their own mind.

Principal Architect

Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.

This is the kind of thing we teach properly in Foundations of Technical Leadership.

Foundations of Technical Leadership is 25 self-paced lessons, with templates you can use the same week.