Community resources
Community resources
Community resources
What We Learned From Jira Admins: 10 Practical Lessons That Work Across Teams
Working with Jira often teaches you that the most important lessons are not hidden somewhere in a particular setting or feature.
Over the past year, I've had the opportunity to work on content shaped by conversations with Jira admins, Atlassian Community Champions, consultants, and people who work with Jira every day. I've managed interviews, collaborated with experts on articles, worked with them on videos, and sometimes simply had conversations about their everyday experiences with Jira. Along the way, I've heard a lot about what works, what becomes difficult as Jira grows, and what experienced admins would approach differently if they were starting again.
At Getint, we also work closely with teams that need Jira to cooperate with other Jira environments and tools across their organizations.
The environments are different, but I've noticed that many of the same lessons keep coming back. They are about keeping Jira manageable, involving the people who actually use it, knowing when standardization helps and when teams need flexibility, and considering what today's configuration decisions will mean a few years from now.
So, instead of another guide, today I wanted to collect some of those lessons in one place. Think of this as a growing knowledge base of practical ideas we've picked up from people who spend their days working with Jira across different teams and organizations.
1. Talk to the People Doing the Work Before Configuring Jira
It's tempting to start a new Jira project with the configuration itself: define the work types, build a workflow, create the fields, configure the board, and then introduce the finished setup to the team.
One recurring lesson from experienced Jira users is to reverse that order.
Before designing a workflow, understand how the work actually moves through the team.
- Who creates it?
- When does responsibility change?
- Which steps genuinely matter?
- What information does someone need before they can start?
- Where do things usually get stuck?
The documented process and the real process are not always the same. A workflow diagram might show eight perfectly defined stages, while the people doing the work routinely skip three of them or coordinate an important approval outside Jira.
Talking to users first helps an admin distinguish between requirements that Jira should support and complexity that has simply accumulated around the process. It also makes adoption easier, because a Jira configuration built around how people actually work requires fewer workarounds later.
2. Every Status, Field, and Rule Should Earn Its Place
Jira is incredibly configurable, which is both one of its greatest strengths and one of the easiest ways to make an instance unnecessarily complicated.
A team asks for another status. Someone needs a custom field for one report. A new automation saves a few clicks. Individually, each change seems harmless, but over several years those small decisions can leave an organization with workflows nobody fully understands, hundreds of custom fields, and automation rules whose original owners have long since moved to another role.
A useful question to ask is: what changes if we add this?
A workflow status, for example, should usually represent a meaningful stage of work. If moving an item into that status does not change responsibility, reporting, visibility, or what happens next, it may not need to be a separate status at all.
The same thinking works for fields and automation. Configuration should solve a real problem rather than simply represent every detail of a business process.
Simplicity is not about having the fewest possible Jira features. It is about being able to explain why the ones you have are there.
3. Standardize What Helps Teams Collaborate, Not Everything
Standardization becomes increasingly important as Jira grows across an organization, but there is a difference between creating consistency and forcing every team to work identically.
An engineering team, service desk, marketing department, and PMO probably should not have exactly the same workflow. Their work is different, and Jira should be able to reflect that.
Problems appear when every team also invents its own language for concepts that need to be understood across the organization. If one team's "Planned," another team's "Ready," and a third team's "Accepted" all mean essentially the same thing, cross-team reporting and collaboration become harder than they need to be.
A better approach is often to establish a common foundation around the elements teams depend on when working together, such as naming conventions, priorities, status categories, security requirements, and information needed for shared reporting (while allowing flexibility around team-specific processes).
This does not mean every organization should standardize the same things. The useful question is whether a configuration affects cross-team understanding, governance, security, or reporting. If it does, some consistency may help. If it only affects how one team organizes its daily work, enforcing a company-wide standard may provide little value.
The goal is not identical Jira projects. It is enough consistency that people can understand each other's work.
4. Don't Let Your Jira Setup Depend on One Person
Most long-running Jira environments probably have at least one person who knows why a particular configuration exists. Sometimes that person is the only one who knows.
That is risky.
When every workflow change, permission question, automation failure, and custom field request eventually reaches one administrator, that person becomes both a bottleneck and a single point of failure.
Healthy Jira administration needs shared knowledge and clear ownership. Technical admins can understand what Jira is capable of, but process owners should understand why a workflow exists, and business stakeholders should be involved in decisions that affect how their teams work.
Documentation matters here too. It should not only explain how something is configured. Recording why an unusual rule or decision exists can be much more valuable to the next administrator looking at it two years later.
The objective is to make sure organizational knowledge about Jira doesn't disappear when one person goes on holiday or changes jobs.
5. Treat Automation as Infrastructure
Jira Automation can remove a surprising amount of repetitive work. It can assign work, update fields, notify teams, create related items, and connect processes that would otherwise depend on someone remembering the next step.
But as automation grows, it needs to be managed with the same care as the rest of the Jira environment.
That means clear naming conventions, documented ownership, testing, monitoring audit logs, and periodically reviewing whether rules are still necessary. It also means being careful about rules that can trigger one another or operate across a very broad scope.
One of the easiest automation mistakes is solving an unclear process by automating it. The manual work disappears, but the underlying complexity does not. It simply becomes less visible.
Before automating something, make sure the team understands the process itself. Then automate the repetitive parts that genuinely do not require human judgment.
A good automation should make Jira easier to operate, not make administrators afraid to touch it because nobody knows what else might trigger.
6. Build Boards and Reports Around Questions, Not Available Data
Jira can display a lot of information. That does not automatically make all of it useful.
A board, report, or dashboard works best when it helps someone answer a specific question. Instead of starting with the gadgets, charts, or data available in Jira, start by asking who will use the view and what they need to understand.
| Who needs the view? | What should it help them understand? |
|---|---|
| Developer | What should I work on next, and what is blocking me? |
| Team lead | Where is work accumulating or getting stuck? |
| Product owner | Are priorities and sprint goals still realistic? |
| Cross-team lead | Which dependencies could affect delivery? |
| Leadership | Where are the major risks, delays, and trends? |
Starting with those questions makes it much easier to decide what information belongs on a board or dashboard. The opposite approach - starting with everything Jira can display, often results in dashboards filled with gadgets that nobody really uses.
It also explains why one universal dashboard rarely works for everyone. A developer and an executive may be looking at the same underlying work, but they are trying to make very different decisions.
Visibility is valuable when it helps somebody act.
7. Good Jira Governance Creates Guardrails, Not Bureaucracy
As Jira expands across more teams, some form of governance becomes unavoidable. Someone needs to decide who can create projects, how permissions are handled, which configurations should be shared, how changes are introduced, and what security requirements apply.
The danger is going too far. If every small workflow adjustment requires a lengthy approval process, teams will eventually look for ways around the system. On the other hand, if every team can create anything it wants without coordination, the instance can become increasingly difficult to maintain.
Good governance sits between those extremes.
Define the areas where consistency genuinely matters and give teams freedom everywhere else. A shared permission model might be important for security. A naming convention may help administration. Common status categories may make reporting possible. Whether two teams need exactly the same board configuration probably matters much less.
Governance should make Jira easier to scale, not harder to use.
8. Assume Today's "Temporary" Configuration May Still Be There in Three Years
Temporary solutions have an impressive ability to become permanent.
A field is created "just for this project." A workflow is duplicated because there is no time to redesign it. An automation rule provides a quick workaround until a process is improved. Then the project grows, hundreds or thousands of work items depend on that configuration, and changing it becomes significantly harder. It means considering the cost of living with a quick solution if it stays longer than expected.
Before introducing something temporary, ask whether it can be easily removed later, who will own it, and what other configurations might begin depending on it.
A few extra minutes of thinking at the beginning can save a surprisingly large cleanup project later.
9. When Work Crosses Teams, Decide Who Owns What First
This is a lesson we have seen particularly clearly while working with integrations, but it applies equally well inside Jira.
Suppose a customer request starts with the support team, becomes development work, requires input from another department, and eventually needs to return to support before the customer receives an update. Technology can move information between all those people, but the harder question is deciding who owns it at each stage.
- Which team controls the priority?
- Who changes the status?
- Where is the source of truth?
- Which information should another team be able to update, and which should only be visible to them?
These questions become even more important when work crosses Jira instances or different platforms. It is easy to begin an integration project by discussing fields and mappings because those decisions feel concrete. But a technically perfect mapping will not fix unclear ownership.
This is something I've seen repeatedly around integrations: the most important decisions often happen before anyone starts configuring the integration.
Define the collaboration model first. Configure the technology around it second.
10. Don't Force Everyone Into the Same Tool Just to Improve Collaboration
This is probably one of the lessons I've seen most clearly from the Getint side.
Organizations rarely operate in a single-tool world. Development might use Jira, IT may work in ServiceNow, another engineering organization may prefer Azure DevOps, and an external customer may have its own Jira instance. There can be perfectly legitimate reasons for each team to stay where it is.
Moving everyone into the same platform can sometimes simplify collaboration, but it can also mean replacing established processes simply to solve an information-sharing problem.
The better question is: do these teams need the same tool, or do they need the right information from each other?
Sometimes consolidation is the right answer. In other situations, clearly defined integrations between systems allow each team to keep the workflow that works for them while relevant updates move automatically between environments.
This becomes especially important when collaboration crosses organizational boundaries. A customer may not want to work in your Jira instance, just as your engineering team may not want to manage its development work in a customer's environment. The goal does not have to be getting everyone onto the same platform. It can simply be ensuring that both sides receive the information they need without relying on constant manual updates.
The principle is the same one that appears throughout this list: start with how people need to work together, then decide how Jira and the surrounding tools should support them.
What Have Jira Admins Taught You?
Looking back at what we've learned from Jira admins, Community Champions, consultants, and teams we've worked with, one theme connects almost everything on this list: good Jira administration is less about knowing every Jira feature and more about making thoughtful decisions about when and why to use them.
The best workflow is not necessarily the most sophisticated one. The best automation is not the one with the most actions. And good governance does not mean making every team work in exactly the same way.
Jira should make work easier to understand and manage. When the configuration starts becoming more complicated than the work itself, that is usually a good moment to reconsider what has accumulated and why.
These are the lessons that have stayed with us, but I'd like to also turn the question over to the people here who work with Jira every day: What's one Jira lesson you learned through experience that you wish someone had told you earlier?
Was this helpful?
Thanks!
Kinga_Getint
2 comments