two birds standing on a bowl of water looking like they are talking

Getting unclear or vague instructions for a task, even a basic one, can be incredibly frustrating, time-consuming, and demotivating. For the more neurotic, it’s also a case of significant anxiety. Is it me? Am I an idiot?!

Often, I think, it points to the giver of the guidance being rushed and/or not considering exactly what the receiver of the guidance needs to know. And it is probably also related to the “curse of knowledge”, which suggests we’re bad at recognising what we know that others don’t. We can’t easily empathise with the other person’s level of knowledge about the situation and, therefore, explain things clearly. This can create a massive time drain for both parties. Being in this situation leaves the receiver of the information in a position where they may waste time trying to solve this problem, not wishing to ask questions, wondering about whether it’s just them who is being dim, then finally getting around to asking and having a confusing chat conversation, or emails, or something that doesn’t immediately clear up the situation.

Giving someone a task to do and providing the information required to do the tasks is known in many fields as “briefing”. A writer or a graphic designer receives a brief. If the brief is unclear the work produced may be entirely wrong so there are benefits to both parties when this is done effectively. Working in publishing, with writers and designers, provided me with a good grounding in what it means to create a “tight brief”.

“Give me the freedom of a tight brief”

David Ogilvy

Unfortunately, and frustratingly, I don’t think this is often focused on in a wider business context.

If you’ve worked with a graphic designer, you’ll know that they are notorious, with justification, for doing EXACTLY WHAT IT SAYS ON THE BRIEF, sometimes resulting in hilarious consequences.

“Nigel gave me a drawing that said 18 inches.”

Writing a good brief means trying to think carefully about all the information required by the other person, particularly when they are new to a project. Try to empathise with their situation: What do they need to know? What might they not know? Sometimes people are perhaps worried about coming across as condescending as if you think the other person is stupid. But it’s easy enough to list out a step-by-step process that captures the different stages in a way that just presents facts.

Despite all this, when briefing we might easily miss something or fail to explain well enough, so having a quick chat to confirm what’s required is also helpful. The other person can openly ask any questions that occur to them, making it less likely there will be a misunderstanding. The depth this chat needs depends on the nature of the task and how complex it is, as well as the experience and knowledge of the other person. If they are new to their role or doing something that might be a stretch for them, there’s a need to make sure they are supported and that they really do understand what to do. This may even involve prompting them to summarise what it is that they’ve understood, which is a good habit to get into anyway, to ensure understanding. It’s something I try to do as much as possible, by saying: “Let me just summarise that to make sure I’ve understood…”.

Here are a few points to tick off when briefing. Hopefully, I’m not forgetting anything important!

  • Why does the task need doing?
    • What is the context?
    • Where does it fit into the wider situation?
    • What other things depend on this being done?
  • What does the other person need in order to do the task?
    • Documents
    • Links
    • Input from other people
  • When does the task need doing?
    • When can/should it start?
    • Are there any waystages? When/What are they?
    • When is the final deadline?
  • How should the task be carried out?
    • Is there a specific or suggested process?
    • How should progress be reported? E.g. is there a need to change status on a project management tool like Asana or Airtable? If so, what, how and when? And should someone be tagged to be notified of that change?
  • What are the deliverables?
    • Document/Product format
    • Size/Length

This is just the sort of thing that we need a checklist for, as we’re often in too much of a rush to think through everything clearly. A checklist helps keep us on track.

Thanks for reading! If you’ve got any thoughts on this post, I’d love to read them. Let me know below.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.