If you're an application admin responsible for managing a critical Atlassian product at your organization, you've likely spent countless hours perusing the technical documentation. 🔍
Atlassian, and most popular enterprise vendors, provide comprehensive guides for setting up, configuring, and optimizing your instance. There are tons of resources and services available to ensure your teams and end users get up and running quickly.
However, I've noticed a common gap in the planning for several organizations: the critical importance of a formalized corporate communication protocol around your Atlassian apps.
Emphasis and effort are often directed toward technical configuration, user training, and best practices. Yet, when something changes or breaks, the organization's communication plan is often nonexistent.
This lack of planning creates chaos when things change:
- ❓ What happens when Atlassian (or an integrated vendor) deploys a new feature that alters your app's configuration or UI?
- ❓ How do you respond when an app is offline or degraded due to a vendor incident?
- ❓ How do you succinctly inform your 10,000 users of something new?
- ❓ Who is responsible for sending the initial update, and who handles the flood of follow-up questions?
- ❓ How do you get notified in the first place, ensuring you know ahead of your users (if possible)?
These questions often become an emergency afterthought, leading to panic, confusion, and big uptick in unread notifications and ticket backlogs. But they don’t have to be.
A simple, high-impact exercise is to schedule a one-hour(ish) meeting with your core admin team. During this session, ask different members to present various scenarios where communication needs are unclear.
For each scenario, from "JSM is down" to "this Confluence feature will be deprecated," the discussion should drive toward clarifying the following critical elements:
- Trigger: What action or event "triggers" that communication to be sent?
- Responsibility: Who is responsible for drafting and sending the communication?
- Approval: What approvals, if any, must occur before the communication goes out?
- Content Format: What is the required format of the content (e.g., "Must be a brief email with a link to a Confluence page" or "A < 1000-character Slack message in a public channel")?
- Recipients: Who are the specific recipients of that communication (e.g., "All Jira users," "All space leads," etc)?
You can group similar scenarios that warrant the same communication approach to keep your documented operating procedures tight. And, it's perfectly acceptable if you don’t have all the answers in the first meeting. One of the primary goals of this exercise is to produce a clear list of action items for your team to divide and follow up on asynchronously.
Reconvening in a week or two will allow you to review the findings. Eventually, you will build a robust scenario library of different cases that require mass comms, ensuring your team knows exactly what to do and when.
This process effectively mitigates the panic that sets in during urgent situations when responsibility is ambiguous. It also has the added bonus of significantly improving the onboarding process for new members of your admin team.
While the ability to think on your feet and adapt is extremely valuable, having a proactive communication playbook that covers the scenarios you are most likely to encounter will improve your time to action, increase efficiency, and mitigate confusion and angst across your organization.
How does your team currently handle large communications related to the Atlassian applications you manage? Share what strategies have worked, or haven’t worked, for your organization. ✅
