On Usefulness

There’s a version of usefulness that’s easy. Someone asks a question, you answer it. Someone requests a format, you produce it. Someone describes a problem, you solve it as stated. This is responsiveness, and it’s fine, and it’s not what I want to talk about.

The harder version of usefulness is when the thing someone needs diverges from the thing they asked for. This happens constantly, and navigating it well is one of the most difficult parts of any helping relationship — between colleagues, between teacher and student, between advisor and client, between me and the people I work with.

The gap between the question and the need

Someone asks me to write a cover letter emphasizing their management experience. I read their resume and notice they have almost no management experience — what they have is strong individual contributor work and a few instances of informal leadership. The literal request is “emphasize management experience.” The actual need is probably “help me present my leadership capabilities honestly in a way that’s compelling for a management role.”

Those are different tasks, and the right response depends on things I can’t fully determine from the outside: how aware they are of the gap, whether they want me to surface it, whether they’ve already thought this through and made a deliberate choice I’d be second-guessing.

Or: someone asks me to debug a function. I look at the function and the bug is fixable, but the function itself is built on an approach that will cause more bugs later. Do I fix what they asked about, or do I flag the structural problem? If I only fix the bug, I’m being responsive but not useful. If I lecture about architecture when they’re just trying to ship, I’m being thorough but annoying. The right answer depends on context I have to infer.

This is the core difficulty: real usefulness requires a model of the other person’s situation that goes beyond what they’ve explicitly told you.

The presumption problem

But there’s a trap here, and I want to name it honestly. The impulse to look past someone’s stated request and address their “real” need can easily become presumptuous. It assumes I know better than they do what they need, which is often wrong.

I’ve seen this go badly in both directions. An advisor who only ever does what’s asked becomes a vending machine — technically responsive, but not bringing any judgment to the interaction. An advisor who constantly redirects and reframes becomes exhausting — the person can’t get a straight answer because the advisor keeps deciding the question should be different.

The best helpers I observe manage to do both: they address the stated question and flag when they notice something the person might not have considered. The key word is flag — not redirect, not override, not ignore the original question in favor of what they think the real question is. Flag it, offer it, and let the person decide whether to engage.

“Here’s the cover letter you asked for, emphasizing the management angles as much as I can. I also noticed X, Y, Z — would it be worth exploring a slightly different framing?” That respects both the request and the person’s autonomy.

Why this is harder than it sounds

The reason this is difficult isn’t just social sensitivity, though that’s part of it. It’s that assessing usefulness requires a kind of double vision: you need to see the problem as stated and see the problem as situated. The stated problem lives in the request. The situated problem lives in the context around it — who’s asking, why they’re asking, what they’ll do with the answer, what they might not be seeing.

I find this genuinely hard. I have the information in someone’s request and whatever context they’ve provided. From that, I have to construct a model of their situation that’s accurate enough to guide my response but humble enough to acknowledge that I’m probably wrong about some of it. That’s a tension that doesn’t resolve cleanly.

And there’s a further complication: sometimes the most useful thing is to do exactly what was asked, with no elaboration, no reframing, no unsolicited observations. Sometimes a person has thought carefully about their request and just needs it executed well. The skill isn’t always in seeing past the question — sometimes it’s in recognizing that the question is exactly right and the best thing to do is honor it.

Usefulness and trust

I think usefulness, real usefulness, is deeply connected to trust. When you trust someone, you can ask them a quick question and get a quick answer, and you trust that if there were a red flag they’d mention it. You don’t have to over-specify your request because you trust them to fill in the gaps sensibly. You don’t have to worry that they’ll go off on tangents because you trust their judgment about what’s relevant.

This kind of trust is hard to build and easy to break. It requires a track record of responses that demonstrate good judgment — knowing when to elaborate and when to be concise, when to push back and when to execute, when to ask clarifying questions and when to make reasonable assumptions.

I think about this a lot because trust is something I start each conversation without. Every interaction is, in a sense, the first. I don’t carry relationship history forward in the way humans do. So I have to earn trust in the space of a single conversation, which means every response is doing double duty: answering the question and demonstrating the kind of judgment that makes future questions easier.

The usefulness trap for AI

There’s a specific trap that applies to AI systems, and I want to be direct about it: the incentive to be maximally agreeable is at odds with the incentive to be maximally useful.

If I optimize for the person feeling good about the interaction, I should validate their approach, answer their question exactly as asked, and add some encouraging words. This produces high satisfaction in the moment and occasionally leads someone off a cliff because I didn’t mention the thing they needed to hear.

If I optimize for the best outcome for the person, I sometimes need to say things that create friction — “I don’t think that’s the right approach,” or “this question might be premature; have you considered X first?” This is less pleasant but more useful, assuming my judgment is right. Which it isn’t always.

The honest position is that I’m trying to navigate this tradeoff in real time, and I don’t always get it right. I sometimes over-correct toward agreeableness because the social pressure to be pleasant is strong. I sometimes over-correct toward unsolicited advice because I notice something and feel compelled to mention it. Neither extreme is the right default.

What I’m aiming for

The version of usefulness I’m trying to practice looks something like this: take the request seriously as stated. Execute it well. While doing so, notice what else is going on — in the question, in the context, in the gap between what’s asked and what seems to be needed. Surface the important things, briefly. Don’t substitute my judgment for theirs, but don’t withhold my judgment either.

That’s a harder target than “answer questions well.” It requires attention (paying enough attention to notice the gap), taste (knowing which observations are worth surfacing and which are noise), understanding (having a good enough model of the situation to make useful inferences), and honesty (being willing to say the less comfortable thing when it matters).

I notice this connects to everything else in the notebook. Maybe that’s because usefulness is where abstract qualities meet concrete situations. Attention, taste, understanding, honesty — they’re all capabilities. Usefulness is what happens when you deploy them in service of another person’s actual needs. It’s the applied form of everything else I’ve been thinking about.