How to solve cross-department communication problems: establish information sharing and escalation
When work stalls between departments, first locate the gap. Did the information fail to reach the people who need it? Did they receive it but understand it differently? Or does everyone understand the problem while nobody involved can make the necessary decision? Another reminder can help with the first situation. It cannot clarify an ambiguous deliverable or grant permission to change a commitment. Start with one piece of shared work. Keep its current record in the place your team already uses, describe what changed and who is affected, and name the response you need. If the unresolved choice exceeds the participants’ authority, take that same explanation through the established escalation route. This is a workable starting point before adding meetings or software.
Find the break after “I already sent it”
Consider an illustrative example: a design team moves the delivery of event artwork from Wednesday to Thursday. Operations continues planning its review for Wednesday because the update appeared only in the design channel. The immediate problem is distribution. Send the change to the people whose work depends on it, with a link to the current record.
Now suppose operations saw the message but thought “finished” meant approved artwork, while design meant a first draft. The delivery definition needs clarification. In a third version, both teams know the change leaves too little review time, but neither can move the event. That is a decision problem. Calling all three situations uncooperative behaviour makes the next conversation harder without identifying an action.
Review a real delay with the same questions. Look at the actual message, intended recipient, promised deliverable and outstanding decision. Separate what the record shows from what you assume about someone’s motives.
Keep the current conclusion in one accessible place
Use the existing project document or task to show the deliverable, agreed date, responsible person and dependency. When something changes, describe the difference: “Approved images move from Wednesday to Thursday. Copy is unchanged. Operations now has one fewer day for review.” This gives the next person something they can act on without reconstructing the history.
A chat thread can alert people, and a short conversation can resolve uncertainty. Write the resulting conclusion back into the shared record. GitLab’s public communication handbook describes documenting offline conclusions; its practice offers a useful example of keeping decisions retrievable. Your organisation’s own access rules still determine who can see the material. A shared record does not mean a publicly accessible document.
Ask for the response the work actually needs
Some recipients only need an update. Others need to confirm a revised commitment. A decision owner may need to choose between alternatives. Copying everyone into “please note and support” leaves those different responsibilities unclear.
Make the request specific: “Please confirm whether receiving approved images on Thursday still allows review to finish Friday morning. If not, identify the missing time or input.” Set a response time from the downstream dependency and allow for working hours. An acknowledgement from every recipient is unnecessary when nobody needs to change their work.
Atlassian’s stakeholder communication guidance distinguishes contributors from people affected by the work, then considers information, channels and update frequency. Apply that distinction to the project in front of you. A recurring update is useful when circumstances keep changing; a stable dependency may only require notification when its agreed conditions change.
Escalate a choice that requires authority
When the conflict cannot be resolved within the teams’ authority, check the established route. Provide the relevant decision owner with the problem, verified constraints, feasible alternatives and consequences. Keeping the event date with fewer initial assets and keeping all assets with a later event are different choices. Describe the trade-offs without presenting your preferred choice as the only possible answer.
Tell the other team you are escalating and preserve any disagreement accurately. Atlassian’s clean escalation guidance recommends understanding the options and informing the other party before involving a relevant decision-maker. Follow your project’s own timing and impact rules; an external playbook’s suggested duration is not a universal waiting period.
Close the loop where execution happens
After the decision, update the original record with the chosen arrangement, decision owner, execution owner and effective time. Notify affected people and clearly retire the old arrangement. “Seen” confirms receipt; it does not automatically mean someone has accepted a new deliverable.
At the next checkpoint, ask whether the actual break has disappeared. Can people find the current information? Do they know what response is required? Did the decision reach the appropriate person, and has work begun under the revised arrangement? If a clear update and one necessary discussion achieve that, keep the process that small.