nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do you spread Jira admin skills without losing control?

John Price_aiexq9

I manage Jira for a large org and we have Cloud (1800 users), Data Center (8000), and Server (10k+). We have a team of 6 people that manages support, infrastructure (AWS), upgrades, and migrations. Obviously that don't scale well and makes us a potential blocker for the very teams we want to help. In the past we've allowed a large number of Jira admins from other teams in order to enable self-service, but those admins haven't always made good choices about customization and it's led to a bit of a mess.

I'd like to hear how other admins handle this. Cloud has of course added self-service projects, but I'm not convinced those are 100% fully baked just yet, especially with regard to the central admin team's visibility into them.

Some things we've done recently:

Require admins to read and sign a Confluence page called Jira Admin Code of Conduct. This is a base "I know what I'm doing and will ask for help if I don't" sort of thing.
(Data Center) Soft barrier to custom field creation by hiding the button using CSS and encouraging admin discussion (Teams channel) about customization needs.
More 1-on-1 time showing teams how to solve problems as a project/Jira admin.
Bought Automation for Jira to allow project admins to do more things without needing Jira admin. We are encouraging this instead of workflow post functions or Groovy scripts.

What great ideas do you have?

Comments

Guilhem Dupuy

Hi @John Price ,

That is a very interesting question you are asking, I'm looking forward to reading what other Admins have to say about it.

I think what you've done is already great, especially the idea of giving more power to the project Admins using the automation rules.

I have a few ideas but I guess you've already thought about it :

Reduce the number of Jira Admins to the strict minimum
Make sure the Jira Admins know what they are doing, through a solid Jira Admin training course. I would recommend a 2 days course which is what we are used to doing.
Have you already restricted the Team-Managed project creation to the Jira Admins only ? I found this type of project to complicate significantly the Jira administration, by multiplying the number of statuses existing in your Jira instance for example.

Looking forward to reading other ideas,

Guilhem

Paula Hidalgo

We have a Jira Admin structure to support 5,500+ users, 1,100+ Company-Managed Software projects, 6 Team-Managed Software (Next-Gen) projects in a single Cloud instance and are approaching 1,000,000 issues:

2 full-time Jira Admins (Subject Matter Experts)
1 Jira Admin does part-time support (SME)
2 Jira Admins who only create Jira projects and update field contexts
4 qualified as-needed Jira Admins who get temporary privileges for tailoring a specific business unit configuration

We no longer allow new Team-Managed Software (Next-Gen) projects.

We hold monthly Jira Admin CoP with anyone who is a permanent Jira Admin or is eligible to become a temporary Jira Admin. The topics covered are:

Atlassian Cloud Support tickets
Configuration changes and clean up activities (all changes require an issue in a Jira Support project and use a specific component to display completed config changes on a Confluence page)
Review the change in Jira Cloud stats (snapshot of stats are taken on 1st and 15th of the month. Stats are ones outlined in "Jira Strategy Admin Workbook" by @Rachel Wright

Our strategy included established tailoring guidelines. Any change must maintain a stable, performant Jira Cloud. In addition, tailoring needs to support our internal/external regulations associated with development processes, to support the common Jira metrics, and to identify a value add (i.e. increased efficiency). An efficiency gain needs to balance the long term maintenance required on any tailored/additional configuration element.

Any temporary Jira Admin has to review planned change(s), approach to change(s), and timing of change(s) with one of the SMEs. Risks and consult points with SME are established. Required training prior to granting temporary Jira Admin privileges is based on the proposed change and the individual's competency. We do take advantage of our Premium Sandbox with the temporary Jira Admin privileges.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

server

jira

jira-server