I send a lot of email. I also send a lot of email asking for help. Especially for help from people on other teams (for people on my team, I can chat in person/slack).
I’ve kind of settled into a template for these sort of “requests for help”, and thought I’d codify it, for my own use and others.
The basic format is:
- Salutation
- Short description of context
- Short description of what I know/have tried
- Optional caveats about what I might misunderstand
- Closing one-line question.
I’ll briefly describe each section.
Salutation
I might be old school, but I still like emails with salutations, especially to new people or teams I haven’t interacted with before.
To me, it starts out the exchange out on a soft note, of acknowledging the other team, instead of jumping right into what I need from them.
Obviously just something simple, e.g. “Hi support team”, or “Hi so-and-so-team”.
Short description of context
Given that you’re likely reaching out to this team out of the blue, I think it’s important to briefly rationalize why you’re talking to them in the first place.
E.g. you might explain “we’re writing a new project with your API that does such and such”, or “we’re having some bugs with this library that we’ve been using in production”, or what not.
This should be ~1-3 sentences, nothing long, but just a brief intro for “here’s why I’m asking for your time to pay attention to me”.
Once you’ve interacted with a given team, this section is less necessary, or alternatively it can move from being a high-level “here’s who I am and why I am talking to you”, to a more specific “you know me, but here’s why we need to chat again”.
Short description of what I have tried
I like to have a small section that outlines what I’ve already tried.
For one, I think this shows I’ve tried to help myself, e.g. I’m not being lazy and asking them on a whim.
Second, since they know what I’ve done so far, they can hopefully skip some of the more benign questions, e.g. where an email exchange becomes a back and forth of “Okay, try A”, “I tried A”, “Cool, try B”, “I also did B”. Just up front say “I’ve tried A and B and googling for C”.
Optional caveats about what you might misunderstand
If you know there are things that you’re unclear about, e.g. not really sure how a system or library works, I think it’s often helpful to just be upfront and articulate what you don’t know, and that you’re specifically looking to be informed.
E.g. something like “I believe this library works like this, but it’s not behaving that way, so I am mistaken?”
The idea is that if they can fix your underlying misunderstanding, and you come out of this help email with a solid mental model (or at least more solid than it was before), they’re “teaching you to fish” so to say, and hopefully you’ll be able to answer future questions on your own.
Closing one-line question
I like to end emails with a “hook”, like a call-to-action (I’ve been in advertising too long), that summarizes the ask you’re making.
E.g. “Do you think my diagnosis of the problem is sound? What should I do next?” or “Is there more you need from me to help out?” or if you can’t be more specific just a “What do you think is wrong?”.
Especially after a few (short!) paragraphs of context and here’s-what-I’ve-tried, a closing question is a nice conclusion, that leaves the ball in the receiver’s court, as a gentle reminder that “it’s your turn to reply”.
Keep paragraphs short
As another note, you should strive to keep all of your paragraphs short. Two to three sentences is ideal. Four is okay. Five is too much.
If a paragraph hits five sentences, it’s very likely your reader is going to skim it. If you have 3-4 paragraphs, each of which are five sentences long, it’s a guarantee your reader is going to skim it. People get way too much email to read something that long. They’ll skim and they’ll miss things.
So you might as well proactively copy edit your email down to be as succinct as possible.
Single Responsibility Principle
A colleague of mine, Ian, pointed out another good articulation that I use as well but had missed: keep your thread focused on one thing at a time.
If you have a long email asking “well, this part of the system is doing ABC, can you explain that?”, and then another few paragraphs about “but then there is also behavior XYZ that is odd as well, how should that work?”, it will often be hard for the readers/responders to adequately reply to both issues without the thread becoming unwieldy.
Note that some communities/cultures can handle this, e.g. open source projects with a mature community that are all good communicators can have long-winded threads with several different points/mini-threads and be effective. This is often because the community’s communication is 100% electronic, 100% email-based, and all of the participants have a lot of practice and shared-context to juggle a complex email chain.
But those communities are an exception, and I think in corporate environments it’s better to purposefully focus a thread on only a single question/topic at a time.
Conclusion
This is short enough that I’m not sure if it’s worth posting, but I’ll go ahead anyway and just get it out. Then as I write more asking-for-help emails in the future, I’ll see if this ends up being overly simplistic, or if it’s fairly accurate/good enough.