I am a team lead, and I am starting to think that I have become poor at technical communication outside of my team. When explaining things to my superiors, or to offsite contractors, a particular scenario plays out again and again.

Imagine that I am explaining task G; A through F are prerequisite knowledge to complete G. I'll believe that A, B, C, and D go without saying, so I'll explain E and F and then G. If the listener is a contractor, what always seems to happen is that they'll then go off and prepare a presentation about C and D, because they had to spend some time figuring it out, and assume it's news to me. If the listener is a manager, the next time the topic rolls around they'll want G explained again, because they didn't actually understand the first time.

If G is a data entry task (a purely hypothetical example), A, B, C, and D would be basic information about data entry: perhaps A is "turn on the computer to use it," B is "the keyboard is for typing," C is "launch Excel by double-clicking the icon," and D is "click in a cell to edit it," while E and F would concern the actual data I needed to be entered. If I were to explain A and B, I am sure I'd insult the listener. But if I don't explain C and D, the listener doesn't always know what's up.

How do I do a better job of judging where to start explaining things without insulting the people I'm talking to?

  • 1
    "Stop me if I'm stating the obvious" then start with A. Commented Jul 17, 2020 at 14:12
  • Do you mention at all that you expect Excel to be used?
    – Kat
    Commented Jul 17, 2020 at 17:44
  • @Kat That is exactly the issue. That’s somewhere in the ABCD range. I feel like I’m providing all the needed background, but I might leave stuff like that out. I might assume “data entry” implies “Excel,” but other people might not realize that. Commented Jul 17, 2020 at 17:48

2 Answers 2


The strategy that has worked incredibly well for me is to create a hierarchy on what I'm reporting/relaying.

First, figure out a top-level organizational scheme for your message.

In other words, look for a way to organize your email in a way that you could summarize in a sentence or two. Some examples:

  • A few paragraphs of high-level detail, followed by a section on background notes, with a final section on some more in-depth technical details
  • Three main steps you need to do, a section for troubleshooting if those steps don't work, followed by some info on how to get help if you can't figure the steps out

For each of these main sections, put a sentence or two at the top indicating what the section is about. (That way, if someone wants/needs to skip it, they easily can without resorting to having to skim through it all.)

Second, look for ways of sub-dividing a section out.

As soon as a section looks a bit too long, figure out a way to subdivide it out further.

  • Indented sections, such as bulleted lists, make a great way of conveying info that is subordinate to the main message of the section

  • If you've got a single subordinate section, feel free to just indent it. This can visually let the reader know that the information applies to the un-indented item above it.

Third, make sure the main parts of the message are easily visible and flow.

  • Bolding works wonders.

  • Make sure the main items aren't in the middle of a sentence; ideally, they should be the only sentence on the paragraph

  • If the message is long enough, consider adding a TL;DR (too long, didn't read) that summarizes the main gist of the message.

Now, take a look at this (very meta) answer

Look how long it is, and how much information is in it. But... look at how the elements I talked about make it a lot easier to navigate and digest.

I had a main point: use hierarchy to organize your info; I had three main ways you could organize that data to achieve the main point; And I had detailed sub-info on each of those three main ways.


When explaining a task to someone, especially a complex one it's often helpful to include some written communication.

In a case like yours where (it seems) you're having a verbal conversation with someone it can be as simple as ending the conversation with "I'll send you an email with the details". Then you send an email including "background".

"Background" is where you cover (briefly or at length as appropriate) the information and assumptions which underlie the task at hand.

The written element (with background) is useful because

  1. It's traceable
  2. It can be referred to after the fact. Something will often make sense to a person during a conversation, but when they go away to think about it/do the task they'll be confused. A written record helps with that.
  3. It allows you to include as much detail as you want. The background section can be long, and a person can think "I've got this" and just skim it if they want, without feeling insulted. Then if it turns out they have questions, they can go back and reread the background more closely, without having to bother you or worry about losing face etc.
  • I agree with everything you say here — but unfortunately this currently happens to me with written communication too, and even PowerPoint presentations. My definition of “background” just sucks, regardless of the medium. Commented Jul 17, 2020 at 14:13
  • 1
    I usually think of background as beginning at the earliest non-trivial thing my company/group/whatever does. So in your data entry example if your company/group doesn't make computers (A) I wouldn't include that. If you company/group doesn't make Excel (B) that's out too. If someone in your group took a bunch of data (E) and then someone else wrote it in a ledger (F) both of those get mentioned as background (also serves to give credit to the people who did E and F). Now you move on to the task at hand (G)
    – Greg
    Commented Jul 17, 2020 at 14:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .