Hey Jira Cloud Admins! Welcome back to our Change Management series, post 2.
In post 1, we covered why change management matters for admins, exploring how the pace of change has shifted from predictable cycles to a constant flow, and how Atlassian's tools help admins stay in control. This week, we’ll talk all about categorizing change, and offer principles for matching the right level of rigor to each type.
Making sense of the change you are dealing with
Not all changes are created equal, yet many organizations treat them as if they are. Before deciding how much process a change deserves, you need a way to describe it first. Two questions do most of that work: how much impact will this change have, and where did it come from?
Where is the change coming from?
Most admins focus on what is changing, but the most successful ones are aware of where it’s coming from, too. In an enterprise ecosystem, change hits you from multiple directions. If you don't know the source, you can't control the pace.
- Business-initiated change: Internal requests from your teams. You own the timeline, but you carry the burden of alignment.
- Vendor-initiated change: The platform itself is evolving. Atlassian feature delivery accelerated dramatically. You are no longer just managing your own configuration, but a living platform.
- Marketplace & Partner-initiated change: Third-party apps and partners have their own schedules. Without visibility, their improvements can become your next Friday night emergency.
What’s the impact?
Once you know where a change is coming from, the next question is “what does this change mean for my organization?”
Business-initiated change: A change initiated to address your business needs can have a varying degree of impact depending on a few factors.
- Reach: How many people, teams, or projects will be affected?
- Disruption: How much will people need to change the way they work?
- Dependencies: Does it touch shared workflows, integrations, permissions, or sensitive data?
- Reversibility: How easily could you return to the previous setup?
A configuration change or small workflow fix within one project may have a low impact, requiring only a quick check and a heads-up to the team. Adopting a new app across multiple teams, reorganizing instances after a merger, or redesigning shared workflows may have a high impact and require broader validation, coordination, and preparation.
Vendor-initiated change
Vendor updates can also vary in impact. A small improvement to a feature your teams rarely use may need little attention. A change to a heavily used workflow, permission model, or API may require testing, communication, or updates to your integrations.
PM Tip: For Atlassian updates, the AI-powered impact ratings in Release Notes show how Atlassian categorizes changes as Low, Medium, or High impact. Use these tags to prioritize your review, then assess the full release note against your organization’s setup and needs.
Why informal handling fails at scale
Small teams can manage change through "shoulder taps" and weekly syncs. At enterprise scale, that informality becomes a liability for three reasons:
- Volume: Reviews become a bottleneck long before they add meaningful risk control.
- Interdependence: In a complex environment, no configuration exists in a vacuum. A "simple" change in one project can have unforeseen ripple effects across the entire organization.
- Accountability: Regulated organizations need to prove who, what, where, and when a change was validated. Reconstructing this later is much harder than capturing it during the change.
Together, these pressures create “the trade-off” we spoke about last week: either keeping pace with change and letting control slip, or holding on to control and gradually falling behind.
Principles for choosing change management practices
You don’t need a perfect framework overnight. A few consistent habits can turn chaos into a repeatable process.
- Classify the change before deciding how to handle it: Establishing early what the likely impact is and where the change originated shapes almost every decision that follows, including who needs to be involved and how much validation is warranted.
- Match the level of rigor to the type of change: Operational change should follow a light, repeatable path, while transformational change warrants a deeper review; applying one standard to both is the most common reason change processes lose credibility.
- Validate away from production: Set up sandbox environments so teams can see what a change actually does before it reaches the systems the business is running on.
- PM Tip: For changes that impact business operations or compliance, testing in a blank instance isn't enough. Use Sandboxes to validate how new apps or complex schemes interact with your existing data and 3rd-party integrations. It’s the best way to prove to your stakeholders that the change is safe.
- Own the narrative: Someone should own the decision, understand the business impact, and tell affected people about the change before they encounter it in their daily work.
- PM Tip: Bundled Releases let you opt into a predictable cadence, giving you time to prepare documentation or training before features go live.
- Treat the change as unfinished until you have learned from it: Deployment is not the end of the process, and the organizations that improve fastest are those that review what worked, what did not, and what should be handled differently next time.
Change as a competitive advantage
The organizations that win aren't the ones that stop change; they are the ones that absorb it faster. By building the capability to handle routine updates confidently, you free up your energy to focus on the transformational changes that actually move the needle for your business.
In the coming weeks, we will explore how to manage change in your Atlassian ecosystem, along with the tools and processes we are building to help you define, set up, and follow a change management process suited to your organization’s goals.
