Tips for asking people for things

By Ben Kuhn @ 2022-04-05T20:30 (+135)

I recently attended EAGxBoston, which was the first EA conference I attended since my employer, Wave, became reasonably high-profile. As a result, quite a few people were interested in talking to me.

Mostly this was awesome! I got to have a lot of fun conversations with people who asked great questions. However, there were a couple recurring patterns where I think people would have gotten more out of it if they'd taken a slightly different approach to our interaction. I thought I'd write them up in case they're useful to future conference attendees.

At a high level, the problem is that I got enough requests to do stuff that I could have packed essentially all my free time with them. But I wanted to maintain a lot of unscheduled slack time for serendipitous conversations etc., so when people asked me for something (e.g. to "chat"), I tried to triage these requests based on how much I thought it would improve the world if I did them. Unfortunately, most requests I got didn't include enough details for me to figure out how good of a use of time they would be, and so I just declined them.

Although the advice in this post is motivated by the fact that I got lots of requests and had to triage, I think these practices are the right way to ask anyone for things, regardless of how busy they are. Even if the person you're asking isn't overwhelmed, they'll still be able to be more helpful to you, and use their time better, if you do the following:

When asking for something, make a case that it's worth doing

Mostly, I was using "how interesting does this project/person seem based on their message" as a proxy for how useful it would be for us to talk. Some things that I think are interesting:

• Having done interesting work (could be demonstrated by e.g. linking to an interesting blog post or a writeup of a past project that went well)
• Having passed a selective application process (e.g. working for an EA org)
• Being referred by someone trustworthy (e.g. "<person> said I should talk to you")

Some examples of messages that didn't give me enough to go on:

• "<person you don't really know> suggested I meet with you. I'm interested in <topic>. When would you be free tomorrow?" (hard to tell what the person expects to get out of it; I didn't know the referrer well so the endorsement didn't work)
• "<nationality> <profession>. If interested & possible, email me with that subject line and I'll send you stuff to help <profession>s in distress" (no info about the project, potential effectiveness, why someone would want to do it, etc.)
• "I'm a <profession>. Do you have 15 minutes to give me some career advice" (no info about what kind of advice, how it would help the author, why they're good to help)

[If you're one of the people who wrote these messages, please don't take this personally! I don't think you're an inherently uninteresting person—only that you didn't give me enough info for me to triage your request for a chat appropriately!]

If asking to talk, specify the topic and context as concretely as you can

A particularly important special case of the above: for many requests/meeting invitations, it was really hard for me to triage them because they included only a very vague topic, or none at all, in the invitation. In fact, some people sent meeting invitations without any text message at all as far as I could tell, although this happened so often that I'm wondering if it was an issue with the conference app UI.

For an example of what a good request to chat looks like, here's one I wrote to someone who's given me a lot of engineering advice recently that I think worked pretty well:

Hey Alex! Thanks again so much for the intro to <your friend> a while ago—talking to both of you saved us from pursuing some pretty bad database scaling ideas, so it helped a ton! I'm reaching out again because I have a new exciting problem that I expect you'd have a lot of useful advice on:

We now have enough eng teams that we need an intermediate management layer between me and the team leads. I'd love to know a bit about what you've found to be the most important traits for people to be effective at the director [manager-of-managers] level. [emphasis added]

Do you have some time next week to chat about this? My calendar is quite open after 10 Pacific time any day of the week!

Context: [emphasis added] I'm looking to hire up to three director-level people for different groups—one "platform" group focused on infra + eng-facing tooling, as well as two product engineering groups (one for user-facing product and one for internal products). I wrote up a job description here (link) although the current one is vague and doesn't have detail about the specific group someone would be director of.

Note that this includes (a) a specific, concrete topic, plus (b) a blurb with more detailed context at the end of the email. This helped Alex in a few ways:

• It helped him be confident that he'd be able to say useful things and add value during the meeting
• It suggested that I would come prepared and ask him questions he could easily answer well (see next section)
• It also probably helped him think about my question in the background before we talked, so he was better prepared with his own thoughts when we had our call.

Ask questions that are easy to answer

Related to the above, a lot of people involved in startups asked me a variant of "what are your best tips for how to run a startup?" Unfortunately, my reaction to questions like this is usually to stammer, freeze, and panic.

That's because all generic startup advice is essentially a vague platitude at this point ("build something that people want," "don't fuck up the culture"). When I get this question, I want to say something that isn't just a vague platitude, but once we get into specifics, there are about a zillion different things you have to do well to run a startup, and different people are good/bad at different ones (and which ones are important depends a lot on the particular type of startup you're running) so I have no idea which one(s) will be useful to whoever asked this question. (This example is about startups but it applies to any type of similarly broad question.) To give advice that isn't a vague platitude I'd need a lot more context and specifics.

Another to avoid doing this is that asking a vague question like this is making me do most of the effort to make the conversation useful. That takes a lot of mental energy, which I often don't have after hours of talking at a conference. It's also the type of question where most possible answers are boring or disappointing (because the listener has heard them before), which makes the conversation more stressful for me since I want to meet the expectations of the person I'm talking to (which are probably high given that they asked me for advice!).

Generally, questions are easier to answer the more concrete they are, and the closer to "tell me about the past / your experience" rather than "tell me what to do." Some categories of easy questions that can be very useful:

• How does <activity/process> work at your organization?
• What were the most important factors behind <project> going well or badly?
• What stood out or surprised you about <thing you did>?
• I'm choosing between these two things. What would you say the major trade-offs are? (Or: here's what I think the trade-offs are, would you add or change anything?)

For example, when I asked Alex for advice, the questions I asked were:

• When you were interviewing directors, what interviews did you find to give the most signal?
• Do you have any heuristics for how to group teams under directors?
  • Here's my planned split; does it set off any red flags?
  • I'm unsure where a "frontend infrastructure" team would go. Where would you put it?
• Here's a list of 7 potential interviews we're thinking of running. Which seem like the most/least likely to be useful? Does anything leap to mind as needing to be added or changed?
• When you’ve participated in Director hiring, what stood out / surprised you about the process?

If I were improving these questions further, I'd try to propose several different team splits and get Alex's take on which one seemed best, and similarly for the frontend infrastructure team question.

Be concise

Try to limit your initial message to a few paragraphs max. I'm putting this last because it wasn't a huge problem at EAGx in particular, but I sometimes get cold emails that are upwards of 10 paragraphs long. That's too long to triage or respond effectively.

When I'm reading email, I often have a large stack to get through, and if I acted on every email immediately, I'd never get through them all. As a result, I usually give myself less than 2 minutes to decide what to do about any given email. A 10-paragraph email takes longer than that just to read, let alone think about and decide what to do. It also makes me think that the sender probably isn't good at figuring out what information is or isn't important for other people to know, which makes me pessimistic about whether we'll communicate well if we have a conversation.

Conclusion

I'm a little worried that this will come off as entitled or as a status move. Please don't take it that way! I would love to have the time and energy to have a 30-minute chat with everyone who asks for one (and I used to do that!), but unfortunately if I did that at a conference the scale of EAGx, I'd end the day with my brain dribbling out my ears :(

Thank you for reading and helping your fellow conference-goers keep their brains where they belong!

Further reading

• Sriram Krishnan's cold email advice