I Don’t Want Your Brain Dump

Do you have some information to share with me? Great. I have 15 minutes. And, to be transparent, if we’re not to a point where I understand what feedback or action you want by minute five, you’ve probably lost me. Does that sound familiar? I bet it does, either because someone has been direct enough to state that explicitly or because you’ve experienced it. The ability to synthesize information and tailor its delivery to suit the audience is critically important.

Maybe that’s obvious in situations like making presentations to leadership or writing a resume, but it is also important in other smaller interactions where that investment may get overlooked. Organizing your thoughts matters, and an unrefined brain dump is rarely the best way to share information.

Why spend the effort?

When you share raw, unprocessed notes or thoughts with someone, you’re requiring them to do more synthesis of their own. That takes time and energy. You’re making them work for it. If you can do that work ahead of time, more of the information consumer’s time can be spent reaching the decision, feedback, or action you need. Furthermore, well-synthesized notes or information can:

  • Untangle topics and help conversations focus on the right things
  • Make conclusions clear and explicit
  • Show respect, that you value the recipients’ time
  • Help you communicate clearly and get what you need

When is it okay to brain dump?

It might be fine to drop raw notes to someone in some situations. For example, if you were just in a meeting with a small group of people and recorded notes for the group, sharing those raw notes with the meeting attendees is appropriate. Or if you’re extremely time-limited and need to share critical information with someone who needs it, by all means, give them what you can. In almost all other situations, refining notes and information will improve your chances of achieving your goals.

When is it especially necessary to synthesize information?

Information synthesis is almost always helpful, but there are situations where it is especially necessary. Synthesize when:

  • The consumers of the information have less context than the author. The synthesis should aim to reduce the need for context or include the necessary context.
  • Information consumers are going to invest limited time with the content. For example, you send in a resume, knowing that the hiring manager will have at most a few minutes to make an initial judgment on fit for their job opening. Or you schedule a 30-minute meeting with your busy department manager to discuss a proposal.
  • It is expected. This includes presentations, formal documents, part of a defined process, etc.
  • The information is going to live for a long time. Some examples are documentation of a software system’s features, project agreements, and proposals, final project deliverables, etc.
  • Someone needs to draw a conclusion and take action. For example, do this when you’re asking for help with a decision about a product feature.
  • The information is complex (deep, broad, or both). For example, do this when you’re recording business requirements for a financial system with complex, precise calculations and a broad web of ripple effects.

How do I do it?

Let’s look at a few simple practices to make it quick and easy to put those synthesis muscles to work and produce information that is clear and helpful.

Focus on the most important information.

Especially when you’ll have limited time or engagement from the recipient. Lead with an executive summary or tl;dr that isn’t more than a couple of sentences or bullet points and helps someone quickly understand the purpose of the communication. Include more information in later sections.

Use templates for structure.

Having a few go-to templates can make information synthesis fast and painless, and bring some structure and clarity to your thoughts. They don’t have to be complicated. For example, our team has templates for types of information we record regularly, our Request for Comments (RFC) documents, and stories. I often make a list of options with positive and negative attributes for each option. Here are a couple of specific template outline examples.

Feature Story Template

  • Goal
  • Requirements
  • Design
  • Implementation hypothesis

Bug Story Template

  • The Problem
  • Desired Behavior
  • Implementation Hypothesis

Request for Comments (RFC) or Decision-Making Template

  • Background
  • Goals
  • Options
    • Pros / Cons
    • Benefits / Costs
    • Expected challenges & risks
  • Recommendation
  • Comments

Request for Help Template

  • Brief problem description
  • What I need
  • How it helps
  • More background

Keep independent topics independent

Create separation between separate topics. Use separate documents, separate headings, or separate discussion times to help avoid conflating or confusing the different topics.

Make it visual

Sometimes a picture really is worth a thousand words. Diagrams, charts, and graphs can communicate volumes and don’t have to take a lot of time to create. Don’t underestimate the value of a collaborative whiteboard drawing session, especially if you’re prepared with a diagram in mind at the start.

Separate the raw notes

If you are going to share raw notes along with more refined information, make sure the separation between the two is clear.

How do you do it?

These are some tools that I use to help myself synthesize information and share it with my team. What strategies or tools do you use to avoid dropping a burdensome brain dump? Let me know in the comments.

 
Conversation
  • Sepp says:

    Bug report template:
    – What did the user do?
    – What did the user expect to happen?
    – What happened instead?
    – Workaround (if known)
    – Context
    – when, where, how often, at which machine, software version, OS version, …?
    – Research (if done by user):
    – Application log files, OS log files
    – Minimal code example (for bugs in APIs, libraries, …) or test case
    – Debugging session log

    Request for improvement template:
    – Status quo
    Example: “When the user does …, main screen shows error message …”
    – Possible improvements

    • Jason Porritt Jason Porritt says:

      Thanks for sharing those templates, Sepp. I especially like the prompt to capture the workaround for a bug. That’s helpful information to have when prioritizing work and advising support teams.

  • Comments are closed.