How to Get Engineers to Love Your Jira Instance | by MG | Jun, 2022

Some will still hate it

Jira logo

Jira is an issue tracking and project management platform that enables teams to track their work and provides insight into how their work is being done. The important note is that it is a platform. It facilitates software development and business processes. If those processes are ill-defined, then it can be configured to implement those ill-defined processes flawlessly. This will reflect poorly on the tool because that is the interface to the process.

However, there are ways to control the configuration to not produce unnecessary overhead on the engineers while still providing the data in order to make business decisions and create quality products.

I should note, I’m referring to the Data Center (self-hosted) version of Jira and not the Cloud (SaaS) version. While there are similarities, the issues encountered with both can be quite different.

It is too slow


  • Some actions can many seconds to complete. Screens can take time to load. This can slow down sprint planning, closing tasks, etc.


  • Evaluate hardware and scope of the instance. It may be as simple as throwing hardware at the problem. The number of projects, issues, custom fields, etc. can contribute to this.
  • Consider archiving issues on a schedule. ie Do you really need to be able to see stories that were completed over a year ago?
  • Implement custom field contexts properly so the fields are not indexed for projects that will not use them.
  • Evaluate workflow transitions and automation. Excessive use of post functions can slow down transitioning issues. Consider moving them to project automation or other methods.

The UI is clunky


  • Admittedly, the UI is inconsistent across the tool which can be confusing. Some operations like moving tasks between projects/issue types or bulk changes can take several screens to complete. Opening an issue in one part of the tool will look different than opening it in another part.


  • Standardizing configuration for like-projects. Moving issues between the projects will trigger a mapping process if the configuration between the projects are different. If moving issues will be a common process, having the projects share the same configuration will expedite this process and eliminate the need for the mapping exercise. However, in my opinion, overly fancy UIs cause other issues.

It’s too confusing


  • Workflows are too complicated, there is too much variance in how it’s configured.


  • This has little to do with Jira and is likely due to poor configuration of the tool and/or top-down management.
  • Keep the configuration as simple as possible and cognizant of any overhead it may add to engineers’ workload.


  • There are too many custom fields


  • Add governance to control which fields are added and set expectations on why 100 custom fields cannot be added to a single project.

It’s too customizable


  • Jira, being a platform, allows it to be configured entirely from the ground up. This is both one of its strong-points but also one of its biggest drawbacks.


  • Implementing proper governance so the tool configuration doesn’t get out of hand. (See Strict governance below.)
  • Narrow training specific to how it’s configured. There’s Jira 101 training and then there’s how your instance of Jira is configured. Jira can be overwhelming but if there are simple runbooks to follow for common tasks the users do not need to be experts in how to use the tool, they just need to know how to use it for their use-case.
  • Have admins that understand implications of certain configurations.

It isn’t customizable enough


  • Users will also complain that they don’t have control to configure the tool as they like for their own team.


  • Set expectations to why each project cannot control, nor should they have their own configuration. Large enterprises can’t afford the overhead associated with managing 100s of custom projects. The quality of the tool will decrease when changes are added without careful consideration. There are SaaS project management tools that allow for teams to manage their own configuration but this isn’t a model that a large enterprise can benefit from when some metrics are globally captured or standards need to be followed.

I have seen a lot of instances of Jira that have 1000s of custom fields, many with duplicate names, or highly specific names that won’t apply to all users. This occurs with lack of governance.

A user asks for a new custom field or status and the admin implements it with no questions asked. What if there were an existing field that can be leveraged? What will this field be used for?

A multi-disciplined governance board should triage and approve requests for changes, particularly for shared configurations.

Some questions to consider when triaging new requests:

  • Will this change impact all teams using the configuration?
  • Will it add unnecessary overhead?
  • Does it provide value? What is the ROI or impact if the change were not implemented?

This will slow down the process of making changes but is necessary for enterprise-sized instances that can’t afford to deal with the tech of field bloat or debt poorly configured projects.

Again, Jira facilitates processes. Engineering processes, such as Defect Management, should have an owner. This owner is responsible for the process that should be tool-agnostic. The owner will have influence over the changes to the process and the Jira responsibles/owners will be for implementing the process and making sure the tool’s best processes are followed.

Benefits of this model include:

  • A centralized place to go to for changes to the process.
  • Relieves responsibility from the Jira team who may not be experts in the process, nor should they be owning the process that other teams own. They should just be responsible for the tool facilitating the process properly.
  • Communication channels will be clear to go to the process owner to answer questions rather than the Jira team.

This is similar to the when to build or when to buy conundrum.

If a solution cannot be solved gracefully through configuration then it shouldn’t be implemented. The experience and ROI to implement will be negative.

In most cases, plugins already solve this issue. The cost to purchase the plugin may be lower than it will be to develop and maintain another solution.

Learn to say “no” in the cases where it will be difficult to create the solution without solving the problem 100%.

A successful team model will have the following:

  • System Administrators: Sysadmins should be responsible for the upgrades and KTLO. They should not be responsible for designing business processes and configurations.
  • Jira Admins: Responsible for configuring the tool through the front end UI. Workflow configuration, project configuration, field configuration, etc.
  • Business Systems Administrators: Responsible for translating the business requirements to how they will be implemented in Jira.
  • Developers: For scripting and plugin development. This role is only necessary for heavily used Jira instances that could integrate with other tools or need a lot of automation.

There can be some overlap here between the BSA and Admin or Admin and Developer but one sole resource should not be responsible for all.

I have seen many job postings that are looking for a unicorn that can do it all. There are many problems with this model:

  • Someone very technical may be able to configure the tool with no issues. These resources are typically an Engineer or someone in IT. They may not be experts in the process. There are problems with someone who isn’t familiar with Agile implementing a Scrum workflow for an entire engineering organization.
  • Someone who is very process-oriented may not be as technical to understand data integrity or specifics of how the tool works.
  • An infrastructure engineer should not, and in most cases, have no interest in working with end users in designing their business process. I have definitely seen job requirements that conflated all of these responsibilities which is a recipe for disaster.

Not all of these solutions will solve every Jira problem but they should help increase satisfaction with the tool. Having an understanding that Jira is a platform that supports processes will help users understand the areas to focus on to improve the user experience.

Some engineers probably are so jaded from working with poor instances that they will not be persuaded but I think it can still be configured to satisfy their needs. Reach out to them and get their feedback directly. In most cases, their issues are with the configuration which can easily be solved. Issues with the UI or performance can be mitigated to a point.

I still think Jira is a superior tool to what’s out there when it is configured and managed properly.

Leave a Comment