The Jira click tax: cognitive load, shadow tools and the SAP parallel

The most powerful project management tool in the world is now the most reliable way to make your developers slower. Read that sentence twice before you file me under "another developer who hates paperwork," because I am not that guy. I have spent ten years implementing governance for a living: audit trails, approval workflows, change controls, the whole apparatus that keeps enterprise software honest. I configure tools like Jira for a living. And I am telling you the tool has become a tax on the very people it is supposed to serve.

Here is the absurdity, and it lands hardest if you have lived it. Your IDE autocompletes your code. Your AI copilot writes the boilerplate. Your CI pipeline builds and tests in minutes. Then you open the ticket for the work you just did, and the 2000s walk in. Assignee, component, fix version, story points, the custom field your team added in 2021 that nobody remembers the purpose of, a transition screen, another transition screen. Fourteen clicks and a form that asks fifty questions, to record work that took a tenth of the time. We build software in the 2020s and we manage it with a tool designed in the early 2000s, configured by well-meaning people who were told to capture everything.

The tool that says yes to everything

Jira started in 2002 as a bug tracker. 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 platform, and that is where the trouble begins. Breadth was a deliberate product choice, not an accident of design. Every new audience, from marketing to legal to support, gave the instance a reason to grow.

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 epic, which parent epic, which account, 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 ticket, forever, by default.

That 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 sprout handoff steps. If leadership distrusts its own teams, statuses 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.

The click tax: what the research says about cognitive load

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 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 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 claim all tracking is bad. It claims the tracking you impose on people has a cost, and you should be able to name what it buys you.

You already know this from the inside, by the way. Remember the last time you were deep in a problem, the fix forming in your head, and a notification pulled you into a ticket that needed a status update and three dropdowns? The fix dissolved. That is not a personality flaw; it is a well-documented feature of human attention. Interruption research has shown for years that recovering focus costs far more than the interruption itself. Jira is not the only interruption in a developer's day, but it is the one your organization chose to make mandatory.

The dashboard lie

The SPACE framework, from the same research group two years earlier, lands exactly on management'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 people who study this for a living are telling you that the dashboards you configure toward are known to be flawed.

Let me be specific about the lie, because it matters. A burndown chart measures the rate at which tickets move across 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.

Shadow tools are a demand signal, not a rebellion

Here is where the folklore gets interesting, because the anecdotes point at something the research confirms. When developers secretly keep their real work in Linear, Notion, a shared Markdown file, or a plain text todo list, it is tempting to call them rebels. They are not rebelling; they are adapting. The shadow tool is the path of least resistance to the three things the DevEx model says matter: flow, fast feedback, low cognitive load.

Linear's own design philosophy, which the company publishes openly, is the opposite of Jira's. Where Jira says "configure it however you like," Linear says "we made the decisions so you can move." Opinionated, low-friction, keyboard-first. You can disagree with the details, but you cannot miss the demand signal: a growing number of individual contributors want a tool that gets out of the way.

Before anyone throws the "enterprise" card at me, let me deal with it head-on. Linear and Notion are not enterprise replacements for Jira. I would not claim they are, and neither should you. They cannot express a portfolio roll-up for five hundred engineers, or an audit trail a regulator will accept, or a change-approval workflow that a SOX auditor wants to see. That machinery is real and it is load-bearing.

The defensible claim is narrower and stronger: these tools reveal what developers actually want when no one is forcing a choice. That is a measurement, not a recommendation. When your best engineers keep a second system for the work that matters, the second system is telling you something about the first one. Listen to the signal; do not shoot the messenger.

One caveat on the discourse, because intellectual honesty cuts both ways. 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. The loudest voices over-sample frustration, and you should discount them accordingly. The absence of outrage is not endorsement. But it is also not a reason to ignore the pattern. The research is the reason.

The SAP parallel: I have built this tax myself

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 configuration 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 cost more analyst and project-manager hours to maintain than the visibility it produced was worth. We built dashboards nobody used to make a decision. I know that 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 defend controls in audits. I explain to CFOs why a control exists and what it protects. When I tell you 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.

The counter-argument, dealt with honestly

The strongest objection to everything above is that Jira's flexibility is the feature, not the bug. Banks, pharma companies, government agencies, and SAP-heavy enterprises need audit trails, custom workflows, portfolio roll-ups, and compliance fields. A minimalist tool cannot express a SOX-audited change-approval workflow. I implement that kind of governance for a living, so I am not going to caricature it. The power is load-bearing somewhere, and it is load-bearing precisely where the stakes are highest.

The second objection is that most Jira pain comes from over-customization by well-meaning admins, not from Jira itself. A cleanly configured Jira is fast. This is also true, and it is the most important concession in this article, because it sharpens the thesis instead of weakening it.

If the tool's power were the disease, the cure 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.

Where this goes next

Trend pieces are only worth writing if they predict something, so here is my second-order view, with the caveat that it is a judgment call and not a data point.

First, expect the split to widen between the governance layer and the work layer. Regulated organizations will keep Jira, or something like it, for the audit trail and the portfolio roll-up. They will increasingly run the daily work somewhere else: a lighter tool, a whiteboard, or no tool at all for the two-person pairing session. The enterprise tool becomes the system of record, not the system of work. That is a healthier architecture, and it is already how the best-run programs I have seen operate.

Second, expect AI to absorb the data entry before it fixes the process. Copilots will fill in the custom fields, move the tickets, write the status updates. The tax will not disappear; it will be outsourced to software that does not resent it. That is good news for flow, and it hides a trap: if the AI does the paperwork, the paperwork stops hurting, and nothing forces anyone to question whether the paperwork should exist at all. The pain was the only feedback loop the process had.

The question that survives both moves is the one the tool cannot answer for you: does this field, this workflow, this report earn its place? If it does, keep it and make it as cheap as possible. If it does not, delete it while deleting is still a normal thing to do.

The fix that does not require a migration

The good news is that the fix is not a tool migration and 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 two in the morning; 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.

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

• DevEx: What Actually Drives Productivity (ACM Queue, 2023)

• The SPACE of Developer Productivity (ACM Queue, 2021)

• Accelerate State of DevOps Report 2024 (DORA)

• Stack Overflow Developer Survey 2024

• Linear's Method: product philosophy

• Atlassian Jira