Jira is too powerful: how over-configuration kills developer productivity
Jira's real cost is optionality: every custom field, workflow and nested epic taxes attention, and the research on developer productivity is unambiguous about the price. The same 'just in case' configuration reflex that bloats Jira instances shows up in SAP as the upgrade tax, a pile of locally justified customizations that turns every release into a project. The fix is a discipline, not a tool migration: name the decision each field feeds, delete what nobody uses, and keep the rigor only where compliance is real.
There is a manager I keep thinking about. Call him the over-enthusiastic Jira admin. Well-meaning, competent, promoted because he cared about process. He spent a month configuring the instance before the team even moved over: custom fields for everything, automation rules that reassigned tickets at 2am, epics nested inside epics "just in case we need to track that later." A year on, his team spends the first hour of every day answering the tool instead of doing the work. The board is a masterpiece. The product is stalled. I have a theory about what happened, and it has nothing to do with this manager being bad at his job. Jira is too powerful for its own good. Its greatest feature, the infinite customizability that made it the enterprise default, is also its greatest curse: it lets an organization automate its own inefficiencies and call the result agile.
The tool that says yes to everything
Jira started in 2002 as a bug tracker for software teams. Log it, assign it, fix it, close it. The power was narrow and the workflow was obvious. Then Atlassian broadened it into a general project management tool, and that is where the trouble begins. Breadth of applicability was a deliberate product choice, not an accident of design. Every new audience got a reason to configure. The problem is not that Jira can do a lot. The problem is that it never tells you to stop. A bug tracker asks one question: what is broken? A fully configured Jira asks fifty: which component, which release, which fix version, which account, which epic, which parent epic, which custom field number forty-seven. Each question is individually reasonable. Each one was added by someone with a real use case in mind. And each one is now asked of every single ticket, forever, by default. This is the "just in case" bloat. The field that might be useful someday, the workflow step that covers a regulatory edge case nobody can name, the report that would be nice to have. Nothing is added out of malice. Everything is added out of a future that never arrives. The result is a tax on every piece of work that does arrive. Conway's law says organizations design systems that mirror their communication structures. Your Jira instance is that law with a UI. If your company communicates in silos, your workflows will sprout handoff steps. If your leadership distrusts its own teams, your statuses will multiply to prove that work is happening. The tool is a mirror, and the mirror is honest. That is uncomfortable, because it means the bloat was never really about the tool.
What the research says about your dashboard
The computer science literature on developer productivity is unusually clear on this topic, which makes it a useful corrective to vendor marketing. The DevEx model, published by Nicole Forsgren and colleagues at ACM Queue in 2023, identifies three drivers of developer productivity: flow state, fast feedback loops, and low cognitive load. Notice what is not on that list: ticket counts, cycle times, burndown charts. A Jira instance loaded with mandatory custom fields, nested epics, and multi-step transition workflows is a textbook cognitive load tax. Every field is a decision the developer must make or skip. Every transition screen is an interruption to the flow state the research says is worth protecting. The model does not say all tracking is bad. It says the tracking you impose on people has a cost, and you should be able to name what it buys you. The SPACE framework, from the same research group two years earlier, goes further and lands exactly on the manager's favorite toys. It warns that output and activity dashboards, the ticket-count, cycle-time, and burndown views that a "just in case" configuration produces, are a misleading single-dimension proxy for productivity. The field's own researchers are telling you that the dashboards you configure toward are known to be flawed. The manager who adds fields to get better dashboards is optimizing toward a metric the people who study this stuff say you should not trust in isolation.
The dashboard lie
Let me be specific about the lie, because it matters. A burndown chart measures the rate at which tickets move through your board. It says nothing about whether the tickets were worth doing, whether the work shipped, or whether anyone uses the result. It is a measure of motion, presented as a measure of progress. Teams figure this out fast, and they respond rationally: they break tickets into smaller pieces, they reopen and re-close, they game the statuses. The dashboard goes up. The work does not get better. The manager sees a healthy board and feels good. Everyone else sees the same board and feels managed.
The case for the defense
Before I go further, the fair version of the counter-argument. Jira's flexibility is load-bearing in a lot of organizations. Banks, pharma companies, government agencies, and SAP-heavy enterprises need audit trails, change approval workflows, and portfolio roll-ups that a minimal tool cannot express. If you are in a SOX-audited environment, you cannot run your change management on a Kanban board and a prayer. The power is not decoration there; it is compliance. I implement this kind of governance for a living, so I am not going to caricature it. There is also the "bad configuration, not the tool" objection. A cleanly configured Jira instance is fast. The pain comes from over-customization by well-meaning admins, not from the product itself. This is true, and it is the most important concession in this article, because it sharpens the thesis instead of weakening it. If the power were the problem, the fix would be a weaker tool. But the power is optional. A minimal instance exists inside every bloated one. So the real question is why so many teams, full of smart people, choose the bloated version. My answer: optionality is the curse. A tool that can express any workflow lets you build a bureaucracy and call it agile, and it gives you the paperwork to prove you are agile. The custom fields are the evidence. The nested epics are the evidence. The forty-seven statuses are the evidence. You are not slow because the tool is slow. You are slow because the tool let you design a process that is slow, and then it made that process look professional.
The SAP parallel
I want to bring in the world I actually work in, because the pattern is identical and the stakes are higher. In SAP, every customization is a Z transaction or a config change. Each one was added for a locally justified reason: this plant reports differently, this legal entity needs a special validation, this controller wants the number broken out a specific way. Individually, each change made sense. Collectively, they become what SAP consultants call the upgrade tax: a pile of customizations so deep that every new release, every migration, every patch becomes a project in itself. I have sat in scoping meetings where the client asked us to preserve custom fields that nobody could remember the purpose of. "It was there before we arrived" is a real sentence people say about their own systems. The Jira version of that sentence is "we added it just in case." Same reflex, same cost, same silence about the cost. Here is the story I keep coming back to. A program where the reporting apparatus itself cost more analyst and PM hours to maintain than the visibility it produced was worth. We built a dashboard nobody used to make a decision. I know this sounds like a punchline, but it is the normal state of affairs in enterprise software: the machinery of tracking grows until it is more expensive than the work being tracked, and nobody notices because the machinery is invisible. It is just "how we report." And here is the part that gives me standing to write this article at all. I am the process person. I build governance structures for a living, I defend them in audits, I explain to CFOs why the control exists. So when I tell you that the "just in case" configuration reflex has gone too far, it is not a developer complaining about paperwork. It is someone who is deeply on the side of process, telling you that this specific pattern is a tax with no return.
What to do about it
The good news is that the fix is not a tool migration and it is not a personality transplant. It is a discipline, and it costs nothing. Before you add a custom field, a workflow step, or an automation rule, ask three questions. First, what decision will this actually feed? If you cannot name a decision, you are building decoration. Second, how often will this be used? A field that gets filled one time in ten is a tax on the other nine. Third, what will you delete when this turns out to be unnecessary? If you have no deletion path, you are building your own upgrade tax. Then do the unglamorous work: delete. Deleting is a feature, and it is the most underused one in the product. Remove the custom fields nobody fills. Merge the statuses that mean the same thing. Kill the automation rule that reassigns tickets at 2am; if a ticket genuinely needs attention, a human can notice it in the morning. The teams I have seen recover fastest are the ones that treat the configuration as a living system that needs pruning, not a monument to be completed. Keep the rigor where it is real. If you are in a regulated environment, keep the audit trail and the approval workflow, and scope them to the processes that actually need them. Compliance is not the enemy of speed; undifferentiated compliance is. The SOX-audited change approval does not need to sit next to the daily task board. Separate the two, and let each be honest about what it is for. A note on the tools that promise to fix this. Linear and Notion are not enterprise replacements for Jira, and I would not claim they are. They cannot express a portfolio roll-up for five hundred engineers or an audit trail a regulator will accept. What they do well is reveal the demand signal: individual contributors want a tool with low friction, fast feedback, and no cognitive load tax. That is the research talking, not the marketing. Listen to the signal, keep the enterprise machinery where you need it, and stop pretending the friction is a feature. And one last thing, about the loudest voices. The developers who rant about Jira on forums are real, but they are not the whole population. Satisfied users in large regulated companies do not write blog posts about their issue tracker; they are too busy shipping. So the discourse over-samples frustration, and you should discount it accordingly. The absence of outrage is not endorsement. But it is also not a reason to ignore the pattern. The research is the reason. Here is what it looks like when you get this right. A team where Jira is boring again. The Monday standup spends two minutes on the board and twenty on the work. The manager who added forty custom fields in year one deletes thirty of them in year three, and nobody notices except that the work gets easier. The tool asks fewer questions, and the questions it asks are the ones that matter. That is the whole game: process that earns its place, the way every line in a good memo does. You can have the governance when you need it and the speed when you do not. Jira will let you build either. The question is which one you choose, because the tool will never choose for you.
Sources
Frequently asked
Why is Jira too powerful for its own good?
Because its infinite customizability lets an organization automate its own inefficiencies and call the result agile. A bug tracker asks one question, what is broken; a fully configured Jira asks fifty, and each one is a tax on every ticket, forever, by default.
Is Jira's flexibility ever justified?
Yes, in regulated environments. Banks, pharma companies, government agencies and SAP-heavy enterprises need audit trails, change approval workflows and portfolio roll-ups that a minimal tool cannot express. The power is load-bearing there, but it should be scoped to the processes that actually need it.
How do you fix an over-configured Jira instance?
Before adding a custom field, workflow step or automation rule, ask what decision it feeds, how often it will be used, and what you will delete when it turns out to be unnecessary. Then do the unglamorous work: delete fields nobody fills, merge statuses that mean the same thing, and treat configuration as a living system that needs pruning.
Need this in your organisation?
I work with a small number of clients each quarter on ERP strategy and IT-department automation. If the questions raised above are live in your team, get in touch.
Start a conversation →