Communication tools for problem solving: how to align different roles quickly
Choose your communication tool by identifying what the group has not yet agreed on. If people describe different problems, start with a short problem brief. If they cannot see where work changes hands, draw the relevant steps. If the facts are understood but a choice is waiting, use a decision record with clear roles. A new application is optional; a useful shared explanation is essential. The aim is to help people with different responsibilities examine the same material. It is not to make everyone agree immediately. A good result may be a decision, but it may also be a precise unanswered question and an agreed way to investigate it.
Start with the gap, not the software
Imagine an events team discussing why some participants received two registration emails. Operations wants to change the mailing list, the technical team wants to inspect the registration form, and the coordinator wants to approve a message to participants. This is an illustrative situation, not a reported customer case. The three proposals address different parts of the work, so a bigger group chat would not by itself tell them which question to answer first.
Ask each person to describe the observed event and the decision they think is needed. Keep observations separate from explanations: two emails were received is an observation; the form created duplicate records is a hypothesis until someone checks. This distinction determines which material should come first. It also prevents a polished diagram from giving an unverified explanation the appearance of certainty.
Use a problem brief when the question is unclear
A short brief can state who was affected, what happened, what should have happened, the evidence available and what remains unknown. In the registration example, include the relevant dates and the number of cases actually checked, without inventing a total. Link to permitted internal records rather than copying participant details into a public document.
Atlassian’s Project Poster separates the problem space, validation and preparation for delivery. Its guidance also says that not every project needs a poster. Borrow the distinction between known information and assumptions; do not create an elaborate document for a question that a few clear sentences can settle. Ask someone outside the immediate task to explain the problem back in their own words. If their account is different, revise the brief before comparing solutions.
Draw only the handoffs that matter
When the uncertainty concerns sequence, sketch the path from registration to list creation to sending. Put the action and the responsible role next to each step. Mark where a record is added, copied or checked. Unknown steps should remain visibly unknown. The sketch is a working representation to review with the people who perform those actions, not proof of how the system behaves.
Use it to ask a concrete question: can both the first registration and a later edit trigger an email? The technical team can inspect that point while operations checks its own sending step. Avoid drawing the entire organisation. A diagram earns its place when it helps someone locate a missing handoff or identify the next useful check.
Use a decision record when a choice is ready
Once the relevant facts are available, stop expanding the problem brief and describe the decision. For example, the group may need to choose whether to pause a second mailing while checking the list. Record the options, the conditions each depends on, the people affected and the date by which a decision is needed. Do not list two alternatives merely to create the appearance of choice.
Atlassian’s DACI framework distinguishes the person driving the decision, the person making it, contributors and those who need the outcome. The framework does not grant authority that someone lacks. Check existing responsibilities first, and use those names rather than inventing a new approval layer. Someone can supply essential evidence without becoming the final decision maker.
Check whether the material worked
Finish by asking each role what it will do next and which question remains open. If everyone can point to the same evidence but still prefers a different option, the problem may now be a legitimate decision rather than a communication failure. Keep that distinction visible instead of rewriting the document until disagreement disappears.
GitLab’s communication handbook asks teams to write down the conclusions of offline conversations. Applied here, a short discussion should update the material people will use afterwards. Keep one current record with links to supporting detail. Remove a redundant sketch or table when it no longer helps the task. The best tool is the smallest one that lets the next person understand and act without reconstructing the discussion.