To increase the efficiency of any business, it’s enough…

In almost every company I worked for or consulted, there was the same communication problem. This problem increases communication costs, leads to mistakes in decisions, and, honestly, annoys employees because of wasted time.

The Core Problem

The problem is the lack of complete information in the initial messages, presented in a digestible form. Almost any correspondence starts with task setting or reporting problems. And then it either turns into a call or continues until all the inputs are clarified, one by one. In chats, the situation only gets worse — they’re informal and fast. So why bother?

Why Does This Happen?

  1. We always do what is easier. This is neither good nor bad, it’s just how we save the energy our brains spend.
  2. We assume that what we know is known by everyone around us. Well, of course, except for our brilliant ideas and unique experience.

Examples of Incorrect Communication

  • The eternal classic: “Hi” ▸ What it should be: Something meaningful, not something that makes you just sit and wait for the next message.

  • Request without details: “We want to build a new Foo service for the Bar project. What would you recommend as its database?”
    ▸ What it should be: A project description, the team’s experience, or just a calendar link if this is a meeting invite.

  • Incident report without details: “We have problems with the baz.com website!”
    ▸ What it should be: How does the problem manifest? How many users are affected? When did the first reports appear? The URL of the error page? Is the incident open?

  • Task without context: “I’m busy with ticket JOB-1234. I need your help.”
    ▸ What it should be: A link to the ticket with a title that automatically pulls in the description and name. And a description of the problem or what is expected from me.

  • Incomplete task description: “Please check the sales report.”
    ▸ What it should be: Which specific points in the report require attention? Which time periods or data should be considered?

  • Decisions without reasons: “We need to upgrade kubernetes.”
    ▸ What it should be: Why?

  • Vague problem: “We have a delay with project Z.”
    ▸ What it should be: And what actions are expected from me? Sympathy?

Solving the Problem

The fewer actions and brain cycles the reader has to spend, the more likely they are to respond. So if you want someone to do something, give them all the necessary data and tools.

I usually solve this by running trainings with examples and introducing a framework like SCR (Situation-Complication-Resolution) for tasks, and a framework for error messages (anything: 5W1H, REACT, something of your own). In the end, it’s also beneficial for the person writing the message that the task gets resolved as fast as possible. And this is an important skill that will definitely be useful in everyday life too.

SCR sets the frame you have to fit a task statement into and nudges the “writer” to at least think about the necessary details from the start, which saves time and improves understanding.

It breaks a task description into three parts:

  1. Situation (Situation): Describe the current situation or project context. This helps understand where we are right now and what conditions need to be considered.

    Example: “Our current project to build a task management service is in beta testing. We received feedback from the first group of users.”

  2. Complication (Complication): Identify the problem or challenge you faced. This helps understand which problems need to be solved.

    Example: “The feedback showed that the system often freezes when adding new tasks. This has already caused dissatisfaction among 30% of testers and slowed down the testing process.”