What Jira Admins Wish PMs Knew: Bridging the Gap with Better Configs

[#1]

Project Managers (PMs) and Jira Admins often work closely—but not always harmoniously. While PMs focus on delivering results and managing timelines, Jira Admins are juggling schema integrity, configuration cleanliness, and system performance. Somewhere in the middle, a request like "Can we just add this field to the board?" might set off a silent internal scream from your admin.

Let’s bridge this gap—with empathy and better configurations.

---

1. Filters Aren’t Just Keywords—They’re the Brain of Your Board

PMs often request boards like:

“I need a board that shows my team’s stories, bugs, and anything tagged ‘urgent’—but not epics or subtasks.”

While this seems simple, the filter driving your board determines its functionality, scope, and gadget reports. Admins wish PMs understood:

• Complex filters slow down boards (especially with nested JQL and large datasets).

• Duplicating boards with minor JQL tweaks can cause filter chaos.

• Shared filters need clear ownership and lifecycle management.

What helps: Collaborate to define a filter strategy. Name them well. Use Jira groups or project roles in the filter when possible.

---

2. Custom Fields Aren’t Free (Even if They Look Like It)

Requests like “Let’s add a new dropdown for business impact” are common. But:

• Every custom field increases the indexing time.

• Custom fields with global context bloat performance.

• Field redundancy creates confusion during reporting and migration.

What helps: PMs can suggest reusing existing fields where possible and allow Admins to guide on field scope (global vs project-level).

---

3. Workflows Aren’t Just About Statuses

A PM might say:

“Can we just add a quick ‘In UAT’ status?”

But Admins are thinking:

• Does this require transition conditions?

• What happens to post functions and validators?

• Who approves movement between stages?

Each change may need re-publishing, migration of existing issues, or re-training.

What helps: Involve Admins in workflow discussions early. Share the why behind the need, not just the what.

---

4. Board Layout Requests Can Be Costly

“I need a separate swimlane for each assignee and color-code tickets based on priority.”

Sounds doable—until:

• The swimlane count exceeds 20 and becomes unreadable.

• Quick filters start overlapping and confusing.

• Configs differ from team to team, making audits impossible.

What helps: Keep boards simple. Use components or labels strategically. Let Jira dashboards do the heavy lifting for complex segmentation.

---

📊 5. Reports and Dashboards Need a Strategy, Not Just Data

PMs want burndown charts, control charts, and custom dashboards for leadership—all great!

But:

• Incorrect JQL can skew charts.

• Using personal filters causes dashboards to break when the user leaves.

• Everyone ends up duplicating the same gadgets.

What helps: Use shared filters, design templates for dashboards, and encourage naming conventions.

---

Bridging the Gap: Practical Tips

For PMs	For Admins
Ask why the request might impact the system.	Avoid jargon—explain trade-offs clearly.
Consider reusing fields or filters.	Create a reusable config library for PMs.
Involve Admins during sprint setup or new team onboarding.	Attend backlog grooming or planning sessions occasionally.
Maintain documentation for your project setup.	Offer PM-facing Confluence pages on Jira best practices.

---

Final Thoughts

Jira is not just a tool—it’s a platform. When PMs and Admins work as partners, not gatekeepers or requestors, the system becomes cleaner, faster, and more scalable.

Admins don’t want to say “no”—they want to say “yes, but let’s do it the right way.”

Let’s build that bridge—together.

[Anne Saunders]

This is EXACTLY why I prefer Company Managed Projects and why our org uses them exclusively.

We have templates for projects, boards, and dashboards by service line that we've refined with Dev and PM over several years. 

[Nic Thiele]

This article resonated with me (even though my role somewhat blends these functions), great advice.

[Yatish Madhav]

Thanks for this @Akhand Pratap Singh - I read just the first paragraph and all I thought was "I AM NOT ALONE!" :D

Well done @Anne Saunders - after about 7 or 8 years of using Jira, JSM and Confluence, I am still trying to get to a more solid version like what you have. We also solely use Company Managed Projects for that reason and have 2 template projects but still have so many others that are legacy. But having just under 1000 projects, around 700 fields, about 7 Jira admins (more in the past before I took over) and around 500 users it makes it a little tougher to action - but the baby steps still helps my sanity :D

I think due to Jira/JSM having countless jargon - although you mentioned it - it is still tough to push back the 'mere mortal' PMs (there I said it :P) with the requests that you mention but it is doable.

Also, @Akhand Pratap Singh regarding the bloating and performance impacts, I have been trying to clean up our instance but it is often met with "No, leave it as is to reduce impact" or "we need to retain projects/issues for 7 years" - how do we curb this? Usually performance related support tickets needs HAR files, which in itself is tough to attain and 'prove' to Atlassian support.

I def am going to share the link and this with our admins!

What Jira Admins Wish PMs Knew: Bridging the Gap with Better Configs

1. Filters Aren’t Just Keywords—They’re the Brain of Your Board
2. Custom Fields Aren’t Free (Even if They Look Like It)
3. Workflows Aren’t Just About Statuses
4. Board Layout Requests Can Be Costly
5. Reports and Dashboards Need a Strategy, Not Just Data

Thank you again

Yatish

[Akhand Pratap Singh]

@Yatish Madhav ,

It’s a classic Jira admin dilemma, you’re working to enhance performance, governance, and usability, but often face pushback due to compliance concerns or stakeholder caution. And to be fair, their concerns are valid. The fear of unintended impact is real, which makes risk analysis a crucial part of any cleanup effort.

So, The most important aspect over here becomes, how we present things.

Few tips:

1. Reframe as Archiving, Not Deletion: Say: “We’re archiving to improve performance, not deleting.”
Use Jira’s project archiving or export old data to Confluence/cloud storage.

2. Show the Impact of Inaction
Present metrics:

• X inactive projects

• Y unused fields

• Slower board loads
  Helps justify cleanup with real data.

3. Get Retention Policy in Writing (This is most important):  Ask Legal/Compliance to define what must be retained. Often, not everything needs to stay in Jira. Make sure these are well documented in your Knowledge base where users can be referred to.

4. Divide your Projects in Tiers and Critical level while defining what is to be archived and when based on inactivity of the project.

[Yatish Madhav]

Great stuff. Thanks @Akhand Pratap Singh

Yeh, that is really insightful and will use this as a slight guide as well. Now, to marry that theoretical and the practical :D

Thank you

[Ben Robbins]

This is why our team own our Jira platform. Any requests to change any of the configuration comes through our team and we assess the request. Guess we're fortunate that our company holds us as the SMEs of our Atlassian products and we have the power to turn away frivolous requests, or at least ensure that they fit our model.